Chatbots are change-makers, and they define how customers connect to a brand and organization today. More and more companies are already using technology with their valued customers. For the uninitiated, a chatbot is an app that engages with customers via a chat interface and runs according to pre-programmed rules.
According to recent research, by the year 2020, 80% of customer queries are expected to be handled by chatbots.
When interacting with a customer service chatbot, there could be instances where a customer asks a question, and it is beyond the bot’s knowledge or not understood by the bot. In this scenario, the customer support chatbot tends to fail to answer, leaving the customer dissatisfied with the interaction. These issues can be quickly addressed by using a ‘Live Agent.’
Live Agent: Is typically a human agent who communicates in real-time with website users.
Live chat provides customers precisely what they want from a support team, real-time interaction with a real person. Amazon is one of the companies that use live chat as a method of support for their customers.
Chatbot + Live Agent = Live Agent Chatbot is an excellent solution for those who have a limited size support team but want to extract maximum return and effectiveness from them. While chatbots can handle the standard queries, a live agent takes care of the rest.
Top 4 Most Popular Bot Design Articles:
The transition between a chatbot and a live agent has to be seamless. If the user has to shift between screens for this transition, it will result in a bad user experience. Instead, the conversation has to be within the same chat window, and just the control should move from chatbot to live agent and vice versa.
Seamless Integration of Live Agent and ChatBot
Below is the protocol to seamlessly shift between Chatbot and Live Agent within the same chat window.
Chat Interface: Chat interface is a channel for the user to interact.
Router & Trigger: In simple words, routing is a process of selecting a path based on customer input. In the above diagram, the router does the same, if a customer types a word like ‘Chat With Associate’ it changes the path to the hop server, or if a customer types any question which the bot can answer, it directs to the bot.
Hop Server: In the above diagram, the hop server (we call it to hop server because the primary job of the server is to just pass the input request to the live agent server) plays a key role while chatting with the Live agent. Because it’s a bi-directional service, it takes the input from the chatbot and sends it to the live agent server as well as from server to chat interface. After the connection is established, it continuously asks the live agent for new messages to send to the chat interface.
Live agent system: To reach the live agent system, we have some endpoints like the rest APIs. Based on customer input, the hop server sends a request to the live agent system to receive or send an agent message to the chat interface.
When a user enters ‘chat with associate’ or ‘chat with agent’ (this is our trigger), the router understands the intent, sends a request to the hop server, takes care of the request (Ex: Get/Post), and then sends the request to live agent server. From now, the control moves from bot to the live agent.
To help understand this concept easily, let us look at Salesforce Service Cloud where we have a Live agent server.
Live Agent server acts one way. It doesn’t know the address of the source. The source (hop server in our case) has to ping the live agent server for updates continuously.
According to the Live Agent rest API, there are four calls to establish a connection between chatbot and live agent server.
- Get Session (System/Session-Id)
- Chat Initialization (Chasitor/ChasitorInit)
- Ping Live agent for New Messages (System/Messages)
- Post Message to Live Agent (Chasitor/Chat Message)
Get Session: To talk with a live agent system, this is the first call to establish the session to approach further. For this call, parameters like ‘affinity’ and ‘version’ are passed, and the Salesforce Live agent server returns ‘session key,’ ‘session token,’ and ‘affinity token’ in response.
Chat Initialization: The result of Get session call is passed as input to this API call, After the Get session call is executed, we get ‘key’, ‘token’, and ‘affinity’ parameters in the response. We need to pass these parameters to the Chat Initialize method, and if the Salesforce Live agent server returns ‘OK’, the user and live agent are connected and all set to start chatting.
Ping Live Agent for New Messages: To implement this API call, the developer must know about 2 key parameters — ‘ack’ and ‘pc’ values, how crucial they are, and how to increment these values when sending requests to the live agent and receiving responses from the server. For example, after the connection is established, for the first request, the ‘ack’ and ’pc’ values are -1 and 0 respectively.
The hop server keeps seeking new messages from the live agent continuously until and unless the session expires, or the server encounters an issue or if the customer explicitly stops the conversation.
Post Message to Live Agent: This API call takes customer question, sequence, affinity token, and session key as input to send a message to the Live agent server. Here, the sequence is the key value and it has to be incremented for every new request/ message. By default, the sequence value is 1.
In the development process, one should know the entire live agent interaction protocol specifications. In the case of Salesforce live agent, one should know terms like ‘ack’ and ‘pc’ and when to increment values and also understand the server response.
You must have noticed that merging live agents and chatbots into a single channel as a Live Agent Chatbot is a complicated process. However, the effort is worth it because of the exceptional user experience this solution provides!