Routing Tickets by Department, Form and Mailbox

At Acme, helpdesk@example.com and facilities@example.com both forward into the same mailbox, because when the ticketing tool was set up it seemed simpler to have one. A ticket about the fire door on the second floor that will not latch has been sitting with the IT team since Tuesday. A ticket about a laptop that will not charge has been sitting with the facilities team since Monday, because the requester guessed. Each team has looked at the other's ticket, decided it was not theirs, and left it where it was. Both teams have been polite about it for a week, which is the most expensive form of politeness there is.

Routing is the set of mechanics that decides which team's queue a new ticket lands in before any person reads it. It is plumbing, not judgment: the mailbox a message arrived in, the choice a requester made on a form, the department a chat widget or an interface key is tied to. Get the plumbing right and most tickets start in front of the people who can do them. Get it wrong and the desk spends its mornings passing tickets across a corridor. This article is part of our Queues & Routing series. This article is about the plumbing.

It covers why routing happens before anyone reads the ticket. Next come one department per mailbox and why addresses are the most reliable signal you have. Then come the form that picks the department and the default department as the catch-all and why it must be watched. After that come chat, social and interface doors bound to a department, and mail screening as part of routing. Next are how to move a misrouted ticket without losing it and measuring misroutes. Last come a short war story and a routing rules table you can copy, filled in and blank.

Routing Happens Before Anyone Reads the Ticket

Routing decides where a ticket lands; triage decides what to do with it once it has landed. The two are different jobs done at different moments, and most confusion about queues comes from expecting one to do the other's work. Routing runs the instant a ticket is created, on the only facts available at that instant. Those are which door it came through and, if the requester chose, which team they chose. Triage is the sort that a person does afterwards: reading the ticket, giving it a priority, deciding who should own it. Routing cannot read. It should not try.

That limit is the point. A routing rule that only looks at the door is simple, reliable and boring, and boring is what you want from plumbing. The ticket that arrived at facilities@example.com belongs in the facilities queue because somebody chose that address. That choice is a better signal than any keyword in the body. The moment routing starts reading subject lines for the word "printer" it is doing triage badly. In that case, the desk will spend more time correcting it than it would have spent sorting by hand. The triager's discipline, channel by channel, is in Triage by Channel. Routing's job is to put the ticket in front of the right triager.

A department, for the purpose of this article, is a separate team inside the ticketing tool with its own queue. It usually has its own form, its own mailbox, its own sending address, its own promises and its own list of who can see what. IT, facilities, HR and a customer-facing support team are departments in this sense. Two IT technicians who sit together and work each other's tickets are not; they are one department with two people. The test is the one from What a Queue Is For. If a person on one team would never pick up a ticket from the other, they are separate departments and need separate routing. If they sometimes would, they are one queue.

One Department Per Mailbox

Every department gets its own address, and every address belongs to exactly one department. That is the whole rule, and both halves matter. A department with no address of its own has to share one. A shared address has to be sorted by hand or by keyword, both of which are triage pretending to be routing. An address that feeds two departments has the same problem from the other side. One address, one department, no exceptions, including the exception somebody will propose next month "just for the facilities stuff that is really IT".

Addresses are the most reliable routing signal you have because the requester chose them. Someone who wrote to facilities@example.com was thinking about the building. Someone who wrote to helpdesk@example.com was thinking about a computer. They may be wrong, and a few of them will be, but they are wrong far less often than a keyword rule is. When they are wrong the fix is a move, not a rewrite of the rule. Most ticketing tools let each department have its own incoming mailbox and its own sending identity. That way, replies from the facilities queue come from the facilities address and the thread stays in one place. Set that up on day one and never route by subject line. Not with keywords. Not "just for the obvious ones".

Forwarders and aliases are where this rule quietly breaks. The old address, the one on the posters and in everybody's address book, must forward into the right department's mailbox and nowhere else. Check every forwarder once a quarter, because a forwarding rule is loyal: it will forward to a leaver's personal mailbox for years without complaint. Check also that nothing human sits in the path. An address that forwards to a person who then forwards "the IT ones" to the desk is not a route. It is a person with extra mail, and the day that person is away the route is closed.

If you inherit a shared mailbox, the honest fix is to split it, and the honest timetable is a fortnight. Create the second address and point the second department's mailbox at it. Update the form and the intranet page. Send one message to the organisation saying which address is for what. For the fortnight after, the old shared address still exists and still lands in one department. During that fortnight, that department moves the other team's tickets by hand and tells the requester the new address in one line. I once pointed two departments at one mailbox and sorted by hand for a month. I called it triage. It was a hobby.

The Form Picks the Department

A web form is the one door where the requester can be asked, and the first thing to ask is which team they want. Most tools let the form offer a department choice. Many then show a different set of fields depending on the choice. That way, the facilities form asks for a room number and the IT form asks for an asset tag. The department choice is routing. The fields are triage material, gathered early. Keep the two in that order on the page: choose the team first, then answer the team's questions.

Name the choices in the requester's words, not the organisation chart's. "Something is broken on my computer", "I need access to something", "The building, a desk or a room", "A question for HR". A requester who sees "Infrastructure Services" and "End User Computing" will pick one at random, and the random one is where the ticket goes. Keep the list to the number of departments that actually exist, which for most small organisations is between two and five. Put the busiest first. A form with twelve choices is a form that routes to "Other".

Resist the urge to make the form route finer than the department. A choice that sends "printer problems" to one person and "e-mail problems" to another is a skill rule in a form's clothing. It has every weakness of a skill rule: the requester classifies the symptom, the rule trusts the classification, and the person it routes to may be on leave. The models and their trade-offs are in Round-Robin vs Skill-Based Routing vs Just Claiming. The conclusion that matters here is that the form should route to a team, and a person inside the team should claim.

A category, where your tool has one, is a different thing from a department and should stay different. The department is who; the category is what. Some tools have a category field, some a tree, and some only a custom field on a form. In all three cases the category is triage data that reports read later, not a routing signal. If your form carries a category, let it carry one, and route on the department anyway.

The Default Department Is the Catch-All

Every ticket that cannot be routed lands somewhere, and that somewhere is the default department: the queue the tool uses when the door gives it no better signal. A form submission with no choice made, a message to an address nobody mapped, a ticket created by an interface key with no department bound to it, a chat from a page with no team set. The default exists in every tool, whether or not anybody chose it. If nobody chose it the tool chose it, usually on the day of installation, and usually as the first department that was created.

Choose the default deliberately and make it the busiest, best-staffed queue, which on most desks is IT. The reasoning is that the default is where misrouted and unroutable tickets collect. So it should be the queue read most often by people most able to move things. A default that points at a small department, a department nobody reads daily, or a department that was created for a test and never deleted is a hiding place with a name. A route needs three things: a door, a department, and somebody who reads that department's queue. The default is where the third one is most often missing.

Watch the default's share. If a quarter of the tickets landing in the default department belong somewhere else, the form or the addresses are not doing their job. The monthly routing review in Queue Hygiene: A Weekly Routine is where that number gets looked at. A healthy default receives tickets that really are its own plus a thin trickle of strays. An unhealthy one is where the rest of the organisation's confusion is stored.

Chat, Social and Interface Doors Are Bound to a Department

Every door into the desk must land in exactly one department. The doors that are not mail or a form are the ones people forget to bind. A live chat widget is usually embedded on a page, and the page belongs to somebody. The intranet page is for staff and routes to IT. The public site is for customers and routes to the customer team. Many tools let a chat visitor choose a department before the first message, or let you set one per widget. Find out which yours does and set it, because a chat with no department set goes to the default. The default was not expecting a conversation.

Social direct messages, where the desk takes them, come through a channel that is configured once and routes to one department, nearly always the customer-facing one. Treat the configuration as a routing rule and write it in the table below, because in a year nobody will remember where those messages go or why. The same goes for anything that creates tickets by an application interface: a monitoring system, an internal form on another site, a script. Most tools that offer an interface let a key or token be tied to one department. The tie should be made on the day the key is issued. A key with no department is a door that opens into the default, and a monitoring system can open it two hundred times in a night.

The table lists each kind of door, the signal routing uses for it, where it should land, and who owns the setting. Fill in the right-hand column for your desk, because the owner is the person who will be asked, in eighteen months, why the chat on the careers page goes to facilities.

Mail Screening Is Part of Routing

Not everything that arrives at a department address is a request, and the part of routing that decides what becomes a ticket at all is mail screening. Bounces, out-of-office replies, newsletters, delivery reports and bulk mail all arrive at helpdesk@example.com. A desk that turns every one into a ticket has a queue full of nobody. Most tools apply built-in rules that drop the obvious cases and let you add your own. Those can act on the sender, the subject, the domain, the body or an attachment name. There are three outcomes: block it, allow it, or hold it for a person to look at.

The hold outcome is the one to think about, because it creates a second queue. Held mail waits somewhere until a person approves it as a ticket or discards it. That somewhere is a place a real request can sit unread if the rule that held it was too broad. Some tools keep held mail for a fixed number of days and then discard it. Find out how long yours keeps it. Find out who reads the holding queue, because the honest answer on many desks is nobody. Add it to the weekly review. A held message from a new supplier's domain is a request wearing a suspicious coat, and the coat should not cost it a week.

Write screening rules narrowly and in the department they belong to. A rule that blocks a newsletter sender is harmless. A rule that blocks everything from a domain is a rule that will one day block the one person at that domain who needed help. Review the rules at the monthly routing check and delete the ones nobody can explain. Keep a one-line note beside each survivor saying why it exists. The rule that nobody can explain is the one that is holding something important. (It is usually holding something important about payroll.)

Moving a Misrouted Ticket

A misrouted ticket is one that landed in a department that cannot do it, and some misrouting is normal. The requester guessed wrong, the address was ambiguous, the form choice was read too fast. The measure of good routing is not zero misroutes but a small, stable number of them, each one moved within a day of arriving. The move is the thing to get right, because a misrouted ticket that is moved badly is worse off than one that was never moved at all.

Move it through the tool, as a transfer to the other department, never by forwarding the e-mail by hand and never by closing it and asking the requester to resubmit. A transfer keeps the ticket number, the history and the requester's link to it. A forward creates a second ticket with a second number and a first message that begins "FW:". The requester now has two tickets, one of which is closed and one of which they have never heard of. Most tools record who moved a ticket and when in its history, so a move is never silent. Leave a one-line internal note saying why you moved it. "Door lock, not IT; moved to facilities." Eleven words, and the receiving team does not have to guess.

Tell the requester, in one line, from the receiving department if the tool lets you choose, so the reply arrives from the address they will use next time. "Your request is about the building, so I have passed it to the facilities team, who will reply from this address." That sentence does two things. It reassures the requester that the ticket exists and is moving. And it teaches them the address for next time, which is the cheapest routing improvement there is. The requester who is told nothing learns nothing and writes to the same place next month.

Know who can move. Many tools restrict transferring a ticket between departments to a higher permission level than replying, which is sensible. That means each department must have at least one person on duty with that permission every day. If the only person who can move tickets out of facilities is on leave, misrouted tickets collect there for a fortnight with everybody looking at them and nobody able to act. Check the permission, name the people, and write them in the routing table. The handover note that goes with a move, and how to make sure the receiving team actually picks it up, is in Transferring a Ticket Between People or Departments.

Measuring Misroutes

Count misroutes once a month, by department pair, and the count will tell you which door is leaking. Most tools can show transfers between departments in a ticket's history, and some can report how often tickets changed hands. Where yours cannot, a search for tickets with a transfer in the last month and a tally in a spreadsheet takes ten minutes. Nine tickets a month moved from IT to facilities means the form or the address is sending building problems to the computer people. In that case, the fix is a clearer form choice or a poster with the right address. Nine moved from facilities to IT means the opposite. Three in each direction is noise.

The number matters less than the direction. Misroutes that all flow one way point at one door, and one door is fixable. Misroutes that flow every way point at a form with the wrong words on it, and the words are fixable too. The only misroute pattern with no fix is the one nobody counted, because it looks, from inside each department, like a handful of strays. Added up across the desk it is a day a month of polite moving.

A Short War Story: Two Addresses at Harbourview Clinic

Harbourview Clinic had two addresses on its intranet page: it-help@example.com, which fed the ticketing tool, and reception@example.com, which fed a receptionist's personal inbox. From that inbox, she forwarded anything that looked technical to the desk by hand, usually within the hour, usually with "FW:" and no other words. On a Saturday morning a nurse, Grace, could not sign in to the patient-record system and wrote to reception@, because that was the address she knew. The receptionist was off until Tuesday. The message sat in her inbox for three days while three clinic sessions ran on paper. Two staff spent most of Tuesday afternoon re-keying what had been written down. The desk, which had been quiet all weekend, first heard about it when the practice manager asked why nobody had answered. The forwarding arrangement had worked reliably for fourteen months, in the sense that it had always forwarded when the receptionist was there. The clinic made reception@ a department address in the tool and bound it to the IT queue. It taught the receptionist to move tickets to facilities instead of forwarding mail. An address that forwards to a person is not a route; it is a person with extra mail, and the route closes whenever they do.

The Routing Rules Table

The template is the routing rules table filled in for one organisation, followed by a blank to copy. Fill in a row for every door, including the ones you think are obvious, and the default at the bottom. Keep it in the knowledge base where the desk can read it, and read it at the monthly routing review. When a row changes, change the table first and the setting second, so that the table is always the thing you trust. Here is the Acme version after the shared mailbox was split.

ROUTING RULES — ONE PAGE
Organisation: ______________________   Maintained by: ____________   Reviewed: monthly

DEPARTMENTS (one line each)
  ______________  address: ______________________  queue read daily by: ____________
  ______________  address: ______________________  queue read daily by: ____________
  ______________  address: ______________________  queue read daily by: ____________

DEFAULT DEPARTMENT
  Name: ______________   Why this one: ______________________________
  Read daily by: ____________   Strays last month: ____

DOORS
  Door                      Signal                 Lands in        Can move out      Owner
  ______________________    ___________________    ____________    ______________    __________
  ______________________    ___________________    ____________    ______________    __________
  ______________________    ___________________    ____________    ______________    __________
  ______________________    ___________________    ____________    ______________    __________
  ______________________    ___________________    ____________    ______________    __________

FORWARDERS AND ALIASES
  Old address               Forwards to            Checked on
  ______________________    ___________________    __________
  ______________________    ___________________    __________

SCREENING
  Held mail is kept for ____ days.   Holding queue read weekly by: ____________
  Rules nobody can explain: deleted on ____________

MONTHLY COUNT
  Misroutes this month: ____   Main direction: ____________ to ____________
  Fix agreed: _____________________________________________   Owner: ____________

Back at Acme, the shared mailbox was split on a Wednesday. The form got three choices in plain words. The fire door and the laptop were each moved to the right queue with a note. The following month, nine tickets crossed between IT and facilities, all in one direction, all from people who had written to the old address. The poster went up on the Thursday. It is still the most effective routing rule the desk has.

Frequently Asked Questions