In Zendesk's messaging for Web Widget, mobile SDKs, and social channels, when a customer requests assistance from a live agent during a conversation, a ticket is created, and agents are notified in the Agent Workspace that a request has been received.
You can use Support triggers to route the associated ticket to specific agents or groups, then use the routing rules defined in your Chat dashboard to determine which of those agents or groups are notified that a new conversation is waiting in the queue. You can also use views to organize tickets submitted through a messaging channel.
If you’re using the Agent Workspace, you can also route messaging tickets using omnichannel routing. For details, see About omnichannel routing with unified agent status.
This article includes the following topics:
Overview of the routing flow in messaging
Before jumping into a discussion about routing incoming messaging requests, it’s important to understand the elements involved and where they fall in a messaging flow.
Elements directly (and indirectly) controlling messaging ticket routing
There are three elements that directly control how a messaging ticket is routed:
- Support triggers are applied to the tickets created when a messaging conversation is passed to an agent. They perform much like triggers applied to tickets created via other channels, but you may need to use them in other ways for messaging tickets. See Routing messaging tickets using Support triggers for more information.
- Chat routing rules define how agents are informed that there is a messaging ticket waiting in the queue. Specific agents or groups can be notified, or all agents can see a broadcast notification. If a Support trigger has routed the ticket to a specific agent or group of agents, only agents assigned to the ticket will receive a notification. Agents must click the notification to enter the conversation. See Setting up notification routing for live chat and messaging for more information.
- Omnichannel routing allows you to direct tickets from multiple channels, including messaging, to team members based on their availability, capacity, and the ticket priority. See About omnichannel routing with unified agent status for more information.
Additionally, there are elements that do not directly control ticket routing, but can be referenced by Support triggers, or can otherwise impact how a ticket is received by agents:
- Transfer to agent events (Web Widget and mobile SDKs only) in a conversation flow, created in Flow Builder, initiate the passing of a messaging conversation Answer Bot to an agent, which creates a ticket associated with that conversation. These events can include custom ticket fields to collect information from customers that can be used when creating Support triggers. For more information on agent transfer events, see About Flow Builder.
- Chat triggers can fire when a conversation is passed to a live agent (via an agent transfer event), or when the customer enters a comment in a messaging conversation with a live agent. An agent does not have to be actively participating in the conversation for these triggers to fire, but the conversation must have been passed from Answer Bot to agent control. Chat triggers in messaging are generally used for auto responders, which can inform your customers that agent assistance is not currently available. See Creating an out-of-office message for Web Widget and mobile SDKs.
Sample messaging flow
The elements described above fire at different points in a messaging conversation, and knowing when each comes into play is important to understanding how they work. Below is a sample of a basic messaging flow. When the elements described above fire are shown in Bold.
- Customer begins a messaging conversation via your messaging channel. For Web Widget and mobile SDKs, Answer Bot is the first responder for the conversation and interacts with the customer, based on the flow designed in the Flow Builder. Social messaging conversations do not currently include Answer Bot functionality and an agent is immediately made the first responder – skip ahead to step 3.
- The customer indicates they are unable to self-solve their issue in an agent transfer event and requests help from an agent. Answer Bot is removed as the first responder for the conversation.
- A ticket associated with the conversation is created. Any chat messaging triggers for when a visitor requests a chat fire, and Support triggers with the conditionTicket | is | Created fire.
- An agent becomes the first responder for the conversation.
- Customer adds a comment to the conversation. Any Chat messaging triggers for when a chat message is sent fire.
- The associated ticket is added to the queue. Chat routing rules fire, alerting agents to the presence of a new conversation.
- An available agent accepts the ticket and enters the conversation based on your selected routing method OR, if no agent is available, the ticket remains unassigned and can be found in the ticket views according to your view configurations.
- Once the customer’s issue is resolved, the ticket is marked Solved.
- After a set period of time, an automation updates the ticket status from Solved to Closed, which ends the associated conversation as well. See Solving a ticket and understanding how it is closed for more information.
Understanding what happens to messaging requests by default
Using the out-of-the-box configurations for your conversation flow, Support triggers, Chat triggers, and Chat notification routing, incoming requests for agent assistance from the messaging channel have a simple, functional routing process.
- Customers are handed off from Answer Bot to the Agent Workspace. No information is collected through custom ticket fields.
- Tickets are not assigned to any agent or group, and appear in two default views, Unassigned tickets and All unsolved tickets.
- A notification is broadcast to all agents, informing them that a request has been received.
Using Support triggers to route messaging tickets
Support triggers allow you to automatically route tickets to specific agents or groups. In messaging, you can use the following data as trigger conditions to automatically route messaging tickets to specific agents or groups:
- Data collected via custom ticket fields as part of a Transfer to agent event created in Flow Builder. This data can include customer location, the nature of their issue, or really any information you want to gather.
- Channel | is | Messaging set as the ticket submission channel, to create routing rules that apply only to messaging tickets. If you do not specify messaging as the channel, all incoming tickets will have this trigger applied. Any triggers with other channels specified (email, for example) that do not include messaging will not fire.
There are three main parts to setting up this routing flow:
- Creating a custom ticket field
- Adding the custom ticket field to your conversation flow
- Building a trigger to route your ticket
For a step-by-step example, see Recipe: Routing messaging tickets using Support triggers.
Using Chat routing rules to notify agents
Chat routing rules determine which agents, or groups of agents, are notified that a messaging conversation has been received. Routing rules are set at the account level, and applied to all brands associated with your account.
There are two basic methods for notifying agents of incoming messaging requests:
- Broadcast, where all agents are notified of all incoming requests, and agents self-assign these requests through the Agent Workspace. This routing option is enabled by default.
- Assigned, where conversations are passed to specific online agents or groups.
One of these routing rules is applied at all times -- you cannot opt out of routing rule selection.
Chat routing rules are applied after any Support triggers fire. If you are using a support trigger to route incoming messaging tickets to specific agents, notifications are only sent to agents that are eligible to accept the ticket.
- If no specific agent or group is assigned the ticket, a broadcast notification will be received by all messaging agents, and an assigned notification will be received by the next eligible agent, according to the assigned routing rules.
- If a specific agent or group is assigned the ticket, a broadcast notification will be received by all messaging agents specified in the trigger, and an assigned notification will be received for the specified agent, or the next eligible agent in the group, according to the assigned routing rules.
Other chat routing settings such as hybrid assignment and reassignment are supported.
Skills-based routing is not supported for messaging conversations.For information on configuring basic routing options, see Setting up automatic chat routing.
Using omnichannel routing to route messaging tickets
With omnichannel routing, you can direct tickets from email, calls, messaging, web form, and API to team members based on their availability, capacity, and the ticket priority.
Using omnichannel routing means that the highest priority tickets are assigned to the agents who are most available to work on them. It requires the Agent Workspace to be activated.
You can also configure omnichannel routing to reassign work to a different team member if it isn’t addressed in a specified amount of time (Enterprise only). This applies to the following channels:
- Answer Bot for Web Widget
- Facebook Private Message
- Instagram Direct
- Twilio or Messagebird Text
- Twitter Direct Message
- Web Widget
Omnichannel routing has some current limitations to be aware of:
- The ability to set an agent's status if they don't accept a certain number of message assignments, known as automatic idle, isn't supported yet.
- Broadcast and hybrid modes for messaging aren't supported.
- If you’re using live chat, you cannot use omnichannel routing. Chat will be included in a future release.
Inactive messages in omnichannel routing
An inactive messaging ticket (more than 10 minutes without a reply) is automatically assigned to an agent with spare capacity on a round robin basis. It won’t use up any of that capacity.
Once an agent comes online, assuming they are not at max capacity, they will be automatically assigned an inactive message from the queue without needing to accept it. If there are several inactive messages in the queue, then the first agent online in the group will be assigned them all. If more than one agent comes online at the same time, the inactive tickets are assigned starting with the agent who’s gone the longest without any messages.
Routing messaging tickets to a view
You can also route messaging tickets to a view, allowing admins and agents to easily locate tickets submitted through the messaging channel. The Chat routing rules will still apply to tickets routed to views. In the example screenshot below, the view is also restricted to a messaging-specific agent group.
Hi, is it possible for the outcome of a 'Transfer to agent' in the 'Flow Builder' to be a new email ticket that populates the backlog?
We aren't looking to have an online human chat presence but would like a bot presence. Ideally what would happen is that if the customer doesn't get the help they are looking for they can submit a request/contact form that generates an email ticket in the backlog for us to pick up.
It seems the only type of support ticket that can be generated is a Chat ticket not a support ticket or have I got that totally wrong?
Apologies for the late response. We have introduced business hours in Flow Builder. This will enable admins to capture more information from customers, starting a conversation out of business hours. This information will passed along to a new Messaging ticket. The agents have the option to respond via messaging or email to that ticket.
I would also suggest checking out this capability, which sends email notification to customers for new, unread messages from the agent.
When a messaging request comes in "A notification is broadcast to all agents, informing them that a request has been received."
Is there any way to limit this notification (the conversations button in the upper right corner) to the agents in the group the ticket is assigned to? Now all agents see there is an incoming message, even when it is not in their group. They can select it but the get the notification they don't have the rights to view it and that's it.
Hi, I found the answer to my question, maybe this could be added to the article:
in order to make assigned routing work you should also enable the chat department.
Anton Verhelst can you explain in more detail how you solved this problem? I too find that messaging and social conversations broadcast to all agents even if they aren't assigned to those groups and I'm having a difficult time figuring out how to limit this. Thank you!
These are the steps I've taken:
In the Chat Dashboard, go to Settings > Departments and enable the teams that should be able to receive the incoming messages.
Next go to Settings > Routing and select Assigned.
Then I created triggers for the specific channels to assign to the correct groups.
Example: FB Messenger should go to the Social Media Team (group in Support)
Make sure your agents are chat agents of course.
This worked for me, I hope it helps you as well!
Thank you so much Anton Verhelst! This is a wonderful improvement.
ok, so I'm trying to create a routing trigger within Agent Workspace for messaging, and I do not have the option of just Channel as shown in your screenshots. We have Channel Type but that doesn't seem to work for routing messaging tickets.
Let me create a ticket so that we can investigate further on this. You'll receive an email shortly. Thanks!
Please sign in to leave a comment.