Routing messaging tickets and notifications

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.

In this article, we’ll explain the settings and features that impact how a messaging ticket is routed to agents, and how those agents are notified. We’ll also show you where and how those settings fire in a sample flow to illustrate the routing process.

Note: Currently, skills-based routing is not available for messaging conversations or tickets.

This article includes the following topics:

• Overview of the routing flow in messaging
• Understanding what happens to messaging requests by default
• Using Support triggers to route messaging tickets
• Using Chat routing rules to notify agents
• Using omnichannel routing to route messaging tickets
• Routing messaging tickets to a view

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 any conversation flow created in bot builder will pass the conversation bot to an agent. This 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 bot 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 the 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.

1. Customer begins a messaging conversation via your messaging channel. For Web Widget and mobile SDKs, the bot is the first responder for the conversation and interacts with the customer based on the flow designed in the bot builder.
2. The customer indicates they are unable to self-solve their issue in an agent transfer event and requests help from an agent. The bot is removed as the first responder for the conversation.
3. 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.
4. An agent becomes the first responder for the conversation.
5. Customer adds a comment to the conversation. Any Chat messaging triggers for when a chat message is sent fire.
6. The associated ticket is added to the queue. Chat routing rules fire, alerting agents to the presence of a new conversation.
7. 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.
8. Once the customer’s issue is resolved, the ticket is marked Solved.
9. 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 the bot to the agent, who picks up the conversation in 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.
• If a ticket request remains unassigned in the queue for more than 10 minutes, it is moved to the Unassigned tickets view.

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 bot 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.

Important: Any departments included in messaging notification routing rules must be activated for Chat for notification routing rules to function correctly. It is advisable to activate all messaging-related Chat departments. See Creating and editing a Chat department for information on updating department settings.

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.

Note: Any chat routing settings configured before enabling messaging are automatically applied to messaging routing.

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 notification 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:

• Bots in the Web Widget
• Facebook Private Message
• Instagram Direct
• LINE
• Twilio or Messagebird Text
• Twitter Direct Message
• Web Widget
• WhatsApp

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.

For more information, see About omnichannel routing with unified agent status.

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.