Language and timezone routing

Two questions decide this stage. Can somebody read what the customer wrote, and is that person awake right now. Language and timezone routing answers both before a ticket lands in a queue. The output is a queue or a named agent. It also records the detected language and the detector's confidence.

Machine translation is a different tool with a different purpose. It lets an agent handle a language they do not speak, at some cost to nuance and to the customer's patience. Routing decides who gets the ticket. Translation decides what happens after. Teams that treat translation as coverage end up with no native speakers on staff and no way back.

Timezone is the half people underrate. A perfect language match who signs off in ten minutes is worse than a decent match at the start of a shift. The router needs the roster, not just the skill list. Shift data has to come from the scheduling system and stay current.

One flag per language is too blunt. Reading a bug report, writing a policy explanation, and taking a phone call are three different abilities. An agent may read German comfortably and refuse to write it. Store a level per language per channel, and let agents set their own.

The supported language list is a policy, not a detection result. Support ops decides which languages get a queue, which get best effort, and which get a polite reply in English. The detector may recognize forty languages. The org supports the ones it staffed.

Each supported language needs a fallback path written in advance. Nobody on shift, holiday coverage gone, sudden volume from one region. The fallback can be a bilingual agent, a translated handling flow, or a message telling the customer when someone will be available. An unstaffed language queue with no fallback is a ticket that ages silently.

Customer preference beats detection when it exists. If an account holds a stated contact language, use it. Someone who writes in English but asks for replies in Japanese has already answered the question. Detection covers the cases where nobody has stated a preference.

Intake can simply ask. When a customer opens a form, a language selector removes the guess entirely. Follow-up questions that fill required fields before submission can carry that selector, and the stated answer overrides anything the detector later returns.

Detection runs on the first message, before any other routing step. Short text is the hard case. A three-word chat opener gives the classifier almost nothing, and confidence should reflect that. Longer email bodies are close to solved.

Set a confidence gate and decide what sits below it. High confidence in a supported language routes to that language queue. Low confidence sends the ticket to a general queue with the top two candidates shown. Guessing between Spanish and Portuguese on eight words costs a transfer and an apology.

Mixed-language tickets are common and normal. Engineers paste English error strings into a French description. Detection should read the prose and ignore the log block, or it will call the ticket English. Turning every channel into one ticket schema helps, because the parsed fields separate quoted output from what the customer wrote.

Voice needs its own handling. A phone call routes on the language of the caller in real time, and a transcript arrives later. Chat and email allow a moment of detection before assignment. Treat those as separate rules rather than one shared threshold.

Match on language first, then filter by who is working. The order matters. A router that picks the freest agent and then checks language will route a Japanese ticket to an idle agent in Ireland. Language is a hard constraint. Availability is a ranking among those who pass it.

None of the detail that follows is real. A consumer drone maker sells in twelve countries and staffs two support sites. Lisbon covers Portuguese, Spanish, and English from early morning to evening Western European time. Vancouver covers English and French, and overlaps Lisbon by three hours.

A pilot in Brazil writes at eleven at night local time. The message is in Portuguese and describes flight logs that will not upload after a battery firmware update. Detection returns Portuguese with high confidence from a long message. The Lisbon queue is closed for another five hours.

The fallback rule fires. One Vancouver agent, Ana, lists Portuguese at reading level and English at native level. The router assigns the ticket to her and sets a note on the ticket saying the language match is partial. The customer gets an automatic acknowledgment in Portuguese with an expected first reply time.

Ana reads the logs, confirms the firmware version, and writes her findings in English on an internal note. She does not answer the customer. At seven in the morning Lisbon time, the ticket moves to Rui, who writes the reply in Portuguese using her notes. Two agents, one handoff, and no machine translation in front of the customer.

The site lead in Lisbon set that pattern by hand after a bad month. Overnight tickets used to wait until morning untouched. The rule now says a partial match may investigate but never replies. Reply quality stays with the language queue. Even a drafted response grounded in knowledge-base sources gets sent by the person who speaks it.

Confident misdetection is the expensive one. The detector returns Spanish for a Catalan ticket, routing sends it to a Spanish queue, and the agent handles it without comment. Nobody logs a correction, so the pattern repeats. Give agents a one-click way to fix the language field and count those fixes.

Language queues hide their own backlog. A queue with two agents can look calm in an aggregate dashboard while every ticket in it is a day old. Report wait time per language, not just per team. Forecasting which tickets will breach their target is more useful when it can see the small queues separately.

Roster drift breaks routing quietly. Someone changes shifts, takes leave, or moves to a different team, and the language profile stays where it was. A router reading stale availability will keep assigning to an empty seat. Pull shift data from the source system daily.

Rare-language speakers get typecast fast. The one agent who speaks Dutch receives every Dutch ticket regardless of topic, and their work narrows to translation duty. Their skills on other topics stop growing. Cap the share of a single agent's queue that any one language may fill, and check that cap monthly.

Every automatic assignment here is reversible by the shift lead. The router cannot see a customer who asked for a specific agent. It cannot see an agent halfway through an escalation. Reassignment takes one action and needs no reason field.

Agents own their own language levels. A self-declared level is more accurate than a manager's guess, and it changes as people study. Send a reminder twice a year asking each agent to confirm or update the entry. Levels nobody has confirmed in a year should be marked stale rather than deleted.

Adding or dropping a supported language is a staffing decision, not a configuration change. One person should own that list, usually the support director who owns headcount. A queue created without hires becomes a place where tickets go to wait.

Language and timezone narrow the candidate pool. They do not identify the best person inside it. Once the pool is set, topic fit and current load decide. That work belongs to ticket content matched against agent skill profiles and the queue-depth checks beside it. The lead watches both and moves anything that looks wrong.