Supervisor guide

The Supervisor Guide covers everything a supervisor can set up in terms of managing their contact center, working hours, agent statuses, as well as queues and routing where and when necessary.

Also, check out how you can manage automations and set up surveys to be shown to the customer after a conversation ends.

Capacity

Capacity is the maximum defined opened conversations for an agent by channel; default capacity for all agents or default system capacity for live messaging is 5 concurrent conversations.

Note that for voice calls - capacity is always one since one agent can talk to only one person at any given time. This default value cannot be changed on system or agent level. 

Default capacity

To set up the default capacity for all agents go to the Conversations module > Settings > General setup > Capacity. Capacity represents the maximum number of concurrent conversations that can be assigned to one agent over the automatic assignment.

Instant Messaging stands for a group of channels: SMS, WhatsApp, Viber, Twitter, Telegram, Google's Business Messages, Apple Messages for Business, and Messenger by Facebook.

Default capacity is taken into account only when not defined at the agent level.

Agent capacity

To set up agent capacity, go to the Conversations module > Settings > General setup > Agents > select the agent you want to edit > Capacity. Agent capacity is considered first. In case it’s not defined, default capacity is considered for new conversations assignments.

Waiting strategy

Being on hold can be frustrating for your customers so it is important that you are able to build a waiting strategy that establishes the best environment for callers while they wait to be connected to your agents.

To do so, navigate to the Conversations module > Settings > General setup. Click the WAITING STRATEGIES tab, and to define a new waiting strategy, click on the CREATE NEW button.

Name your waiting strategy and define general information:

• numbers or application (when using Web and In-App Calls) that your strategy applies to
• maximum waiting time that defines how long this strategy will run for

Subsequently, you can set up one or more available options depending on your business needs:

• Greeting message - this will be the first communication callers hear when they contact you. You can use the text-to-speech feature to craft a message or upload a file you would like to play to your callers.

• Hold music - certain types of music can calm a person while on hold and create a more positive experience for callers. You can upload your hold music file.

• Announcement message - when your customer's mind is occupied with something it makes the time they have to wait feel less burdensome. Keep callers engaged by periodically playing announcement messages.

• Maximum Wait Time Message - when the maximum wait time has been exceeded, and just before the call is about to be dropped, play a message to your customer letting them know that the call will end. You can use the text-to-speech feature to craft a message or upload a file you'd like to play to your customers.

You can enable/disable each option by clicking the toggle button. 

Create message

You can decide to create your waiting strategy messages as a speech version of the text you provide in a written format. In that case you should use text-to-speech as audio source and write the message script in the provided text field.

To do so, configure these available parameters:

• Language - select one of the available languages
• Voice - select one of the available voices
• Speech Rate - adjust the speed at which words will be spoken to be in line with the language and the message you are communicating

Upload file

You can use a file that you have previously recorded or created in your waiting strategy messages. In that case, you should use file upload as the audio source. Click Browse (or use drag and drop action to upload your file), locate the file, and confirm the action to upload your file. 

You can also delete uploaded files if needed.

Waiting strategy for messaging channels

Waiting strategy for digital channels applies to all the text-based channels used in the Contact Center.

When set, the waiting strategy triggers when a conversation enters the contact center directly or after being transferred from a bot and is unassigned.
The conversation will be unassigned if auto-assignment is not set up on the queue or if there are no available agents for auto-assignment.

There can be only one waiting strategy for a sender.
The waiting strategy consists of three types of messages:

1. Welcome message – a message sent to the customer when they enter the queue
2. Announcement message – can be a periodic message
3. Maximum wait time message – a message sent to the customer when they have waited the maximum defined time in the queue

At least one message must be enabled for the waiting strategy to be used.

Waiting strategy can end in three ways:

1. A conversation assigned to an agent.
2. A conversation waiting more than maximum wait time set up in which case this conversation is also closed. A closed conversation will be removed from the queue and won’t be assigned to an agent.
3. A conversation waiting for more than an hour. The conversation will remain open, but there will be no more messages sent to the customer.

Welcome message

A welcome message is sent to the customer upon entering a queue, but the conversation is left unassigned.
This message is sent only once and it usually contains a greeting.

Announcement message

Announcement message can be sent after the welcome message in regular intervals while the customer is still waiting for an agent to take the conversation (waiting for conversation to become assigned to an agent). Minimum interval is one minute.

Using the option to set a number of announcement messages enables you to choose how many messages can be sent to the waiting customer. After sending these messages, the conversation will remain in waiting strategy.

Maximum time for sending announcement messages is one hour, meaning that the maximum number of messages that can be sent to the customer is 60.

If a conversation waits for assignment for more than an hour, and if there is no maximum wait time set, the conversation will remain open, but no more messages will be sent to the customer.

Maximum wait time message

Maximum wait time is used to close the conversation after the time has passed and the conversation was not assigned to an agent. It can be set to the maximum of 60 minutes.

If the time is reached, the message will be sent to the customer and the conversation will be closed.

Typically, the content of this message will inform the customer of alternative ways to contact the business and get help at a different time.

Working hours

Set working hours for your contact center – you can do that for each separate day of the week.
Also, holidays can be set as non-working days and you can set them by exact dates which throws repetitiveness out of the window.

On this page you can set:

• Working hours
• Holidays
• Away message

A working hour period can be set per queue, meaning that one working hour period can be assigned to each queue.
This is especially handy for companies dealing with different markets in different time zones.
One working hour period can be set as default which means that all queues created afterward will have this period set without the need for intervention.

If you happen to change the default working hour period, previously created queues will retain the old setup.

Agents and Supervisors will be able to see all conversations and messages created outside working hours to follow up with customers.

When a customer sends a message outside working hours they will receive the auto-reply over the same channel that they used to contact you.

Away message

Define automated Away Messages for each queue where this message will be sent if a customer reaches out to your contact center outside the working hours.

Callback

The Callback feature allows customers to request a callback from the agent to the phone number associated with the conversation.

Callbacks aim to improve the customer experience by minimizing the frustration of long wait times or when calling a business outside of working hours. A callback can be triggered by a long wait time, a lack of available agents, or if the customer simply wants to be called back later.

Here are the 3 steps to enable callback for your customers:

1. Create the Callback configuration
2. Apply the Callback configuration
3. Set the action code to trigger Callback

Follow the Agent callback section for more information about the agent experience with callbacks.

Configure callback

To activate a callback, you first must configure the feature to achieve the desired system behaviors. Navigate to the Conversations module > Settings > click the Callback tile. Now, click the ADD NEW button.

A new screen opens open where you specify the desired selections for your callback configuration.

At the top of the configuration page, name the callback configuration so it is easy to identify it on later screens.

Next, choose the desired callback type:

1. Automated

• This option ensures that the callback process is completely automated. Using the existing routing and prioritization rules, the Conversations platform will select and assign an agent to the callback.
• The callback will automatically ring on the agent’s desktop or mobile app.
• When the agent answers, an outbound call is made to the customer’s callback number.
• If the customer does not answer, the call is assigned to the next available agent.

2. Manual

• The Conversations platform maintains a list of callbacks.
• Agents need to navigate to All Work > Callbacks and manually select the callback request to handle.

Additionally, the priority of the callback can be set based on one of two options. These are only available if the callback type is set to Automated.

• Inbound priority
  • Prioritizes incoming calls (direct or in a queue) over callback requests.
  • After all incoming calls have been handled, callbacks are assigned to available agents.
• Queue position priority
  • Calls are prioritized based on their place in the queue. The Conversations platform remembers the customer’s position in the queue and assigns them to agents in the requested order.
  • New incoming calls are considered to have lower priority.

You can configure the number of callback attempts. The configuration is universal across all callbacks regardless of where they are received. Callback retries ensure that multiple attempts are made to contact a customer who does not answer the call when the agent initiates the callback. 

There are two parameters available to configure:

1. Number of callbacks:

• Determines the number of times a callback will be attempted in the event a customer does not answer. Note that the first callback attempt is not considered a retry, and thus is not included in the number. For example, to ensure that 5 total attempts are made to contact the customer, you should enter the value of 4 in this field. This value ensures that after the first attempt fails, exactly 4 more attempts for a total of 5 attempts will be made. When the maximum number of attempts is reached, the callback is removed from the queue and closed.

2. Delay between callbacks:

• The time value in this field indicates the delay between unsuccessful retry attempts.

You can also configure a configuration message, which is played after the caller enters a response code that triggers the creation of a callback request. These messages can be either text-to-speech or pre-recorded audio file messages. The confirmation message is globally applied across all callback types and triggers for the given callback configuration.

• Text-to-Speech
  • Use this feature to craft a custom message.
    If you select text-to-speech, specify the following items:
  • Language - select one of the available languages
  • Voice - select one of the available voices
  • Speech rate - adjust the speed at which words will be spoken to be in line with the language and the message you are communicating
• Upload Audio File
  • Drag and drop or browse to add a pre-recorded audio file.

Apply configuration and set action code

For callback requests to be functional, you must link the callback configuration to a specific announcement message under the Waiting strategy and the away message under the Working hours sections. 

This is how you can link the two:

• Create a custom text-to-speech message, or upload a custom audio file
• Set the response code to trigger the callback
• Link the response code to the callback configuration created in the previous section
• Set the time to wait for a response from the user.

To enable Callback for calls in queues, set up the announcement message for the Waiting strategy:

• Navigate to the Conversations module > Settings > General setup > choose the Waiting strategies tab and open an existing strategy > click the Announcement message tab

Alternatively, click on the Waiting strategies quick link located on the Callback configuration page and then click Announcement message.

To enable Callback for calls received after business hours, set up the announcement message for the Waiting strategy:

• Navigate to the Conversations module > Settings > General setup> choose the Working hours tab and open existing configuration > click the Away message tab
• Alternatively, click on the Working hours quick link from the Callback configuration page

To set up Response codes, scroll down this page, click on the Add new button, and fill in the following:

• Number: Add the desired DTMF code to be applied to the Callback
• Action: Choose Callback as a value from the drop-down list
• Value: Select the callback configuration you want to apply

You can configure the waiting time for response/input from your end users in Wait for response codes field.

Callback requests list

To preview the list of callback requests, go to the Conversations tile on the left menu > choose ALL WORK > click Callback under Global Views.

There you can see all callback requests with predefined filters:

• Callback status = In queue
• Callback type = Manual
• Conversation status = Open, Waiting, or Solved

Callback related fields and their corresponding values are as follows:

• Callback Type: Manual, Automatic
• Callback Status: In Queue, Active, No reply, Done
• Callback Pending Since: Predefined list with a time period
• Callback Starting Date: Predefined list with a starting date, calendar input for start and end date

Statuses and event logs

This list is described in the Calls > Agent Guide > Callback > Callback statuses and event logs chapter.

Service-level agreement (SLA)

A service-level agreement (SLA) is the level of service you expect from a vendor. It defines the metrics by which a service is measured, and it takes into account remedies and/or penalties if the agreed-upon levels are not respected.

Main values of having the Service-level Agreement active are:

• Provide an opportunity to track the conversations SLA for your customers
• Actively tracking the SLA increases customer satisfaction as every conversation is handled in dedicated time to avoid any breaches
• Supervisors can faster recognize breached SLA in conversations and proceed to quickly resolve those conversations to avoid long SLA breaches
• Focus on the most important conversations based on the severity of the issue

Key benefits of SLA in Conversations:

• A faster resolution of the most important conversations, as well as urgent customer issues
• Conditional SLA policy based on variable attributes bringing personalized approach into handling conversations from time urgency point of view
• The ability to identify the severity of the issue and thus prioritize the conversation
• Transparent tracking of the response time by displaying the remaining SLA time left before the breach
• Improve supervisor management by quickly identifying the conversations with breached SLA in time

Configuration

To configure SLA, navigate to the Conversations module > Settings > and locate the Service-level Agreement tile.

Click on the card to manage your existing and create new SLAs. To add your first SLA, click the CREATE NEW button.

Here you need to fill in all the details about your SLA:

• Name your SLA policy (default name will be pre-populated)
• Set the status:
  • Status is Enabled by default. You can change it to Disabled after which this SLA policy is not valid anymore.
• Based on the validity period, once the SLA time is out, the policy will not be valid anymore.

Period

• Define the time period during which this SLA will be valid
• To update the validity period, click the three-dots menu on the right and then Edit
• Note that the dates you set define the period when the configured SLA policy is valid and applies to all conditions for matched conversations

Conditions

• Conditions are rules that you need to configure based on which the SLA policy will apply to those conversations
• You should set at least one condition

e.g., Set the SLA for all incoming conversations if ''Company'' is condition ''A''.

• In case you need to set conditions based on some custom company or user attributes, you can set such conditions here
• You can also apply +AND and +OR conditions to combine more attributes

The first SLA policy that fits the conversations based on the conditions set is the one that will apply to those conversations.

You can define which queues have the SLA policy set or ignored by assigning and applying the SLA policy based on a specific queue.

The other SLA policy is assigned to the conversation when it transfers from one queue to another and the second queue requires a different SLA policy. As a result, any prior breaches are recalculated using the newly allocated SLA policy.

Additionally, you can specify whether a queue or customer receives support 24/7 or just during working hours. By prioritizing tasks in this way, you can distinguish between those that are more urgent and require around-the-clock assistance and those that can wait until working hours.

Once a conversation is routed to a queue and has an assigned SLA policy, the following setup is added to the SLA logic if it is considering working hours or no time limitation (default):

• Working Hours indicates that the SLA needs to consider:
  • the actual queue of conversation
  • queue working hours setup
  • in case there is an only working hours setup, the current time is checked, and if it is outside of working hours and the current severity is set to apply only during working hours, all SLA counters for these conversations are put on hold
• No limitations means that the SLA can fully ignore any working hours and is always counting based on already existing logic:
  • if the severity setup is no time limitation, the SLA continues counting in already running timers

Severity

• The Severity level represents the complexity of the issue the customer is facing
• Every SLA policy must have at least Default Severity level set
• Based on your business needs and policies, you can define different levels of Severity

For every Severity level you need to set:

1. Name - This will be visible to Agents as an option to choose between severities for every conversation (Default Severity is set for every conversation that matches the SLA policy condition)
2. Times:
   • First response time
   • Next reply time
   • Total resolution time

It is mandatory to set at least one of these for each severity. Also, choose whether you want this SLA to apply Always or during Working hours only. This will depend on your business use case and what kind of support you have agreed upon.

Please note that this feature is in Early Access so if you wish to try It, contact your Account Manager to set it up.

Every SLA can have an unlimited number of severity levels so you can add as many as you need by clicking the +ADD SEVERITY button.

Example of severity levels:

Severity	Description
Default severity	Default severity that applies to every new incoming conversation fitting the SLA policy.
Severity 1	Could represent extreme infrastructure or product outage for many customers.
Severity 2	A certain product part is unusable for many customers.
Severity 3	A certain product feature is unusable for many customers.

This is how the resolution time is counted:

• The SLA counting starts from the first message the end user sends
• First response time represents the time between the first message from the end user appeared and the agent's response
• Next reply time is the time between the next (not the initial) message from the end user and the agent's response to that message
• Total resolution time is the time between the conversation start and when the Agent has set the status to Solved.
• SLA is paused every time a conversation is set to the Solved status

Note that each of these Times is configured in minutes.

After you have set the Period, Conditions, and Severity levels, you can save your SLA.

List of SLA policies

The list of SLA policies allows you to define the priority of your SLAs.

• The SLA policy on the top is the most important.
• Based on this logic, if you have two policies that have similar conditions fitting your conversations, the system will apply the first one on the list.

You can edit the list if you click the three-dots menu and then choose to Edit, Delete, Send to top or Send to position (enter the number to move the SLA to that position).

Note that if you delete your SLA, it will no longer be valid and it will not be applied to any conversations anymore.

Usage

Once you have set up everything, your agents will be able to see SLA details in their My Work and All Work panels. Follow the aforementioned guides to learn more.

Agent statuses

Agents communicate their availability by setting their status which can be changed automatically or manually.

There are 2 types of agent statuses:

1. Default statuses – Predefined and have automation logic based on the agent’s activity or workload.
2. Custom statuses – Allow you to create new statuses for your agents to fit your business needs.

Additionally, there are 4 groups of statuses:

1. Available - Indicates that agents are signed in and available to take on new conversations
2. Busy - Agents are unable to receive new but can receive transferred conversations.
3. Away - Agents are away from a computer and won’t receive new but can receive transferred conversations.
4. Unavailable - Agents are not signed in, and unable to receive any conversations.

Configuring and being aware of agents' statuses enables supervisors to better track how agents spend their time and get an insight into how to better utilize their agents.

Agent’s status is also connected to Auto Assignment, in a way that only agents in any status from the Available group of statuses will be a candidate to receive a new conversation.
Also, if the agent’s current workload is 90% (or higher) of their maximum capacity, they will automatically be transferred to the Full Capacity status.

When their current workload drops below their maximum capacity, they will be back in the Under Capacity status. 

Another important mechanism is the agent’s activity within the system. The system tracks whether agents are really in the status they set themselves in.

Example: If an agent sets themselves as Available but the system notices there is no activity in the browser (or the browser is closed), the system will automatically log them out to prevent further conversations assigned to them and inaccurate time tracking on Agent’s Utilization.

Voice and Video channel statuses

For the Voice and Video channel there is an additional logic involved. To receive, accept and have a conversation and later wrap it up, agents will undergo several statuses:

• Ringing – Call is not yet connected to the agent but they are prompted with the ringing dialog
• In a call – When the agent accepts the call
• Wrapping – After the call has been completed, agent has some additional time to write important notes or conclude the call if there was a resolution with the customer

Conversation forms

These are fully customizable forms that agents can assign to conversations (Digital, Calls, and Social Media) based on each conversation's parameters. Agents can fill these forms to collect information that can later be used for analysis and re-engagement.

To set up forms, you need to navigate to the Conversations module > Settings > select Conversation Forms.

There are multiple types of input fields that you need to fill in: 

• Text – simple text input
• Multi-line – larger texts 
• Checkbox  
• Dropdown – multiple levels of hierarchy are possible; you can create a new level using :: e.g. Clothing::Shirts will return results in a drop-down menu with the value 'Clothing' and sub-value 'Shirts' 
• Whole number  
• Decimal number
• Datetime
• Regex – a textual input that uses regular expressions to limit inputs from agents (e.g., So that they can only enter numbers in the input)

After you have created input fields, you can add them to your form.

If needed, you can mark each input as mandatory. Empty mandatory input fields in the form will prevent agents from marking the conversation as Solved or Closed. 

You can mark input as conditional, meaning that if some fields are set to a specific value, additional fields will be shown to the agent. Moreover, you can set any of these conditional fields as required so the agents know they need to fill them in.

When creating a form, users can use the same conditional input fields multiple times in the form. Regardless of the setup, the input field will be shown only once. With this improvement, we are making forms more flexible and fulfilling for users:

• In the configuration, the same conditional field can be placed multiple times in the form.
• Forms cannot be created with inputs like "Input A, Input A, Input A" because conditional fields must be utilized if they are added more than once.

When you have created a form, you need to set triggers. They define which conversations will have the newly created form displayed. The triggering mechanism is similar to the one on Routing. If no triggers are fulfilled, the default form is assigned. You can mark any form as the default one.

Note that only one form can be default at any given moment.

After you have added triggers, the form is ready to be displayed to agents. Also, forms will be assigned when conversations from bots or flows are transferred to an agent.

When they start a conversation, and it fulfills the parameters set in the triggers section, the form will be shown in the My Work panel so that the agent can fill in the data during or after the conversation with the customer. Agents can change the form for the conversation as needed.  

As mentioned before, agents will not be able to mark the conversation as Solved/Closed if they do not fill in the required fields.

When merging two conversations, form fields set in the initiator conversation (not in the recipient conversation) are merged.

You can use the assigned forms and values entered in input fields to filter out conversations in the All Work and the Reporting section. 

Macros

Macros are primarily used to help agents resolve repetitive tasks more quickly. These are previously made responses for agents to faster respond to customers if they often ask similar things or discuss the same topics, as well as create escalations to external sources, internal escalations within Conversations, etc. They simplify the agent's work and enable automation of the needed steps for the same use cases by simply choosing the appropriate macro where all steps are completed automatically.

Available actions to automate are:

• Status (change the status of conversations)

• Priority (change the priority)

• Forms (fill in the form values/choose the correct form to be displayed to the agent)

• Template (pre-fill the template in message composer)

To create a new macro, navigate to Conversations → Settings → click the Macros tile.

From there, you can:

• Create new macros
• Search for the existing ones
• Edit macros
• Add macro tags
• Duplicate
• Delete

When you click the CREATE NEW button, a new window opens where you can add the following macro details:

• Name
• Description
• Settings:
  • availability for:
    • All Agents (if you set it for all, then agents from all queues can use the macro)
    • Selected Queues (if you click this option, you can select specific queues that will have access to the macro, and agents assigned to that queue can use it)
  • Add tag (adding tags makes macros easier to find)
• Set actions:
  • Set conversation status
  • Set conversation priority
  • Populate form fields (any kind of form attributes (no matter from which form) you would like to fill out with specific values)
  • Conversation form (you can choose which form is displayed to the agent once they apply the macro)
  • Set template (you can set a template per channel in one macro that is an omnichannel and can be used in multiple channels; in that case, the system automatically detects which channel the agent is in, and based on that, applies the proper template (if the template for that channel is not set, it is not populated))
  • + ADD AN ACTION button

On the Macros page, you can filter them by:

• All
• Tags (these tags are not related to any other tags in Conversations since these are just macros tags that are used for faster searching or categorization of macros, e.g., escalation macros, Sales macros, etc.)
• Status

The sorting is done by:

• Macro name A-Z
• Macro name Z-A
• Date created - Newer first
• Date created - Older first

Macro Tags

Next to Macros, click the Tags tile to create new macro tags and/or edit/delete existing ones. Tags can be assigned to conversations to better categorize conversation topics or customer intent, and they are connected to the dashboard where Supervisors can analyze the number of conversations per specific tag.

The main purpose of macro tags is to group the related macros under the logical group from the supervisor perspective that could help agents in finding and utilizing the appropriate macro much faster.

Such tags can be used based on:

• customer process flow (e.g. Problem acknowledgment (tag1), Problem resolution postponed (tag2), Problem resolved (tag3), etc.)
• importance of customer (e.g. Gold customer macros, Silver customer macros, etc.)

Once the agent uses a certain macro, they do not need to remember its name, since they can simply use a tag suitable for the current situation they are handling, and based on that, get the needed macro faster because the list will be already filtered for the situation they are handling.

To create a new tag, click the CREATE NEW button, enter the tag name and click SAVE.

Users and permissions

In order to provide a more flexible approach to users and permissions, we have added four Conversations roles that can be set on the user’s profile: 

• Conversations Agent – users assigned to this role can handle conversations
• Conversations Manager – this user can manage conversations regardless to whom they are assigned 
• Conversations Analytics Manager – can check analytics and reports 
• Conversations Account Manager – users who can manage Conversations setup 

Note that these roles can be combined, which means that one user can have multiple roles assigned, thus fulfilling any specific permission needs the client might have. A user cannot have both Agent and Manager roles because the Manager role has all the permissions that the Agent role has and additional access rights.  

Every user assigned to any of the Conversations roles needs to have an active Named User License (NUL).

After you have set this up, the new user will get an email with login data and can successfully log in to the Conversations module.

Agents

To manage Conversations Agents, the Conversations Account Manager should navigate to Settings > Users tab. This section contains a list of all users where you can assign the Conversations role(s) for each user.

Add

To add a new agent, you need to create a new user in Settings > USERS and assign the Conversations Agent role to your agent.

Manage

To manage specific agent details, click on the agent’s name on the list of all agents.

The agent details page will open where you can do the following:

• Change Agent name
• Check Agent status (active, busy, offline, away)
• Enter title and phone number
• Enable/Disable Agent
• Check and manage user details, queues, capacity, call wrap-up, recording, call transcript, performance, and utilization

Moreover, you can assign agents to queues (a queue is a pool of agents that handle a certain topic). Click ADD QUEUES, select a queue and click ASSIGN. When assigned to a queue, the agent will see this queue and conversations within the queue in their ALL WORK panel.

You can also configure some of the conversation parameters on the agent level. e.g., you can change the value for agent wrap-up time for Voice calls.

Queues and routing

Conversations routing is a process of finding the right queue for new messages from where they can be further processed. The new message is evaluated against each route in routing and when the first route is matched, the message is added to the specified queue. If no route is matched, the message is added to a default queue.
The order of routes inside routing is important because the new message is compared to a rule in a given order in routing to find the first match.

Routing is a set of rules which determine the assignment of a new conversation to a particular queue executed in a specific order.

Route consists of a set of conditions that determine the destination queue and priority for a new conversation.

Conditions are expressions defined based on the message or customer attributes and conversations tags.

Queues

Queues are buckets or folders for conversations. Agents are assigned to pick up work from specific queues. New conversations are handled based on specific rules called routes. The purpose of queues is to categorize conversations. Supervisors can assign agents to certain queues, so conversations are managed in a timely manner by the most knowledgeable team members.

Important to note is that the Default queue is a system-defined queue that collects all unmatched conversations during routing. It is available to all agents and all agents are part of this queue automatically. All agents have access to conversations in the default queue and can reply to customers. The default queue can be changed in a conversation but it cannot be deleted.

Manage queues

Queue management inside the web interface is located within the Conversations module > Settings > General setup > Queues.

Previously created queues are listed on the Queues page, and this is where Supervisors can:

• Check the lists of created queues
• Create a new queue
• Manage existing queues

When you click on a queue name, the Queue detail page will open. Here you can find more information about the selected queue such as:

• Name of the queue
• List of agents assigned to the queue
• List of routes leading to that queue

For easier management, it is recommended to name the queue according to its purpose. For example, if you have frequent inquiries from premium customers you can name the queue 'Premium customers'. You can manage assigned agents and routes setup on the same page.

Create a queue

To create a new queue, click on the CREATE NEW button in the top right corner.
Every new queue is named ‘Queue #X’ by default where X is a random number, but the Supervisor can rename the queue at any point. Agents and routes should be assigned to created queues to make them functional.

When you click ADD AGENT, the list of enabled agents appears on the right side panel and any agent can be added to the queue. To add a route, the Supervisor can choose from the list of existing routes or create a new one and assign it to the queue.

Auto assignment on the queue level is mandatory for calls, so you should enable this for the default queue and/or all other queues you expect calls to be routed to.

Delete a queue

To delete a queue, navigate to the list of all queues, click the three dots, and then Delete. Only queues that don’t have an active conversation associated with it can be deleted.

Working hours

Set the working hours for this queue. Choose a suitable time period from the drop-down menu. Read more on how to create new Working Hours.

Automatic agent assignment for chats

The Automatic Agent Assignment is a process of distributing conversations between available agents based on their workload, capacity, and idle time. Supervisors can configure this on the queue level in the Conversations module > Settings > General setup > Queues.

There are two options you can choose for the Automatic Agent Assignment:

1. Assign conversations to any available agent – where agents are randomly picked out of all agents assigned to the queue the conversation is routed to
2. Assign conversations to the agent who last interacted with the customer – where previous interactions with the customer are taken into consideration creating a situation where agent might already have some context. When using this option, you can set an additional parameter: the period during which the agent had to have communicated with the customer to be considered for assignment.

For the second option, you can select one of the following:

• In the last 30 days
• In the last 60 days
• In the last year
• Ever

The process when a new conversation is assigned to a queue goes like this:

1. Automatic Agent Assignment process starts (only one can run at any given time)
   • On newly created conversations
   • Or when an agent changes their status to AVAILABLE
2. Availability is calculated
   An agent is marked as AVAILABLE when their status is available, and they have fewer conversations assigned in any status other than Closed, than their defined capacity
3. Workload and waiting time is calculated for every agent marked as AVAILABLE

In the Conversations statuses and capacity section, you can exclude or include statuses that you do not want to be counted in the capacity. The conversation statuses you select here will be counted into an agent's maximum capacity.

You can exclude Solved and/or Waiting status when calculating capacity. This means that agents will appear Busy while in the status you select in this box.

Additionally, use the Reset to default button on the far right to reset this configuration.

When agent occupancy has dropped, AA is triggered for that specific agent. The following areas can cause a drop in occupancy:

• Conversation unassigned
• Conversation closed
• Conversation merged
• Transition from included to excluded conversation status

When a conversation is routed to a queue and assigned to an agent, and in the meantime, the queue changes, the following happens:

• If the agent is assigned to the new queue, they are left assigned to the conversation after the queue change.
• If the agent is not assigned to the new queue, they are unassigned from the conversation, and the Automatic Agent Assignment starts (if turned on) on the new queue. If the Automatic Agent Assignment is not turned on, the system is waiting for agents in that new queue to take the conversation and handle it.

Also, if an agent was previously assigned to a conversation, they are not eligible for AA for the same conversation.

Bulk AA algorithm is triggered at the beginning of the working hours, which means that all conversations that arrived outside business hours will be assigned once the agents' shift starts. This algorithm sorts unassigned conversations by priority and looks at the createdAt that matches the agent queues and channels and the system tries to assign the conversations that correspond this logic.

Single AA algorithm has in mind the sticky agent first. If not found, the system looks for the best option (agent) in terms of workload and availability. This algorithm applies when a conversation changes its queue but also when a conversation is unassigned - it will exclude the previously assigned agent and look for a new one assignee. 

Workload is represented as the ratio of occupancy and capacity. If two agents are eligible to be assigned to a conversation, and Agent A has the capacity of 4 and occupancy (number of open conversations assigned to the agent) of 2, and Agent B has the capacity of 8 and occupancy of 3, the conversation will be assigned to Agent B. This is because Agent A has an occupancy/capacity ratio equal to 0.50 and Agent B has a ratio of 0.38. We can say here that Agent B has more capacity to handle the new conversation.

Waiting time is the time marked from the last conversation assignment to the agent, meaning that the agent that was waiting longer has more chance to get a new conversation

Those two values are combined into a formula that results in the agent to whom the new conversation is assigned. This Automatic Agent Assignment logic applies to chat conversations only.

Automatic agent assignment in action

If the sticky agent option is not selected, then the system applies the Weight Sum Method. The following showcases how that is calculated. 

A list of all AVAILABLE agents in the queue is created, and every agent has two attributes assigned:

1. Workload

                   ([occupancy_LiveChat]                [occupancy_{LiveMessaging}]
              __________________     x100 +     _____________________   x100 )
             ([capacity_LiveChat]                 [capacity_{LiveMessaging}]           
    Workload= ^{____________________________________________________________________________________}

                                       2

2. Unserved Time
   UnservedTime = CurrentTime - TimeOfLastAssignment

Agent	LiveChat Capacity	LiveChat Occupancy	LiveMessaging Capacity	LiveMessaging Occupancy	Workload	Unserved Time (seconds)
Agent 1	10	5	20	4	20	10
Agent 2	5	1	10	5	35	200
Agent 3	20	15	5	1	48	300

Weights are added to attributes, 0.5 for Workload and 0.5 for Unserved time, which means that both impact the overall result equally.

For any agent to be selected, Workload should be as small as possible, and Unserved time as large as possible. Workload is treated as a “non-beneficial attribute”, and Unserved time as a “beneficial attribute”.

Agent	Workload (weight 0.5)	Unserved Time (weight 0.5)
Agent 1	20 (non-beneficial)	10
Agent 2	35	200
Agent 3	48	300 (beneficial)

For agents on the list, the minimum workload (non-beneficial attribute) of all agents is divided by the workload of each agent.

Agent	Workload (weight 0.5)	Unserved Time (weight 0.5)
Agent 1	20 ÷ 20 = 1	10
Agent 2	20 ÷ 35 = 0.57	200
Agent 3	20 ÷ 48 = 0.42	300

For agents on the list, the Unserved time values are divided by the highest Unserved time value (beneficial attribute) of all agents on the list.

Agent	Workload (weight 0.5)	Unserved Time (weight 0.5)
Agent 1	1	10 ÷ 300 = 0.03
Agent 2	0.57	200 ÷ 300 = 0.67
Agent 3	0.42	300 ÷ 300 = 1

Divided values are then multiplied by 0.5 (weights for Workload and Unserved time).

Agent	Workload (weight 0.5)	Unserved Time (weight 0.5)
Agent 1	1 x 0.5 = 0.5	0.03 x 0.5 = 0.02
Agent 2	0.57 x 0.5 = 0.29	0.67 x 0.5 = 0.34
Agent 3	0.42 x 0.5 = 0.21	1 x 05. = 0.5

Performance score for each agent on the list is then calculated by summing up the values from previous steps.

Agent	Workload (weight 0.5)	Unserved Time (weight 0.5)	Performance Score (Workload + Unserved Time)
Agent 1	0.5	0.02	0.52
Agent 2	0.29	0.34	0.63
Agent 3	0.21	0.5	0.71

The agent with the highest number wins and the conversation is assigned to them (as shown in the table above).

Automatic agent assignment for calls

Besides standard automatic agent assignment which applies to chats, you can also set it up for calls. The logic is a little bit different here.

This is what the process looks like when a new conversation is assigned to a queue:

• The automatic agent assignment process starts (only one can run at any given time)
• It is applied to newly created conversations
• Or when an agent changes their status to Available

Note that for calls, availability is taken into consideration. An agent is considered available to take on new calls when they set their status to Available, and they have fewer conversations assigned in any status other than Closed, than their defined capacity. 

Workload and waiting times are calculated for every agent who is in the Available status.

Routing

As mentioned in the beginning, Routing is defined as a set of rules which determine the assignment of a new conversation to a particular queue executed in a specific order.

With route management, you can define business rules according to which incoming customer requests will be assigned to queues and agents for the most effective resolution.

Create a Route over Web Interface

To create a route over web interface, you need to set up rules.

The rules are customizable and can refer to (e.g.,):

• Message attributes such as channel, sender, receiver, or message content
• Customer attributes that you specified in the People module (e.g., name, city, purchase power, etc.)
• Conversation tags assigned manually or through automated flow
• IVR inputs collected to a variable through automated flow
• Custom data from Web and In-App Calls and Video 

Only when all the above-mentioned parameters are defined, you can create a new route and it will be shown in the list of all routes.

Any route can be set as Enabled or Disabled (default status is Enabled).

In the table below you can find the options you can use to set up routes.

Category	Existing attributes	Operators	Values
Search	N/A
Conversation attributes	channel	is is not	Select channel
	content	is is not contains starts with	Free input
	conversation tags	in list not in list	Tags dropdown (you can select only one)
	from	is is not contains starts with	Free input
	is visitor	is is not	True False
	to	is is not	Sender dropdown
Standard person attributes	address	is is not contains starts with	Free input
	birthDate	is is not before after before or on after or on	Date picker
	city	is is not contains starts with	Free input
	country	is is not contains starts with	Free input
	customer tags	contains does not contain	Free input
	externalPersonId	is is not contains starts with	Free input
	firstName	is is not contains starts with	Free input
	gender	is is not	Male Female
	integrations	is is not contains starts with	Free input
	lastName	is is not contains starts with	Free input
	middleName	is is not contains starts with	Free input
	modifiedFrom	is is not contains starts with	Free input
	nickName	is is not contains starts with	Free input
	preferredService	is is not contains starts with	Free input
	type	is is not contains starts with	Free input
Custom person attributes	N/A
Standard company attributes	accountManager	is is not contains starts with	Free input
	country	is is not contains starts with	Free input
	customerStage	is is not contains starts with	Free input
	domains	contains does not contain	Free input
	industry	is is not contains starts with	Free input
	name	is is not contains starts with	Free input
	notes	is is not contains starts with	Free input
	segment	is is not contains starts with	Free input
	tags	is is not contains starts with	Free input
	vatNumber	is is not contains starts with	Free input
Custom company attributes	N/A
(Channel specific) Apple Messages for Business attributes	device agent	is is not contains starts with	Free input
	group	is is not contains starts with	Free input
	intent	is is not contains starts with	Free input
	locale	is is not contains starts with	Free input
(Channel specific) Email attributes	email cc	contains does not contain	Free input
	email from	is is not contains starts with	Free input
	email subject	is is not contains does not contain starts with	Free input
	email to	in list not in list	Sender dropdown
Custom attributes	N/A

Destination Queue over Web Interface

Setting up routes means that when a new message arrives, the system will automatically check if message parameters comply with any of the rules specified within the route and will assign conversation according to the rules that match the defined destination queue.

Priority over Web Interface

If message parameters are matched with certain route rules, conversation will get a priority defined within that route setup. According to assigned priority, conversation will be shown in the list of All Conversations. Priority can be changed manually within the conversation details at any point.

Set Conditions over Web Interface

Conditions are a set of criteria that will be checked when there is an incoming conversation. Based on those, a conversation will be added to a specific queue.

Set Route Order over Web Interface

Considering that several different routes can be set at the same time, you can set up route ordering.
When there is an incoming message, parameters will be checked, and message will be assigned according to the first route that matches against parameters.

Imagine you need to set two routing rules – one for Spanish speaking customers and another one for premium customers.

• Rule 1: If the message comes to the destination number 123 and the person sending the message has been marked as Spanish speaking within the Target module, route this message to the Spanish queue.
• Rule 2: If message comes to the destination number 123 and person sending message has been marked as premium customer within the Target module, route this message to the Premium queue. 

Now each queue has a team of agents assigned to it:

• Spanish queue – Ten agents that can read and write Spanish but are juniors and don’t know anything about premium customers.
• Premium queue – Three agents who speak Spanish and English and know everything about premium customers.

What you want to make sure is that messages from your premium customers end up in the Premium queue and not in the Spanish queue. That’s why you need to set up the routing priority. The premium route should be priority number 1 and Spanish route priority number 2.

To re-arrange routes, drag and drop them according to their priority.

Enable or Disable a Route over Web Interface

All created routes can be enabled or disabled based on your needs. In case a route is  set as disabled, incoming messages will not be checked against conditions in disabled routes.

Configure Routing for Live Chat

This section explains what can be configured for Live Chat in Routing to assign specific requests to certain Agents queues.

To configure routing for Live Chat, navigate to the Conversations module > Settings > General setup > Routes > CREATE NEW.

Available fields that you need to set are as follows:

• To – Destination to which inbound conversation messages are sent. This field accepts widgetID for Live Chat routing. Widget ID can be taken from the widget edit page and is unique for each widget configuration.

• Channel – Defines if all inbound conversations from the specific channel shall be sent to a certain queue. For Live Chat applicable value is Live_Chat

• Person attributes – All Person attributes are applicable for Routing, however only if the session is coming from an authenticated (logged in) customer and if we have a Person associated with a key identity (email address, in this case).

• Authenticated customer/ anonymous visitor – can be used to differentiate which customer support queue should take on the on auth. customer or visitors. The parameter is Visitor defines if the inbound conversation comes from an anonymous visitor. If set to false, then it’s treated as inbound conversation from auth. customer.

Manage automations

Use automations to reduce manual and repetitive work and increase efficiency in your contact center. Check out the below mechanisms we have put in place to help you out in automating your contact center.

Workflows

Workflows are easy-to-use automations created within a simple “if-this-then-that” editor.

You can set up workflows in the Conversations module > Settings > Automations. To manage these subsequently, simply navigate back to Settings > Automations.

There are two types of workflows:

1. Time-based – triggered after a certain time period. E.g., if a conversation has been in the Solved status for more than 24 hours.
2. Event-based – triggered right after a certain event occurs. E.g., when a conversation status changes to Solved.

A workflow consists of:

• Trigger(s) (mandatory) – refers to a time period or an event that triggers the workflow. You can set multiple triggers in a single workflow. If you have set up multiple triggers in a workflow, they will be tied to an ''OR'' operator, meaning that if any trigger is performed, the workflow will activate.
• Conditions (optional) – these are additional statements that allow you to select the actions that should be performed on different entities.
• Action(s) (mandatory) – changes that this workflow will perform. You can add single or multiple actions. If you add the “Close conversation” action, bear in mind that no other actions can follow this one. Add all other actions you need before you add the ''Close conversation'' action.

To put it simply, when certain triggers happen and conditions are met, actions will be performed.

You can order created workflows, meaning they are activated one after another and the result of one workflow can trigger one or more workflows later on the list.

Find available triggers here:

Trigger/New trigger name	Operator	Parameters	Type	Description
Customer reply is pending for / Customer did not reply for	More than	Days, hours, minutes (all set to 0 by default)	Time-based	Triggers a workflow when a customer does not reply for a set period of time.
Agent reply is pending for / Agent did not reply for	More than	Days, hours, minutes (all set to 0 by default)	Time-based	Triggers a workflow when an agent does not reply for a set period of time.
Solved conversation is unmodified for	More than	Days, hours, minutes (all set to 0 by default)	Time-based	Triggers a workflow when a conversation has been solved for a set period of time AND if there were no changes in the conversation.
Conversation is solved for	More than	Days, hours, minutes (all set to 0 by default)	Time-based	Triggers a workflow when a conversation has been in the Solved status for a set period of time, regardless if there were any changes.
Conversation status changed	To	Open, Waiting, Solved	Event-based	Triggers a workflow when the conversation status is changed to the set one.
Conversation form changed	N/A	N/A	Event-based	Triggers a workflow when an agent changes the conversation form or if the change happens automatically.
Conversation queue changed	N/A	N/A	Event-based	Triggers a workflow when the conversation is moved from one queue to another.
Conversation tag changed	N/A	N/A	Event-based	Triggers a workflow when tags are added or removed in a conversation.
Conversation customer changed	N/A	N/A	Event-based	Triggers a workflow when an agent unlinks a customer from the conversation.
Conversation channel changed	From/To	Any, SMS, Viber, Messenger by Facebook, WhatsApp, Email, RCS, Apple Messages for Business, Line, Google's Business Messages, Telegram, Calls, Twitter, Instagram, KakaoTalk	Event-based	Triggers a workflow when the first message over the second channel in the same conversation is sent.
Note is created	N/A	N/A	Event-based	Triggers a workflow when an agent adds a note.
Outbound agent message is sent	N/A	N/A	Event-based	Triggers a workflow when an agent sends a message.
Inbound message received	N/A	N/A	Event-based	Triggers a workflow when an agent receives a message from a customer.
Survey feedback received	With score	Happy, Not happy (both can be picked)	Event-based	Triggers a workflow when a customer sends survey feedback (e.g., send a message to Slack). It can be used in combination with the existing workflow/automation conditions and actions. Works with the text channel surveys, however, if you also configure a follow-up question in the survey, both the survey score and the follow-up answer need to be received for the trigger to be activated.

Find available conditions here:

Condition	Operator	Parameters	Description
Queue	Is on the list, is not on the list	Multiselect of all existing queues	If you use the "Conversation queue changed" trigger, the condition refers to the destination queue.
Conversation direction	Is	Inbound, outbound	Inbound conversations are the ones initiated by a customer, and outbound ones by an agent.
Conversation tag	Is on the list, is not on the list	Multiselect of all existing conversation tags	If the conversation has any or none of the tags selected from the drop-down.
Conversation channel	Is, is not, is on the list, is not on the list	For is/is not a single-select option: Internal, Multichannel, Chat, Email, Messenger by Facebook, Google's Business Messages, Apple Messages for Business, Telegram, Calls, Twitter Direct Messaging, Viber, LINE, Instagram Messaging, SMS, WhatsApp, RCS. For is on the list/is not on the list: multiple-select option of all channels listed above.	If the conversation is/is not ongoing over the selected channel; If the conversation is/is not ongoing over any channel selected from the drop-down. Note: At least 2 channels need to be used in order for the "Multichannel" condition to be fulfilled.
Conversation form	Is, Is on the list, Is not on  the list	For is a single-select option of all existing forms; For is on the list/is not on the list: multi-select of all forms.	If a conversation has a selected form assigned to it: If any of the Conversation forms is/is not assigned to the conversation.
Message	Is	First in the conversation	If a message is the first message sent in the conversation (by customer or agent).
Hours since assignee updated	Greater than	6,12	Denotes when was the last time the agent updated the conversation.
Email subject	Contains any, does not contain	Tag lookalike string adding	If the email subject contains or does not contain any of the defined strings.
Agent email address	Is on the list	Multiple-select option of all agent addresses	If the email sent by a customer is sent to an agent address selected from the drop-down.
Agent domain	Is on the list, is not on the list	Is: A single-select option of all domains Is on the list/is not on the list: A multi-select option of all domains	If the email address the agent is using has a domain that was selected from the drop-down; If the email address has any or none of the domains selected from the drop-down.
Agent status	Is on the list, is not on the list	Active, Busy, Offline, Away	If the agent currently assigned to the conversation is/is not marked with any of the statuses selected from the drop-down.
Agent	Is	Assigned, Unassigned	If the conversation is/is not assigned to an agent.
People tag	Is on the list, is not on the list	Multi-select option of all defined tags	If the customer in the conversation has/does not have any of the tags assigned in the drop-down.
Person country	Is on the list, is not on the list	Tag lookalike string adding	If the customer in the conversation has/does not have a country attributed in the People data platform match with any of the countries entered.
Company	Is on the list, is not on the list	Multi-select of all companies	If the customer in the conversation is a match to a company stored in the People data platform and that company does/does not match with any of the companies selected from the drop-down.
Company tag	Is on the list, is not on the list	Multi-select option of all tags	If the customer in the conversation is a match to a company stored in the People data platform and the company has/does not have a tag match with any of the selected ones from the drop-down.
Company segment	Is on the list, is not on the list	Tag lookalike string adding	If the customer in the conversation is a match to the company stored in the People data platform and that company has/does not have a segment marked with any of the segments entered.

Find available actions here:

Actions	Parameters	Description	Note
Send a message to the customer	Channel (hardcoded to the last used channel) Message (1000 chars) - no placeholders	Sends a message to the customer that participated in the conversation that triggered the workflow, over the last channel that the customer used. The content of the message needs to be manually added.	The message is sent over the channel that was used for the last inbound message, not the last used channel overall.
Apply tag(s)	A multi-select option of all tags	Adds selected tags to the conversation.
Remove tag(s)	A multi-select option of all tags	Removes selected tags from the conversation.
Email the customer	Email subject (no placeholders) Email content (no placeholders)	Sends an email to the customer that participated in the conversation that triggered the workflow.	The last message in the conversation has to be an e-mail, otherwise, this action will not be executed.
Email the external recipient	From: A drop-down with senders registered for this purpose. To: Tag lookalike string adding. Email subject Email content (no placeholders; basic formatting options)	Sends an email to any defined recipient(s), regardless if they were involved in the conversation that triggered the workflow, or not. The sender's email address used to send these emails must be manually set as a no-reply address.
Email transcript	From: A drop-down with senders registered for this purpose Email subject	Sends the transcript of the conversation that triggered the workflow, using the sender's email address that must be manually set as a no-reply address.	The customer must have a defined email address in the People data platform.
Notify by email	From: A drop-down with senders registered for this purpose To: Tag lookalike string adding Email subject	Sends an email notification using the sender's email address that must be manually set as a no-reply address. Recipients need to be manually defined.
Message on Slack	Type: A drop-down with two options (Select recipient from conversations - shows a drop-down with form fields, free entry of recipients; (Manual) - shows 2 To fields (Channels and Users) Message: Standard placeholder picker	Sends a Slack message to a person or a channel defined by the user, or to Conversation users subscribed via Infobip Tools. To be able to use this action, Slack for Conversations integration on Exchange must be enabled.
Set conversation status	Drop-down with an option to mark conversations as Solved	Changes the conversation status to Solved.
Set conversation priority	Drop-down with priorities (low, normal, high, urgent)	Sets the conversation priority to the chosen one.
Unassign agent	N/A	Unassigns agent.
Email survey to the customer	N/A	Sends an email with the link to the CSAT survey.
Close conversation	N/A	Closes the conversation. No other action can be added after this one.
Call API	Method URL Content type Headers Body	Triggers Infobip and third-party APIs. When a customer sends a message and a conversation is created, Infobip needs to know if the customer reached out to Support or Marketing. When a conversation is created, the workflow is triggered to check to which sender the inbound message is sent. If the message is sent to a Support sender, the Call API action is triggered which updates the person's attribute with the "SUPPORT CUSTOMER" value. If the message is sent to a Marketing sender, the person's attribute is updated with the "MARKETING CUSTOMER" value.

Call API

The Call API action in Workflows, as mentioned in the table above, triggers Infobip and third-party APIs when a customer sends a message to differentiate if they reached out to Support or Marketing. It consists of the following parameters:

• Method
• URL
• Content type
• Headers
• Body

Method

The Method parameter is used to specify the type of HTTP request you want to make to the endpoint. The method parameter indicates the desired action to be performed on the resource identified by the URL.

• GET: It is a read-only method and does not modify the resource. For example, when you want to retrieve information about a user from an API, use the GET method.
• POST: Used to submit data to the server to create a new resource. It is often used for creating or submitting data, such as submitting a form or creating a new user. When you want to create a new resource, use the POST method.
• PUT: Used to update an existing resource on the server. It replaces the entire resource with the new data provided. For example, if you want to update the details of a user, use the PUT method.
• PATCH: Similar to the PUT method, but instead of replacing the entire resource, it applies partial updates to the resource. It allows you to update specific fields or properties of an existing resource.
• DELETE: Used to delete a resource from the server. When you want to remove a resource, you would use the DELETE method.

URL

The URL in an API Call is the specific address where the API is located and the desired resource or action is identified. It consists of the base URL (API location) and the path (resource/action within the API). The endpoint uniquely represents the location within the API that you want to interact with.

For example, https://api.example.com/users represents the endpoint for the 'users' resource in the API.

Content Type

The Content Type in an API Call refers to the format of the data being sent or received, and it specifies how the data should be interpreted. It includes the following options:

• RAW
• JSON (application/json)
• Text (text/plain)
• XML (application/xml)
• URL-encoded (application/x-www-form-urlencoded)
• Form Data (multipart/form-data)

Setting the correct content type is important to ensure the data is processed accurately by the API.

Headers

Headers in an API Call are the key-value pairs that provide additional information in the HTTP request or response. They include details like authentication credentials, content type, caching directives, and more. Headers help the client and server communicate effectively and handle various aspects of the API interaction.

Body

The Body refers to the data transmitted in the HTTP request or response. It can contain various formats as explained under the Content Type. The Body allows for exchanging and manipulating data between the client and server and it can be set using key-value pairs or as text using the editor option.

Use ordered lists in workflows

You can drag and drop workflows to organize them in ordered lists. The system will then execute workflows according to their order, meaning that all actions from the first workflow are executed first, then all actions from the second workflow, and so on.

This helps you create more specific use cases and prevents some problematic cases such as random workflow execution and cycles.

Voice of the customer

This dashboard offers insight into customers’ feedback that they provide after a conversation with an agent over surveys. This also ties in very closely with Analytics and the overall satisfaction the customers feel about Conversations and the services provided.

Surveys

Surveys can help you automatically collect Customer Satisfaction Scores.

These can help in recognizing more or less satisfied customers, to adjust the tone of ensuing communication, and improve the overall quality of your contact center.

Survey is triggered when a conversation status is changed to Solved. Shortly after that, the customer will receive a message over the channel that they used last in their conversation. Message contains questions about their satisfaction with the current issue and whether it was resolved. The questions are predefined but you have the option to edit them.

There are two possible answers: happy and not happy.

Supervisors can define a follow-up question requiring additional feedback that customers may provide. Scores and comments are visible in the agent panel and in the Voice of the Customer dashboard.

Along with the trigger saying that the conversation status is changed to Solved, you can set the time span between two surveys. This period starts after one survey has been sent to the customer. A new survey cannot be sent before this period elapses. This is a very important parameter that will protect customers from being spammed with multiple surveys within a short period of time.

Sentiment analysis

With sentiment analysis scoring, you can get feedback on your customers' satisfaction. Manage your agents' performance in a streamlined way and improve customer satisfaction faster.

Sentiment analysis uses natural language processing (NLP) to try to interpret customers’ feelings within messages and conversations. During a conversation, sentiment is analyzed in real time. That way Agents and Supervisors can track changes in the sentiment from the start to the end of the conversation.

This feature analyzes every message sent by the customer and scores it on a scale from -1 to +1 (-1 being the lowest score, and +1 the highest). The final sentiment score is determined as the average sentiment of all messages that contributed to the conversation. Messages sent later in the conversation have a higher weight since they show the latest sentiment of the customer. 

The scoring follows this logic:

The screenshot below shows what the sentiment looks like in the agent panel:

To monitor how Agents handle their conversations, Supervisors can dive into ongoing or past conversations. Following on this information, they can advise Agents on how to improve their interactions with customers and increase the satisfaction score.

To enable sentiment analysis for your conversations, navigate to the Conversations module > Settings > locate the Sentiment tile and turn ON the toggle for Conversations. When you activate this feature, we encourage you to share your feedback with us on the sentiment score accuracy. This will help us improve and further develop the Sentiment Analysis feature.
To leave your feedback, click the feedback button in the web interface located in the top right corner.

Self-service automation

To optimize resources in your contact center, use automated flows or chatbots to avoid repetitive work so your agents can focus on more complex tasks. Automation is available over our Chatbots, Flow builder in the web interface or over Flow API.

Self-service over Moments and IVR over Flow

Moments and IVR over Flow let you create automated flows to engage your customers and come to a satisfactory resolution in no time, thus avoiding any repetitive work for your agents.

Create Flows

Navigate to Moments and click CREATE FLOW. Select a predefined Flow template or choose Start from Scratch to build your own.

You can choose one of the following options to start your flow:

• Inbound message – inbound messages through a channel, using a 2-way number or creating your own content
• One-time audience – you know your audience in advance and want to invite them to a conversation
• Flow API – audience is added to Flow via API
• People events – people are added to Flow after it starts, based on their profile changes

In the example below, the Flow is started by sending bulk messages to customers for special offers. If they are interested and wish to receive more information they can connect with an agent by replying YES.  

To enable the Flow to transfer a customer to a real agent, you need to specify the Start a conversation action. Any conversation transferred to agents has an option to get a tag for an effective routing or topic hint to agents.

After the conversation is transferred to an agent, all messages exchanged between Flow and the customer are shown in the conversation details so the Agent can see the customer intent.

Create Outbound IVR over Flow

Navigate to the Moments module and click CREATE FLOW.
You can use a predefined Flow template or choose Start from Scratch to build your own and select Predefined Audience as your entry point. Existing users in the People module, either grouped or tagged will enter the flow.

In the example below, calls are placed to a predefined list of phone numbers when flow is initiated. An IVR message is played to the callee and later their inputs are collected to a variable. 
Depending on the variable value, the flow will transfer the call to a real agent. To make this happen, you need to specify the Start a Conversation action.

Having in mind the number of agents who will be answering calls, note that you should adjust sending speed. If there are no available agents at that moment, waiting strategy would be played to the caller.
Also, you can tag any conversation that you want to transfer to an agent. Use tags to hint the conversation topic to agents.

Both collected inputs and tags can be used for effective routing of conversations. 

Self-service over Answers

Create chatbot

To create a chatbot, navigate to the Answers module > select Chatbots > and then click on the New chatbot button.

Chatbots always start with inbound messages. You can create simple FAQ types of scenarios or more advanced AI-based chatbots. To enable the transfer of a customer to a real agent, you need to specify the Redirect to agent action in Answers. Any conversation transferred to agents has the option to get a tag for an effective routing or topic hint to agents.

Chatbots have the ability to automatically transfer customers to agents if they are not able to resolve the inquiry.

After the conversation is transferred to an agent, all messages exchanged between the bot and the customer are shown in the conversation details so the Agent can see the customer's intent.

View Chatbot Conversations

Chatbot conversations are conversations or parts of conversations exchanged between end users and an automated bot. Only chatbot conversations that have Start a conversation element defined will be visible in the Conversations module. All chatbot conversations will have a chatbot agent assigned. The chatbot name will be equal to the name of the Flow used to execute the chatbot conversation. To view chatbot conversations, Supervisors need to go to Conversations > All Work and select Chatbots view.

Monitoring chatbot conversations helps Supervisors identify bottlenecks in the chatbot setup and improve the user experience. It also helps measure how many conversations still end up transferred to agents and for which topics specifically. This helps predict further workload so the supervisor can adjust agent shifts and training accordingly.

In case chatbots are unable to resolve customer queries, supervisors can select the Agent takeover action to transfer the conversations to an agent and assist the customers in a timely manner.

Connect external bots

When you use an external bots solution to automate a part of the user journey, you can still connect it to the Conversations solution by triggering the transfer to agent action. The action will move the bot-to-customer conversation to the agent along with all the conversation history.

Bots are similar to Agents in the sense that they can have a conversation with customers by sending and receiving messages through an API endpoint.

Set up external bot

To configure a bot, go to the Conversations module > Settings > General setup > Chatbots > click on the Connect Chatbot button on the far right and define the following as an admin:

• Bot name - A unique name that will be visible in the bot conversations queue. It’s different from the existing Flow or Infobip bots.
• Bot URL - The URL where all inbound messages will be forwarded to until the bot triggers the Transfer to the agent action.
• The number for which the bot is configured - Any inbound message from customers to this number will be forwarded to the bot.
• Conversation history - If checked, messages exchanged between the customer and the bot will be visible to agents after they take over the conversation. Otherwise, the Agent will not be able to view messages exchanged between the customer and bot.
• Whether the bot is active or not

Optionally you can define the Session timeout parameter. This timeout is the time period in which the bot conversation session will expire if there are no messages exchanged by the end user.

Receiving Messages

All inbound messages received on the defined destination number assigned to an active bot will automatically be forwarded to its webhook URL via the POST HTTP method with the conversationId parameter. 

Based on the threading mechanism, a new conversation is created or customer messages are added to an ongoing conversation.

Conversations are automatically assigned to the Bot. Bots are managed as special types of agents by the system.
When a human agent takes over the conversation, all new customer messages are not sent to Bot webhook URL but rather shown to agent only.

Sending Bot Messages

To send messages from a bot, use our standard Conversation Messaging API. To do this, you must have the conversationId in the URL path and an identifier x-agent-id in the header. The conversationid parameter is used to keep track of messages exchanged between the end user and bot and later agent, while the  x-agent-id parameter is a bot identifier.

Transferring Conversation from Bot to Agent

There are two ways you can do this:

1. Conversation can be transferred to an Agent by invoking the route endpoint.
   It will remove the bot as an assignee from the conversation, execute routing logic, and find the appropriate queue if any. If you’ve configured the auto-assignment, the conversation will be assigned to the first available Agent.
   The bot won’t receive any further inbound messages for this conversation and it won't be able to send any outbound messages.

2. Conversation can also be transferred to the agent by invoking the update conversation endpoint and passing the new agentId parameter. This way routing is avoided and direct assigning is committed.

Intent

You can set the customer intent by adding a tag to the conversation which can later be used for routing.

Refer to the Add Tag to Conversation article for more information.

Conversation Metadata

Use Conversation Metadata to store and manage additional information. Conversations metadata provides context for Agents when taking over a conversation from a bot. It’s displayed in the Agent Panel so the end user doesn’t have to repeat the entire conversation they had with the bot when switching to an Agent.

Here’s an example of conversation metadata:
{ "Manufacturer": "Mazda", "Model": "CX-5", "EngineType": "Diesel", "EnginePower": 90.0 }

Refer to the Metadata article on our API docs for more information.

Biometry authentication

Customer authentication is a common part of everyday processes in contact centers. It can be used to verify the identity of both existing and new clients. Using biometry for client authentication significantly improves reliability of positive identification, improves the overall process and customer experience.

Biometric authentication can be used in Conversations (when interacting with agents) and Answers (when interacting with chatbots, before switching to an agent).

To use biometric authentication, you need to complete the enrollment process Know Your Customer (KYC). During the process, customers must provide a scanned ID with a picture and take a selfie. To confirm the customer’s identity, data extracted from the document must match the data available in People.

After confirmation, customers will be able to use selfies as their authentication method.

When using OTT channels such as WhatsApp, Viber, and others, the agent sends a message with the URL to the customer. The link leads to the authentication service that guides them through the process of scanning their ID and taking a selfie.

PREREQUISITES 

The prerequisite for using KYC is to have your customer’s data in People.

1. Log in to the web interface and navigate to People > CREATE PERSON PROFILE.
2. Enter contact information and attributes. Enter Standard attributes and Custom attributes.

Custom attributes are:

First name	mrzFirstName
Last name	mrzLastName
Date of birth	mrzDateOfBirth
Document ID	mrzDocumentId
Document expiry date	mrzDocumentExpiryDate

bioReferenceiD as custom attribute is automatically generated.

During the KYC process the data will be read from the document’s MRZ section. It should contain the same five fields to be matched to the fields already in People.

Only if all data matches, the customer will be considered as authenticated and they will be able to use selfies as their only authentication method in future communication.

Authentication Steps

1. When the conversations starts, the agent sends the authentication link.

2. Customer receives the URL and proceeds to authentication. When the customer starts the authentication process, the agent will see that the authentication is in progress.
3. After the customer has been authenticated, the conversation continues.