A ticket arrives in a language nobody on shift reads. What happens next is decided by your routing rules, and most routing rules were written for a single-language desk where the only question was which team should own the problem.
TL;DR
- Route on the requester’s recorded language preference, not on detection of the ticket text. Detection is unreliable on short messages.
- A one-line subject in a language sharing vocabulary with another is the classic misroute, and it is common.
- Language is a second dimension, not a replacement for your existing skill routing. You need both.
- Do not build a queue per language until a language has enough volume to keep somebody busy.
- Have an explicit fallback: what happens when no agent for that language is on shift.
- Measure misroutes and reassignment counts by language. A high reassignment rate is a routing fault, not an agent fault.
Why detecting the language is the wrong approach
Automatic detection works well on a paragraph and badly on the text people actually submit. IT tickets are short, full of proper nouns, product names and error strings, and frequently written in a mix of two languages.
A subject line reading “VPN error 403 no connect” has almost no linguistic signal in it at all. Detection will return something, with confidence, and that something routes the ticket. Languages that share vocabulary or script compound the problem.
The alternative is boring and reliable: route on what the requester’s record says. You already hold an employee identifier on the ticket, and their preferred language is a field on that record.
Capture preferred language at onboarding as a field, sync it to your service desk as an attribute on the user, and route on that. It is stable, it does not depend on how a particular message was phrased, and it is correct even for a one-word ticket.
Ask for preference rather than first language. Plenty of people who work comfortably in a second language would still rather receive support in their own, and plenty of others prefer English because that is where the technical vocabulary they know lives. Only the person can tell you which.
Allow it to be overridden per ticket for the cases where somebody deliberately writes in another language, but make the record the default rather than the exception.
Language is a second dimension
The common design error is to treat language as a replacement for skill routing, producing a Spanish queue and a German queue and losing the distinction between a network problem and a licence request.
You need both dimensions, and in most desks skill should dominate. A network specialist who does not read the language will resolve a routing problem faster than a fluent generalist who cannot, with a translation step in between. The exception is anything requiring back-and-forth with the user, where language dominates because the exchange is the work.
A workable rule: route on skill first, then prefer an agent with the language within that skill group, and fall back to skill alone with a translation aid.
A worked example
A desk of nine agents supporting six countries built queues by language. Within a quarter two problems appeared. The two largest language queues were busy and the three smallest were nearly idle, so three agents were underused while the main queue backed up.
Worse, specialist knowledge had fragmented. The only agent who properly understood the VPN stack sat in one language queue, so tickets about it from five other countries were handled by people learning it from scratch. Average resolution on that topic rose by half.
Rebuilt as skill queues with language as a preference attribute within each, resolution times fell back and the idle capacity disappeared, because every agent could now take any ticket in their specialism and only preferred the ones in their language.
Setting it up
What to do:
- Capture preferred language at onboarding and sync it to the service desk as a user attribute.
- Keep your existing skill-based queues. Add language as a preference within them, not as a replacement.
- Allow a per-ticket override for people who deliberately write in another language.
- Define the fallback explicitly: which agent group receives a ticket when nobody with that language is on shift.
- Only create a dedicated queue for a language once its volume would keep somebody occupied.
- Report reassignment counts by language monthly and treat a high rate as a routing defect.
The fallback is the item most often left undefined, and the result is a ticket sitting unassigned in a queue nobody is watching because the rule matched a group with nobody on shift.
What to measure
Reassignment count per ticket, split by language. The cleanest signal of a routing fault. A population whose tickets are reassigned twice as often as average is being misrouted, and that is a rules problem rather than anything to do with the agents involved.
Time to first assignment, by language. Distinct from first response. A long gap before anybody owns the ticket usually means the rule matched an empty group.
Clarification exchanges per ticket, by language. More than two suggests the language preference was wrong or ignored, since the cost shows up as repeated attempts to establish what the problem is.
Where tooling fits
An answer layer in front of the queue reduces how much routing you have to get right, because the repeatable majority never reaches an agent. Figures below were read from each vendor’s own pricing page on 5 and 7 October 2026.
| Zendesk | $55 plus $50 per agent per month | Deepest routing rules of the set |
| Freshservice | $19, $49, $99 per agent plus $29 for Freddy AI | Routing plus service workflow |
| Crisp | Free, $45, $95, $295 per month per workspace | Shared inbox, team size does not change the bill |
| Matram | $29, $69, $199 per month flat | Answers ahead of the queue, 95+ languages |
Disclosure: Matram is owned by the same people who publish PeopleOpsHQ. It does not route tickets and is not an ITSM platform, so it sits in front of a service desk rather than replacing one, and it has no free tier. If routing itself is your problem, the per-agent platforms are the stronger purchase. All eight are in our multilingual IT support comparison.
Final thoughts
Routing by language fails in two predictable ways: detecting the language from short ticket text, and replacing skill queues with language queues. The first produces confident misroutes, and the second fragments specialist knowledge while leaving small-language agents idle.
Route on the requester’s recorded preference, keep language as a preference inside your existing skill groups, define the fallback for when nobody is on shift, and watch reassignment counts by language. That is most of the work and none of it needs new tooling.
Frequently asked questions
Should we detect the language of the ticket or use the requester’s record?
Use the record, because automatic detection performs well on a paragraph and poorly on the short, proper-noun-heavy text that IT tickets actually contain. A subject line consisting of a product name, an error code and three words carries almost no linguistic signal, yet detection will still return an answer with confidence and route on it. Capturing preferred language at onboarding and syncing it to the service desk as a user attribute is stable and correct even for a one-word ticket.
Should we create a queue per language?
Only once a language has enough volume to keep somebody genuinely occupied, and even then keep it as a preference inside your skill queues rather than as a parallel structure. Language queues fragment specialist knowledge, so the one person who understands a particular system becomes unavailable to five other countries, and they leave agents on smaller languages idle while the main queue backs up. Skill should usually dominate, with language as a preference applied within each skill group.
What should we ask employees about their language preference?
Ask which language they would prefer to receive IT support in rather than what their first language is, because the two answers differ more often than people expect. Some staff who work comfortably in a second language still want support in their own, while others prefer English specifically because that is where the technical vocabulary they know lives. Only the individual can tell you which, and the preference question predicts behaviour while the first-language question does not.
What happens when no agent for that language is on shift?
Whatever you have defined, and the common failure is having defined nothing, so the ticket sits unassigned in a group with nobody watching it. Write the fallback explicitly: which agent group receives the ticket, whether the requester is told that it will be handled in another language, and what translation assistance the agent is expected to use. This single rule prevents the most frustrating version of the problem, which is a ticket that was never slow to answer because it was never picked up.
How do we tell whether routing is working?
Report reassignment count per ticket split by language, since that is the cleanest signal available and it isolates the rules from the agents. A population whose tickets are reassigned roughly twice as often as the average is being misrouted, which is a configuration defect rather than a performance issue for anybody involved. Add time to first assignment by language, because a long gap before anybody owns a ticket usually means a rule matched a group with nobody on shift.
Does a self-service layer reduce the routing problem?
It reduces how much of it you have to get right, which is a meaningful difference. The repeatable majority of IT volume, covering access, provisioning, setup and connectivity, can be answered from your own documentation in whatever language the question arrives in, and none of those tickets reaches a queue at all. What remains is the smaller set that genuinely needs a person, where getting the routing right matters more and is easier because the volume is lower.
