Customer request routing: getting messages to the right team

Short answer

Routing a customer request to the right department takes three things: a short list of categories based on what the customer wants (sales, existing order, complaint, payment, other), an owning team and an hours rule for each category, and a fallback owner for requests that match no rule. Measuring misroutes matters too: how many conversations were passed from one team to another? That number shows how good the rules are.

A written request is not a call

Routing in contact centres has been built for years: a call enters a queue, and an agent's routing profile defines which queues they serve. Platforms such as AWS store these fields separately in their contact records. Call routing is covered in skills-based routing.

Written channels are different. The customer does not pick from a menu; they write freely: "I ordered yesterday, it hasn't arrived, and do you have it in red?" One message carries two intents — a delivery complaint and a sales question. And the message may arrive at night when the team opens in the morning.

Step 1: intent categories

A category is not a department name; it is what the customer wants. Five to seven categories are enough to start:

• Sales question: price, availability, terms.
• Existing order: status, delivery, changes.
• Complaint and returns.
• Payment and documents: invoices, receipts, credit.
• Partnerships and job applications — often forgotten and dumped in the sales queue.
• Other — goes to the fallback owner.

With too many categories, both bot and agent get it wrong. If a category receives only a few requests a month, fold it into "other".

Step 2: the routing matrix

Write one row per category. The matrix should not exceed one page:

1. 1Category"Existing order".
2. 2Owning teamLogistics and customer service.
3. 3During hoursAssigned to the agent on shift, with a first-response target written down.
4. 4Outside hoursThe bot answers status questions from the knowledge base or the order system; anything unresolved is handled first thing in the morning.
5. 5Fallback ownerThe shift lead — if nobody from the owning team is available.

Step 3: mixed and vague messages

Most mistakes happen with two-intent and very short messages. Three rules work:

• With two intents, route to the higher-risk one: a complaint comes before a sales question. Once the complaint is handled, the agent answers or passes on the sales question.
• Messages like "Hi" or "some info please" are not routed anywhere — a clarifying question comes first.
• If the customer changes intent in a second message, the conversation can be rerouted, but with its history.

Step 4: hours and shifts

Routing depends on the clock. If the sales team closes at 19:00, a sales question in the evening goes either to the bot or to the morning queue — never to "nobody". The customer should be told plainly when they will get an answer. Weekends and public holidays go into the matrix as separate rows, because that is when most requests get lost.

Leads and support requests take different paths

A request with buying intent becomes a lead and is distributed to a sales manager, and that distribution has its own rules — rotation, channel, workload. A support request stays in the service queue until it is resolved. The most common mistake is recording a complaining customer's number as a sales lead: a manager calls with an offer while the customer's problem is still unsolved.

Who keeps the matrix

A routing matrix is not a document you write once and forget. With every new product, campaign or change in team structure, categories go stale and requests start landing in the wrong place again. The matrix needs an owner — usually the head of customer service or the operations manager. Once a month they read 10–15 rerouted conversations, note why each went wrong, and tighten one or two rows. Before a big campaign there is a separate check: which category will campaign questions land in, and will that team have enough people on shift? When something changes, the team gets a short note so nobody keeps working to the old rule.

An illustrative example

This is an illustrative example. At 22:40 someone writes to an electronics shop on Instagram: "I bought a laptop and it won't charge. Can I return it?" Under the matrix this is "complaint and returns". The bot states the return policy from the knowledge base, gives the service centre's address and says an agent will be in touch at 10:00. The conversation lands in the customer service queue; no sales lead is created.

The same evening another customer writes: "Is there a 16 GB version of this laptop?" That is a sales question: the bot answers, once a number is given a lead is created, and in the morning it is assigned to a sales manager.

Measuring routing quality

• Re-routing rate: conversations passed from one team to another.
• The share of requests landing in "other" — above 15–20%, the category list does not reflect reality.
• Requests left without an owner (outside hours counted separately).
• Leads created by mistake from complaints.

Common mistakes

• Building categories around the org chart instead of the customer's language.
• Not naming a fallback owner.
• Routing by channel only: "Instagram = marketing". People complain on Instagram too.
• Losing the history on handover, so the new team asks the customer everything again.

Limitations

Automatic categorisation is not error-free: short, ironic or mixed-language messages will land in the wrong place. So re-routing must be easy and mistakes must be reviewed regularly. Routing also depends on each team's real capacity: sending everything to the right team does not cut waiting time if that team is short-staffed.

Routing in Vexvon

In Vexvon, a lead gets a category and a priority (high, medium, low) according to rules the company sets, and is distributed in one of four modes: manually, by rotation, by channel, or by each manager's current workload. With the buyer-intent filter switched on, a customer who shares a number while complaining does not become a sales lead. When a customer asks for an operator, a notification goes to the team's Telegram group; outside working hours the company's own message is sent. For more complex routing between departments, lead and status events can be passed to the company's own system by webhook. More on the CRM page.

Next step

Read last week's 50 written requests and give each a category. Then check which ones were actually passed to another team. That list is the first version of your matrix. The daily inbox work is described in the omnichannel inbox, and we can build your matrix together during a demo.