The elements of a conversation
The concept of a conversation is central to Unblu. To understand how Unblu works, it’s essential to have a solid grasp of the various elements that make up a conversation.
For information on configuring conversations, refer to the Configuration properties reference.
Overview
All communication in Unblu takes place within the context of a conversation. A conversation begins before there are any participants in the conversation, and a number of factors determine how Unblu creates a conversation.
First, Unblu ascertains the type of conversation to be created. This is referred to as the conversation’s engagement type and it’s used to determine which conversation template to base the new conversation on.
Next, Unblu identifies who may participate in the conversation. A conversation has two main participants: a visitor, and an agent. The main visitor is referred to as the context person; the main agent is the assigned agent. (There may also be other participants, as explained below in the section Conversation participants.)
The person or people who don’t initiate the conversation receive an invitation to join the conversation. If the conversation is initiated by a visitor, they’re the primary participant on the visitor’s side. In such a case, the invitation is sent to the conversation’s Recipients, that is, those agents who have the authorization and/or skills required to join the conversation. The agent who accepts the invitation first and joins the conversation becomes the conversation’s Assigned agent.
Depending on the configuration, participants may leave a conversation and return to it later. Once one of the conversation’s participants is present in the conversation, Unblu opens a conversation session. The session is maintained until there are no participants present in the conversation.
Engagement types
When creating a conversation, Unblu uses the following factors to determine the conversation’s engagement type:
-
The person type of the person who initiates the conversation: either agent or visitor.
Who initiates a conversation determines whether the conversation appears in agents' queues. Only visitor-initiated conversations are queued.
-
The person type of the central person, the person that the conversation is centered around: again, either agent or visitor.
The central person is a mandatory participant in the conversation.
-
The type of media initially used in the conversation
-
Whether the conversation is initiated in a standard Unblu UI or via the API
The engagement type determines the conversation template for the conversation. It’s only taken into account when first establishing a conversation. At that point, the configuration of the conversation template is linked to the conversation. If the conversation template’s configuration inheritance switch is set to on, changes made to the configuration of the conversation template are propagated to all ongoing conversations that were created from it. If the configuration inheritance switch is set to off, on the other hand, the conversation’s configuration is independent of the conversation template, and changes made to the template don’t affect the conversation.
| If you change the switch’s setting on a conversation template, the change only affects conversations created from the template after the change. Conversations created before you change the switch’s setting aren’t affected by the change. |
Chat request (CHAT_REQUEST)
A visitor requests to chat.
-
Creator person type: visitor
-
Central person type: visitor
-
Media type: chat
-
Available in standard UIs: yes
Offline chat request (OFFLINE_CHAT_REQUEST)
A visitor requests to chat while no agent is available.
-
Creator person type: visitor
-
Central person type: visitor
-
Media type: chat
-
Available in standard UIs: yes
Video request (VIDEO_REQUEST)
A visitor requests to start a video call.
-
Creator person type: visitor
-
Central person type: visitor
-
Media type: video
-
Available in standard UIs: yes
Audio request (AUDIO_REQUEST)
A visitor requests to start an audio call.
-
Creator person type: visitor
-
Central person type: visitor
-
Media type: audio
-
Available in standard UIs: yes
Universal co-browsing request (HEADLESS_BROWSER_REQUEST)
A visitor requests to start universal co-browsing.
-
Creator person type: visitor
-
Central person type: visitor
-
Media type: universal co-browsing
-
Available in standard UIs: yes
Screen sharing request (SCREEN_SHARING_REQUEST)
A visitor requests to start sharing their screen.
-
Creator person type: visitor
-
Central person type: visitor
-
Media type: screen sharing
-
Available in standard UIs: yes
Embedded co-browsing request (DOMCAP_BROWSER_REQUEST)
A visitor requests to start embedded co-browsing.
-
Creator person type: visitor
-
Central person type: visitor
-
Media type: embedded co-browsing
-
Available in standard UIs: yes
Mobile co-browsing request (MOBILE_COBROWSING_REQUEST)
A visitor requests to start mobile co-browsing.
-
Creator person type: visitor
-
Central person type: visitor
-
Media type: mobile co-browsing
-
Available in standard UIs: yes
Universal co-browsing PIN (HEADLESS_PIN)
An agent invites a visitor to join universal co-browsing via a PIN.
-
Creator person type: agent
-
Central person type: visitor
-
Media type: universal co-browsing
-
Available in standard UIs: yes
Screen sharing PIN (SCREEN_SHARING_PIN)
An agent invites a visitor to join screen sharing via a PIN.
-
Creator person type: agent
-
Central person type: visitor
-
Media type: screen sharing
-
Available in standard UIs: yes
Embedded co-browsing PIN (DOMCAP_PIN)
An agent invites a visitor to join embedded co-browsing via a PIN.
-
Creator person type: agent
-
Central person type: visitor
-
Media type: embedded co-browsing
-
Available in standard UIs: yes
Mobile co-browsing PIN (MOBILE_PIN)
An agent invites a visitor to join mobile co-browsing via a PIN.
-
Creator person type: agent
-
Central person type: visitor
-
Media type: mobile co-browsing
-
Available in standard UIs: yes
Chat PIN (CHAT_PIN)
An agent invites a visitor to chat with them via a PIN.
-
Creator person type: agent
-
Central person type: visitor
-
Media type: chat
-
Available in standard UIs: not by default, but configurable with com.unblu.agent.conversationtemplate.allowStartChatPinConversations
Chat invite (CHAT_INVITE)
This engagement type doesn’t reflect a standard use case. It’s mainly intended to be used for conversations that are created using the Unblu web API and for outbound conversations.
While it’s possible in principle to create conversations of any engagement type via the Unblu web API, in practice, chat invite is the most commonly used engagement type under these circumstances.
-
Creator person type: agent
-
Central person type: agent
-
Media type: chat
-
Available in standard UIs: not by default, but configurable; see com.unblu.agent.conversationtemplate.allowStartChatInviteConversations and com.unblu.conversation.outbound.allowCreateOutboundConversation
Universal co-browsing invite (HEADLESS_INVITE)
An agent sends a visitor an invitation to join universal co-browsing.
-
Creator person type: agent
-
Central person type: agent
-
Media type: universal co-browsing
-
Available in standard UIs: yes
Invitations
When a person creates a conversation, Unblu sends an invitation to other potential participants. To join a conversation, an invitee must redeem the invitation. An invitation can only be redeemed once. Thus, even if more than one person receives an invitation, at most one of these people can join the conversation using this invitation.
Besides being redeemed, an invitation can also be revoked, either by an agent or by Unblu, provided it hasn’t yet been redeemed. Once an invitation has been revoked, it can no longer be used to join a conversation.
Recipients
If a visitor initiates a conversation, the agent or group of agents to receive an invitation to join a conversation are referred to as the conversation’s recipients. They’re potential participants in the conversation.
Once a recipient has redeemed the invitation, it isn’t possible for other recipients to join the conversation with the same invitation. However, the conversation’s recipient stays the same when the invitation has been redeemed.
If a conversation is forwarded to another agent, team, or named area, they become the conversation’s new recipient.
Recipients are displayed in the conversation list of the Floating Visitor UI until a recipient redeems the invitation.
Invitation types
There are a number of different types of invitation, depending on who initiated the conversation and on the purpose of inviting the other person.
Assignment request
This is the most common type of invitation. It’s sent to conversation Recipients when a visitor initiates a conversation.
Agent forwarding
When an agent forwards a conversation to another agent (or to a team), the new agent receives this kind of invitation. Once the latter joins the conversation, they become the conversation Assigned agent, and the conversation ends for the original assigned agent.
Agent invitation
This kind of invitation is used to invite an agent to join a conversation as a secondary agent. The status of other agents in the conversation isn’t affected when the invited agent joins.
Visitor invitation
This is the kind of invitation created when an agent adds a visitor to an existing conversation using the Invite a customer option in the Agent Desk. Any user with the invitation ticket of an visitor invitation can join the conversation as a visitor. Once the invitation has been redeemed it can’t be used by another visitor.
PIN conversation
This invitation type is used for universal, mobile, and embedded PIN sessions. Any user with the invitation ticket can join the conversation as a visitor. The invitee redeems the invitation by entering a PIN code. Once the invitation has been redeemed it can’t be used by another visitor.
Public links
The invitation types discussed above can all only be redeemed once. This has some downsides:
-
An agent setting up a conversation with multiple participants has to create a separate invitation for each invitee.
-
If a participant redeems an invitation but fails to join the conversation for some reason, the agent has to send them a new invitation.
To work around this, agents can opt to provide participants with a public link to a conversation instead. All participants can use the same link. This way, agents can send all participants a single email with the same link, for example.
For more information, refer to the section Public links of the article on Configuring invitations.
Conversation participants
A participant in a conversation is a person who has joined that conversation. Unblu distinguishes between different participants depending on their person type (visitor or agent) and on whether they’re primary or secondary participants in the conversation. What participants are able to do in a conversation is configurable. You may wish to prevent visitors from inviting other people to join the conversation as Secondary participants, for example.
Context person
The context person is the primary visitor in a conversation.
The primary visitor is the first visitor to join the conversation. This person defines certain aspects of the conversation such as the default language used, the size of certain UI elements in the collaboration space and when collaboration layers can be opened (see Conversations). For this reason, the primary visitor is also referred to as the context person.
Assigned agent
The assigned agent is the primary agent in a conversation.
The assigned agent is the agent who is initially assigned to the conversation. This typically occurs when the agent selects the incoming conversation from their queue.
Secondary participants
Secondary participants are participants invited to join a conversation by a current participant of the same conversation. For example, Unblu allows the assigned agent of a conversation to invite other agents and visitors to join them. Who is able to invite whom to join a conversation is configurable.
Secondary visitors
For visitors, we distinguish between the primary visitor (or context person) and secondary visitors.
Secondary visitors are any visitors other than the context person participating in a conversation. For example, a relationship manager may wish to chat with two clients in different locations. In this case, the relationship manager could start a conversation with one of their clients and then invite the other client to join them in the conversation. Here, the first client would be the context person and the second client would be a secondary visitor.
| There can be more than one secondary visitor in a conversation. |
Secondary agents
For agents, we also distinguish between the assigned agent and secondary agents.
Any agents participating in a conversation who aren’t the assigned agent of that conversation are referred to as secondary agents.
For example, a relationship manager may wish to invite a tax specialist from the bank to take part in a conversation with their client. In that case, the tax specialist would join the conversation as a secondary agent.
There can be more than one secondary agent in a conversation. In the previous example, the relationship manager could also invite their assistant and one of the bank’s lawyers. All three invitees would be secondary agents.
Another context where secondary agents are important is in long-running conversations between advisors and their clients. By inviting a secondary agent to the conversation, relationship managers can ensure that their clients' enquiries are dealt with in a timely fashion even if they themselves are unavailable.
For more information, see Hidden secondary agents.
Hidden participants and ghost participants
Hidden participants are secondary participants in a conversation who aren’t visible to the other participants.
Two kinds of participants can be hidden: bots and secondary agents. For information on hidden bots, refer to Conversation-observing bots.
Unlike hidden participants, ghost participants aren’t actual participants in a conversation. They may view a conversation, usually by using the Preview button in the inbox or the conversation history of the Agent Desk.
Depending on the configuration of the conversation, ghost participants have the right to execute actions such as forwarding the conversation to another agent or inviting another agent. For more information, refer to the configuration properties reference.
User-based conversation permissions
Most conversation permissions are based on the participant’s type of participation—assigned agent, context person, secondary agent, secondary visitor, or ghost—and their user role. Sometimes, however, this can be problematic.
Consider the following scenario: In your organization, only help desk agents have the hardware needed to conduct calls from their computer.
You’ve configured your conversation template for chat requests launched in ebanking so that the assigned agent can start audio calls: com.unblu.conversation.call.allowStartAudioCall has the value [ASSIGNED_AGENT]. When a visitor starts a chat with your ebanking help desk, the agent who accepts the request can therefore opt to start an audio or video call.
If the help desk agent can’t resolve your customer’s issue, they might forward the conversation to a 2nd level support team. When a 2nd level support agent accepts the forwarding, they become the conversation’s assigned agent. According to the permissions configured in the conversation template, this lets them start calls, even though they lack the necessary hardware. If the 2nd level support agent starts a call anyway, they can’t take part in the call they themselves initiated.
User-based conversation permissions let you revoke conversation permissions from individual users and teams, irrespective of their participation type. The configuration properties to do so are in the configuration group com.unblu.core.shared.collaboration.conversation.config.conversation.RevokeUserConversationPermissionConfiguration.
To prevent 2nd level support agents from starting audio calls in conversations forwarded to them from the ebanking help desk, you could set com.unblu.conversation.user.revoke.revokeStartAudioCall to true.
If you’ve set up your teams in such a way that all 2nd level support teams are ultimately subteams of a single team, you need only make the change in a single place.
Conversation session
When at least one participant is present in a conversation, a session is created in the context of that conversation. Conversation participants who are online are said to be present in the conversation session.
For more information, refer to Conversation timeline.