Ticket routing is how a support team decides who handles each customer request (a team, a human agent or an AI agent) and how soon. For a consumer brand, route by what the customer needs, such as the request type, language and urgency, rather than by the channel it arrived on, so each request reaches an owner who can resolve it and doesn't bounce between queues.
When software does it, it's called automated ticket routing. Skills-based routing and omnichannel routing are two ways of doing it, both covered below.
In short
- Every routing rule makes two decisions: who may take the request, and how soon. A method such as round-robin only picks the agent within that group.
- Route by request type, language and urgency. A refund request on WhatsApp and one by email go to the same agents; the channel only changes the reply window.
- Send an AI agent the requests it can complete under your rules, and send the rest to human agents with the order and a summary attached.
- Judge routing by reassignments, time to a first owner and whether that owner resolved the request, not by speed alone.
Triage, routing, assignment and escalation
These words are often used interchangeably. They are four decisions, and each needs its own rule.
| Term | The decision | Example |
|---|---|---|
| Triage | What is this request, and how urgent is it? | "Please cancel my order": a cancellation, urgent because the order is packed at 11am |
| Routing | Which team, queue or AI workflow may handle it? | The cancellation workflow, or the orders team if the order is already packed |
| Assignment | Which agent in that team takes it now? | The available orders agent with the fewest open tickets |
| Escalation | Who takes over when the first owner can't finish? | A team lead who can approve a refund outside policy |
Most helpdesks do triage and routing in one step, which is fine as long as both are written down. Escalation comes later: it moves a request that has already started to someone with more authority, often at the next of your customer service tiers. Routing is one part of customer service operations, alongside staffing, tiers and service levels.
The two decisions in every routing rule
Who may take it. This is the eligible pool: the agents, or the AI workflow, with the skill, language, channel access and authority the request needs. Authority matters in order work. An agent who can't edit orders in your store, or can't issue refunds above a limit, isn't eligible for those requests however free they are.
How soon. This is the priority within the pool. For a consumer brand, urgency is usually set by a clock outside the conversation: the dispatch cut-off for a cancellation, money already taken for a failed order, a messaging window about to close. Tone matters too, but a calm message about an order packed at noon is more urgent than an angry one about a refund due next week.
Only then does a distribution method pick the agent. HubSpot's help desk, for example, offers load-balanced, round robin and random distribution, where load-balanced means the available agent with the fewest open tickets. The method is the smallest of the three decisions.
Ticket routing methods compared
| Method | How it decides | Suits | What goes wrong |
|---|---|---|---|
| Manual or pull | A lead assigns tickets, or agents take the next one from a shared view | Small teams doing one kind of work | Easy tickets get picked first and hard ones age |
| Round-robin | Rotates through available agents in turn | Similar requests and equally skilled agents | Ignores how hard the ticket is and how busy the agent is |
| Load-based | Sends to the available agent with the most spare capacity, often with a limit per channel | High volume with uneven handling times | Limits set too high let one agent collect a backlog |
| Skills-based | Limits the choice to agents with the skill the request needs: request type, product or authority | Refunds above a limit, warranty claims, bulk orders | A skill held by one person becomes a silo |
| Language | Limits the choice to agents who read and write the customer's language | Brands serving several languages or regions | A language with one speaker waits for her shift |
| Priority or customer value | Moves repeat contacts, loyalty members or high-value orders up the queue, or to senior agents | Customers you can't afford to keep waiting | When everything is urgent, nothing is |
| AI classification | Reads the message and sets the request type, language and urgency | Free text on WhatsApp, Instagram DMs and email | Low-confidence guesses routed as if certain |
| Sentiment or escalation risk | Sends frustrated customers, or those threatening to go public, ahead of the queue | Complaints and repeat contacts | Noisy labels flood the priority lane |
Most consumer brands combine them. AI classification sets the request type, language and urgency; skills and language define the pool; load-based assignment with capacity limits picks the agent; priority rules reorder the queue. Round-robin alone works for a team of five doing one kind of work. Zendesk's own documentation notes that its round robin doesn't consider ticket complexity or expertise, which matters as soon as requests differ.
Flowcall's AI Helpdesk is built for that combination. Tickets go to a team or agent by skill, language, workload, sentiment or escalation risk, each going to the least-loaded available agent, the customer's previous agent first, within capacity limits for each agent, channel and team, and priority can follow the workflow type. You can also route by customer data, such as tier, region or order value. Frustrated customers and those at risk of escalating skip the queue, so the team can step in before frustration turns into a public complaint.
Route by request type, not by channel
Many teams route by channel because that's how the channels arrived: someone watches Instagram, a team works email, another takes calls. It is easy to set up and it fails in a predictable way. A refund request waits in the email queue while the WhatsApp team is quiet, and the social team, who reply to comments and campaigns, can't touch orders at all. Route by request type instead, and treat the channel as an attribute of the request, which is how omnichannel customer service keeps one issue with one owner.
| Request | First owner | Needs | What sets its urgency |
|---|---|---|---|
| Where is my order? | AI agent, from live courier data | Read access to store and courier data | A parcel past its expected date or stuck at one scan |
| Cancel my order | AI agent under your rules; the orders team once it's packed | The ability to cancel in the store or order system | The dispatch cut-off |
| Change my delivery address | AI agent before dispatch; the logistics team after | Order editing; a check that the courier serves the new postcode | The dispatch cut-off |
| Return or exchange | AI agent books the pickup inside the return window | Return rules; courier booking | The return window closing |
| Refund | AI agent for status and refunds within a limit; agents with refund authority above it | Refund authority and an amount limit | Money taken; days since the return reached you |
| Damaged, wrong or missing item | AI agent collects photos and the order; then a human agent | Judgement; authority to replace; a stock check | A safety issue; a repeat contact |
| Payment taken, no order | A human agent trained on payments; the AI agent collects the transaction reference first | Access to the payment gateway | Money taken; a second contact is likely |
| Complaint or threat to go public | A senior agent or team lead | Authority for goodwill gestures | Immediately |
To build your own version, start from last month's 10 to 15 biggest request types, with their volume by channel and language, and fill in the same four columns. Two things change when you route this way. What the request needs decides its first owner, so the channel only sets the reply window. And urgency comes from the request's own deadline, which the rule can read from the order: an address change for an order that ships at noon is urgent at 11am and pointless at 1pm.
What to route to an AI agent, and what to human agents
An AI agent is one of the routes, not a filter in front of the queue. Send each request type down one of three paths.
- The AI agent completes it. Requests with a written rule and a system the AI can change: order status from courier data (order tracking automation), cancellations before dispatch, address changes, and the return pickups and refunds within a limit that make up most of returns management. Routing these to a human agent only adds a wait; this is customer service automation that completes the request instead of tagging it.
- The AI agent prepares it and a human agent decides. Damaged items, refunds above the limit and exceptions to policy. The AI collects the order, photos and reason, then hands the ticket to the pool for that request type with a summary.
- Straight to a human agent. A customer who asks for an agent, a repeat contact about the same order, a safety issue such as an appliance that sparked, a legal or public threat, or a customer who is plainly furious (see how to handle angry customers).
One rule makes the handoff work: the AI's classification becomes the ticket's route. If the AI knows the customer wrote in Hindi about a damaged mixer grinder, the ticket should go straight to an agent who reads Hindi and handles damage claims, not to a general queue for someone to triage again. What the handoff must carry is listed in our chatbot vs live chat guide; escalation management covers what happens after it.
We built Flowcall's AI Agent so that its classification becomes the ticket's route. It works out what the customer wants, picks the workflow for that request and, when your rules allow, completes it on WhatsApp, Instagram, Messenger, Live Chat or email. When a human agent is needed, it creates a ticket with the conversation, a summary, the customer and order context and what's left to do, and routes it to the right team rather than a general queue.
One queue across WhatsApp, Instagram, email, chat and phone
One queue doesn't mean one list sorted by arrival time. It means requests from every channel go through the same triage and into the same pools, while each of your customer service channels adds its own constraints.
- Join before you route. Match each message to the customer (by phone number, email or order ID) and to any open ticket about the same issue. Otherwise a customer who writes on Instagram and then emails gets two tickets, two agents and possibly two answers.
- Respect the messaging window. On WhatsApp, a customer's message opens a 24-hour customer service window; once it closes, the business can send only pre-approved templates. Instagram and Messenger give businesses 24 hours to respond, extended to seven days for manual replies with Meta's human agent tag, which needs Meta's app review.
- Check business-hours targets against those windows. A WhatsApp message sent at 8pm on Friday and answered at 10am on Monday has waited 62 hours, and the agent must reopen the conversation with a template. Evening and weekend cover, by people or an AI agent, is a routing decision as much as a staffing one; see 24/7 customer support.
- Bring calls into the same pools. The phone system's menus route a call before any ticket exists. With computer telephony integration, the call joins the customer's ticket, so callbacks go to the pool that owns the request.
- Route by the language the customer wrote in, detected from the message rather than picked from a menu. Where few agents speak a language, multilingual customer support covers how to widen the pool.
- Use channel access as the second filter. Calls, email and live chat are different jobs, so channel skills can narrow the pool, but only after the request type has chosen it.
In Flowcall, every WhatsApp, email, Instagram, Messenger, Live Chat and phone conversation arrives in one inbox. Flowcall's AI also moves support and pre-sales questions from comments and @mentions on your Instagram and Facebook posts into a private DM that continues in the same inbox. When the same customer writes on another channel while their issue is open, Flowcall keeps it on the same ticket with the whole history, while a new issue or a different order gets its own ticket. Someone else writing about the same order joins the open ticket too, so the issue isn't routed twice. Through Flowcall's phone integration, calls open with the customer's context and are logged, recorded and transcribed on the ticket.
SLAs for each route
Set first-response and resolution targets for each route (a request type at a priority), not for each channel. Three rules keep them honest:
- Start from the request's own deadline. The resolution target for a cancellation before dispatch is the dispatch cut-off, not a round number of hours.
- Stay inside the channel's window. On WhatsApp, Instagram and Messenger, measure the first reply in calendar hours, including weekends, against the 24-hour window.
- Set the rest from your own data. Use recent medians and 90th percentiles of each route's first response time and resolution time, not a published benchmark whose definition you don't know.
| Route | The target comes from | When it's at risk |
|---|---|---|
| Cancellation or address change before dispatch | The dispatch cut-off | Move it to the top of the orders pool and alert the warehouse |
| Messaging request that needs a human agent | The 24-hour window, in calendar hours | Send it to an evening or weekend pool, or to a lead |
| Refund above the limit | Your refund promise to the customer | Alert the approver, not just the agent |
| Damaged item or complaint | Your own 90th percentile, tightened as it falls | Reassign to a senior agent |
A target without an action when it's at risk is only a report.
Flowcall's SLA policies attach that action. They set response and resolution targets for each team, workflow or channel, on your business hours or around the clock, and show which tickets are at risk; the people you choose are alerted before a breach, and breached tickets move up the queue.
One Monday after a sale, routed two ways
A kitchen-appliance brand ran a weekend sale. At 9am on Monday its queue holds hundreds of messages, including these three:
- An Instagram DM sent at 8:40am: "Please cancel my order, I ordered twice." The order is due to be packed at 11am.
- A WhatsApp message in Hindi sent at 7:10am: the refund for a kettle returned last week hasn't arrived.
- An email with photos of a mixer grinder that arrived with a cracked jar. It's the customer's third contact, after an earlier email and a phone call on Saturday.
| Routed by channel | Routed by request | |
|---|---|---|
| Instagram cancellation | Waits in the social team's queue among comment replies. The team has no store access, so it forwards the message to email at 11:30. By then the order is packed and on its way. | The AI agent finds the order, sees it isn't packed, cancels it, starts the refund and confirms in the DM at 8:41. No ticket is created. |
| Refund in Hindi on WhatsApp | Round-robin gives it to a WhatsApp agent who doesn't read Hindi. She reassigns it to a colleague on the evening shift, who replies at 6pm. | The AI agent replies in Hindi with the refund's status from the payment system. The refund is past the brand's promise, so it creates a ticket for the refunds pool, limited to agents who read Hindi, with the transaction reference. An agent picks it up at 9:20. |
| Third contact about a damaged item | Joins the email queue behind the weekend's backlog. At 2pm an agent asks for photos the customer already sent in the earlier email, which is on a separate ticket. | Joins the open ticket with the earlier email and the call. As a repeat damage claim, it goes to the top of the damage pool, and a senior agent approves a replacement jar before 10am. |
It is the same team with the same volume. Each request was triaged once, by what it needed, and reached an owner who could act on it.
Common routing failures and how to fix them
- Bouncing. A ticket passes between teams because each thinks it belongs to another. Write down one owner for each request type, and require a note when a team sends a ticket back, so repeated bounces point to the rule to fix.
- Orphaned tickets. Tickets sit unassigned, or with an agent who is off shift. Some helpdesks leave a ticket unassigned when no eligible agent is available; HubSpot's does by default. Give every pool an overflow, reassign open tickets at the end of a shift, and alert a lead when a ticket stays unassigned longer than its first-response target allows.
- Skill silos. One agent handles warranty claims or reads Tamil, and the queue waits for her. Keep at least two or three people on every skill, with a fallback pool after a set time. Staffing each pool by the hour is a workforce management question.
- Priority inversion. First-in, first-out puts a third complaint behind a hundred order-status questions. When half the queue is marked urgent, urgency means nothing. Keep a few priority levels tied to deadlines and risk.
- Keyword misroutes. A rule that sends every message containing "return" to the returns team also catches "return to origin" (a courier term for a parcel sent back to the seller). Classify intent from the whole message, and send low-confidence cases to a triage queue instead of guessing.
- Rules that don't survive a peak. A sale can multiply one request type while other pools sit idle. Cross-train an overflow pool on the requests that spike, and plan it before the sale, as for Black Friday customer service.
How to measure routing quality
Speed alone doesn't show whether routing works: a ticket can be assigned in seconds to the wrong team. Measure these for each route, alongside your other customer service metrics:
| Measure | How to count it | What it tells you |
|---|---|---|
| Time to first owner | From the first message to assignment to the team or agent who works it; median and 90th percentile | Whether requests wait in triage |
| Reassignment rate | Tickets moved to another team or agent after the first assignment, divided by all tickets | Misroutes and unclear ownership |
| First-owner resolution | Tickets resolved by the first team, agent or AI workflow they were routed to, divided by all resolved tickets | Whether routing picks an owner who can act |
| Unassigned too long | Tickets unassigned for longer than the route's first-response target, per day | Orphaned tickets |
| Asked again after handoff | Handoffs where the agent asked for something the customer or AI agent had already given, divided by all handoffs | Whether the route carried the context |
| Target met, by route | Requests meeting their route's response and resolution targets, divided by requests on that route | Whether priorities hold |
| Load spread | Open tickets per agent in a pool: the highest against the median | Whether distribution is fair |
Each week, also read 20 reassigned tickets and note where each should have gone first; that sample shows which rule to fix. First-owner resolution is the routing side of first contact resolution. Report AI and human routes separately: as the AI agent completes the simple requests, the human queue keeps the harder ones, so its times and reassignments can look worse while routing improves.
Flowcall's AI Auto QA finds the "asked again after handoff" cases for you. It flags human agents who ask again for details the customer already gave, and AI Agent conversations with missed or late handoffs, and quotes the conversation in each finding. Flowcall's reports show CSAT by AI versus human, channel, team and agent, so the AI and human routes can be judged separately.
How Flowcall routes tickets
Put together, Flowcall routes each request by what it needs rather than where it arrived. The AI Agent works out what the customer wants and completes what your rules allow; the AI Helpdesk sends everything else, from any channel, to a pool that can act on it with the order and a summary attached; and SLA policies and QA findings show where a route is slipping.
To see where your own requests would go, book a demo and we'll take a sample of your request types through triage, the AI path and the pool each would reach.
Frequently Asked Questions
What is ticket routing?
Ticket routing is the process of deciding which team, human agent or AI agent handles each customer request, and how soon. Rules use the request type, language, urgency and customer details to choose the group; a method such as round-robin or load-based assignment then picks the agent.
What are the types of ticket routing?
Manual assignment, pull (agents take tickets from a queue), round-robin, load-based, skills-based (including language), priority or customer-value routing, and AI routing that classifies the request from its text. In practice they work together: classification and skills choose the group, and load-based assignment picks the agent.
What is the difference between queue-based and skills-based routing?
Queue-based routing sends each request to the next available agent. Skills-based routing first limits the choice to agents with the skill the request needs, such as refund authority or a language. When requests differ, it lets more of them be resolved by their first owner, as long as each skill has enough people.
What is automated ticket routing?
It is routing done by software instead of a team lead: rules or an AI model classify each request as it arrives and assign it. It needs fallbacks for requests it can't classify confidently and for times when no eligible agent is available, or tickets land in the wrong queue, or in none. The triggers and timers that act on tickets after routing are help desk automation.
What is omnichannel routing?
Omnichannel routing puts requests from every channel through the same triage and into the same agent pools, instead of keeping one queue per channel. The channel then sets constraints, such as a messaging window, rather than deciding who answers.
