In this article, we’ll explain messaging conversation handoff and handback, the actions that can change the first responder in a conversation from Answer Bot to an agent, and back again.
- Handoff is removing Answer Bot as the conversation’s first responder, and making an agent the first responder.
- Handback is removing an agent as the first responder in a conversation, clearing the way for Answer Bot to be the first responder when the customer starts a new conversation. Handing a conversation back to Answer Bot is, effectively, ending one conversation, clearing the way for a new conversation to address a new problem or support request.
This article includes the following topics:
Understanding handoff events
The only action that initiates handoff of first responder status from Answer Bot to an agent is the Transfer to agent step in an automated flow. When the conversation is handed off, agents are notified of the pending support request based on the account’s established routing flow, and Answer Bot can no longer respond to the conversation.
An agent remains the first responder until the ticket associated with the conversation is closed.
Understanding and managing handback events
Conversation handback is initiated when the status of the ticket associated with the conversation is changed from Solved to Closed. Then, when the customer begins a new conversation, Answer Bot becomes the first responder again. It’s important to note, however, that Answer Bot does not automatically send the first message in a subsequent conversation. The returning customer must send a message to initiate a response from Answer Bot and Answer Bot will attempt to find a conversational shortcut. respond according to normal free-text entry behavior. See Conversational shortcuts and article suggestions for more information.
Until the status of the ticket is changed to Closed, a customer returning to the messaging channel while the ticket is still marked Solved would find the previous conversation still active, and the agent would still be the first responder. The customer would be unable to start a new conversation to address a new support request. By default the time between a solving and closing a ticket is four days, which can cause some confusion for customers returning to your messaging channel.
You can avoid this scenario in two ways:
Adjusting your default automation
Automatically updating a Solved ticket status to Closed is managed through a default Support automation, Close ticket 4 days after status is set to solved.
You can edit this automation to manage how much time passes before the ticket status changes to Closed. You may want to change the time frame to close the ticket within the following hour or you can extend the time to up to 28 days after the ticket is Solved. To close a ticket immediately, see the trigger recipe in the following section.
Creating a trigger to manage handback timing
You can also create a trigger to automatically close solved tickets, essentially overriding the default automation.
To do this, you’ll need to add a tag (such as close) to any ticket that has its status changed to Solved.
Then, create a trigger that fires on any ticket with the added tag and closes the ticket. The trigger should have the following properties:
- Condition: Tags | Contains at least one of the following | close
- Action: Status | Closed
If you are using CSAT to gauge customer satisfaction in messaging, it’s important to note that the survey is sent immediately when the ticket status is set to Solved. If you are using CSAT surveys, we recommend that you keep at least a small time buffer between solving and closing a ticket, to avoid any conflicts. See Using CSAT with messaging for more information.
Additional settings to consider
There are a number of settings that, while not directly related to messaging handoff or handback actions, can impact how they perform, and how your end users experience them.
- Out-of-office triggers can set a customer’s expectations for when a live agent might engage them in the conversation. See Creating an out-of-office message in a Web Widget or mobile SDK for more information. Out of office triggers only fire after handoff occurs.
- Continuous conversations let you automatically send email notifications to end users who have left a conversation in a Web Widget before it was concluded. See Enabling customers to continue their conversation over email for more information.
- Routing settings manage how a messaging conversation and its associated ticket are passed from Answer Bot to an agent or group, after a handoff event occurs. See About routing in messaging for more information.
Are you able to clarify what happens if a ticket is handed off to an agent outside of business hours? I can see the option to configure a path based on whether or not it's inside/outside business hours, but there's no clarification on what happens after the handoff. Does it just become a ticket in the queue, rather than a message notification in the upper corner?
When a message is sent on the widget outside your business hours and "Transfer to agent" step is added to your bot flow, a ticket is created that goes to your unassign tickets queue and a notification is also visible on the top right of the Support page showing that there's a ticket that came in. Agents will have to manually pickup those tickets from the queue, unless you have configured custom routing rules using Trigger or Automation.
See Understanding what happens to messaging requests by default.
Hope this clarifies!
After the ticket is marked as closed, How do we prompt the bot again for the customer.
Basically when the customer comes back again for second time, how do we give him the same experience as the first time. We want the bot greeting message with start options to come again for the customer after the ticket is marked as closed.
Please note i am using authenticated customers, so there is no option for new conversation here.
I saw the ticket you created with the same question and already responded to it. We can continue working on the initial ticket. Please check your email!
I have a question about the trigger to close the ticket.
What is the reason to first assign a tag and then have the trigger fire when the ticket is tagged?
My current solution is a trigger that fires on Messaging and WhatsApp tickets when the ticket status is set to "Solved". It then sets the status to "Closed". So far it seems to work just fine, but would there be any reason to not do it like this?
Yes, your trigger should work as well considering you're not waiting for a CSAT score from your customer.
Using the trigger that is based on a tag allows you to add a tag anytime you want the ticket to be Closed. This trigger comes in handy if you are utilizing CSAT for your Messaging channel and you want to wait for the survey response before closing out the ticket.
Please sign in to leave a comment.