Auto-Routing Rules That Do Not Misfire on Real Tickets

Tuesday, 10:15, at Redbrook Engineering. Lena opens the identity team's queue and finds twenty-three new tickets with the word "account" in the subject. Four are about user accounts, which is her job. The other nineteen are about supplier accounts in the finance system, raised by the accounts payable team after an overnight upgrade. None of them is anything Lena can fix. They are in her queue because of a routing rule written two years ago by a technician called Sam, who has since left. It reads: if the subject contains "account", move to Identity. Across the building the finance systems team has an empty queue and a growing suspicion that the upgrade went well. Sam's rule has worked flawlessly for two years, in the sense that it has done exactly what it says.

An auto-routing rule is a rule that decides which department a new ticket belongs to, without a person reading it. It is the second rung of the automation ladder, above the acknowledgment and below the timers. It is the first rung where a misfire costs the requester real time. A ticket in the wrong department is a ticket in a queue where everyone who sees it has already decided it is somebody else's. This article is part of our Ticket Workflow Automation series. This article is about writing routing rules that put tickets where they belong and fail loudly on the rare occasions they do not.

This article covers what a routing rule decides and what it should leave alone. Next come the four handles a rule can hold a ticket by: mailbox, form, sender and keyword, in order of reliability. Then come the default department that catches everything else and what happens when two rules match. We cover the ten-real-tickets test before any rule goes live, then the quarterly review. A short war story follows, then the routing rule register to copy. The design of the queues themselves, which departments exist and why, is in Routing by Department, Form and Mailbox. This article assumes the departments and decides how tickets reach them.

What a Routing Rule Decides

A routing rule decides the department, and nothing else. It does not decide who in the department will work the ticket, how urgent the ticket is, or what the ticket is about. Those are three separate decisions, each made by a person later. A rule that tries to make them at the same time as routing is three rules wearing one coat. Keep routing to the question "which team's queue should this appear in?" That is because that question has a factual answer most of the time, and the others do not.

The rule gets its answer from one of four handles, and the handles differ enormously in how often they are right. The mailbox the message arrived at. The form the requester filled in. The sender, meaning the requester's address or the domain after the @. And the keywords in the subject or body. The first three are facts about where the ticket came from. The fourth is a guess about what the ticket means. A rule built on a fact misfires when the fact is wrong, which is rare and easy to see. A rule built on a guess misfires when the guess is wrong, which is often and easy to miss. Sam's rule is the fourth kind.

Most tools let you route by at least two of the four. Some have a rules editor where you combine any of them. Some tie a department to a mailbox and a form and offer nothing more. Some leave keyword matching to a script outside the tool. Whatever yours offers, use the handles in the order below, and reach for the fourth only when the first three cannot answer the question. The order is not a preference. It is the order in which the rules stop being right.

Handle One: The Mailbox

The most reliable routing rule on any desk is one address per department. Mail sent to facilities@example.com is a facilities ticket; mail sent to hr-requests@example.com is an HR ticket; mail sent to helpdesk@example.com is an IT ticket. The requester chose the department when they chose the address, usually from a contacts page or a signature that told them which to use. The rule simply honours the choice. In QuerySolv a department comes with its own mailbox and its own web form. So the department is decided by the door the request came through before anything resembling a rule is involved. That is the arrangement to copy in any tool that allows it.

Mailbox routing misfires in two ways, both visible. The first is the wrong address used on purpose: the requester knows helpdesk@ and sends everything there, including the broken door handle. That is not a rule failure; it is a ticket in the default department, and the daily glance at the default catches it. The second is the forwarded message. A manager forwards a facilities complaint from helpdesk@ to facilities@ and the ticket is created in facilities with the manager as requester. That is a requester problem rather than a routing one. Neither is a reason to avoid mailbox routing. Both are reasons to keep the list of addresses short and to publish it somewhere people actually look.

Mailbox routing decides nothing about the content, which is its strength. A ticket about a password sent to facilities@ goes to facilities, where someone reads it, sees it is not theirs, and moves it. The move is visible in the ticket's history. The rule did what it said, a person corrected the one case in fifty, and the correction is recorded. How a mailbox becomes a queue in the first place is in How a Mailbox Becomes a Queue.

Handle Two: The Form

The web form is the second handle, and it is nearly as reliable as the mailbox. That is because the requester is again choosing the department, this time from a list rather than an address book. A desk with one form and a "which team?" drop-down is routing by form. A desk with a separate form per department, each linked from that department's page on the intranet, is routing by form more reliably still. That is because the requester reached the form by already knowing which team they wanted.

Form routing misfires when the list of choices asks the requester to know something they do not. "Infrastructure" and "End-user computing" are two options that mean nothing to a person whose laptop will not connect to the projector. They pick one, it is wrong half the time, and the rule faithfully files the ticket where they pointed. The fix is in the form, not the rule. It means fewer choices, named in the requester's words, with the most common department first and a plain "not sure" option that goes to the default. The design of forms that get usable answers is its own subject, in A Request Form People Will Finish. For routing, the only rule is that every choice on the form maps to exactly one department and the "not sure" choice maps to the default.

A form also carries fields the mailbox cannot, and those fields can route too. A "site" field can send tickets from the northern depot to the technician who covers it. A "system" field can send tickets about the finance system to the team that owns it. These are still facts the requester supplied, and they are the only safe way to route by what a ticket is about. The requester said which system. The rule did not guess.

Handle Three: The Sender

The sender's address, and especially the domain after the @, is the third handle. It is the right one when the department depends on who is asking rather than what they asked. Mail from anyone at a partner's domain goes to the team that handles that partner. Mail from a subsidiary's domain goes to that subsidiary's support group. Mail from the directors' assistants goes to the senior technician who has agreed to take it. The fact being read is "who sent this", which the mail system supplies and the requester cannot easily get wrong.

Sender routing misfires in three ways, and the first is the most common: the domain changes. A partner is acquired, a subsidiary is renamed, or a supplier moves its mail to a new domain. The rule, which has the old domain written into it, silently stops matching. The tickets do not vanish; they fall to the default department. That is why the default must be read daily. It is also why every sender rule in the register has a note saying "check the domain still exists" beside its review date. The second misfire is the forwarder: a message that arrives from an internal address but was forwarded from the partner. So the rule sees the wrong sender. The third is a shared address, where fifteen people send from one mailbox and the rule routes them all the same way. That is fine until one of them is the finance director with a different problem entirely.

Use sender rules sparingly and write each one down with the reason it exists. A desk with twenty sender rules has twenty domains to keep current and twenty reasons somebody has forgotten. A desk with three, each for a partner that genuinely needs its own queue, has a routing design it can still explain after the person who built it has moved on. Nobody at Redbrook knew Sam's rule existed until it misfired.

Handle Four: The Keyword

Keyword routing reads the subject or the body for a word or phrase and routes on a match. It is the last handle because it is the only one that guesses. "Account" means a user account to the identity team, a supplier account to finance, and a customer account to sales. The rule matches all three with equal confidence. "Printer" appears in tickets about printing, about toner, about a printer somebody wants to buy, and about the print server. "Phone" means a desk phone, a mobile, the phone system, and a request to phone someone back. Human language was not designed for pattern matching, and it shows.

Keyword routing is safe in exactly one situation: when the keyword was put there by a system rather than a person. A monitoring tool that sends alerts with the fixed subject "ALERT: disk space on SRV-FILE01" is giving you a label. In that case, routing on "ALERT:" or on the server name is routing on a fact. An order system that e-mails "New starter request: Priya Nair" is doing the same. A requester typing "my account is locked" is not labelling anything. They are describing, in their own words, and their words are not your rule's words. Route on labels. Never route on descriptions.

Before writing any keyword rule, run the ambiguity test: search last month's tickets for the keyword and read every match. If more than one ticket in twenty would have gone to the wrong department, the rule will misroute one ticket in twenty forever. In that case, a person triaging would have got all twenty right in about the same number of minutes. Keyword rules that fail the test can still earn their keep as a hint rather than a decision. Add an internal note saying "subject matched 'account'; check identity or finance" and leave the department to the triager. The same guess that makes a poor router makes a useful suggestion. The limits of keyword matching when the goal is a category rather than a department are the subject of the next article, Auto-Categorization and Its Limits. The limits are the same ones.

The Default Department as the Safety Net

Every ticket that no rule claims must land somewhere a person reads every day, and that somewhere is the default department. On most desks it is the general IT queue, because that is where the triager already sits. Its job is not to work the tickets; its job is to be the one place a ticket can land without being invisible. A desk without a default has tickets that belong to nobody. A desk whose default is a queue nobody reads has the same thing with a name on it.

The default is also the desk's instrument for measuring its routing. Count how many tickets land in the default each week and where the triager moves them to. If a third of the default's tickets are moved to facilities, facilities needs its own door, or its door needs publishing. If the default is receiving tickets from a partner domain that used to route elsewhere, a sender rule has stopped matching. If the default is nearly empty, the rules are working, and that is the only way to know. A default department with no one counting what passes through it is a bucket, not a net.

Read the default at fixed times, twice a day, as part of the triage rhythm rather than as a separate task. The triager asks of each ticket "is this ours, and if not, whose?" They move it and leave a one-line internal note saying where it came from and why it was moved. That is because that note is the data the quarterly review runs on. The routine for looking in the places tickets go to be forgotten, of which the default is only one, is in Keeping Tickets From Hiding. The default is the drawer everyone knows about, which is what makes it the safe one.

When Two Rules Match

Sooner or later a ticket will match two rules, and the tool will do one of three things. It will apply the first rule in its list, apply the last one, or apply both in order so that the second overwrites the first. Which one yours does is written in its documentation. More reliably, it is discovered by sending it a test ticket that matches two rules and reading the result. Find out before you have ten rules, because the behaviour decides how you order them.

In a first-match tool, order the rules from most specific to most general. A rule for mail from the lab partner's domain goes above a rule for mail to the clinical systems mailbox. That is because a message from the partner to that mailbox should follow the partner rule. A rule for a specific monitoring subject line goes above any rule for the monitoring mailbox. The general rules sit at the bottom, and below them, catching everything, is the default. In a last-match tool the order is reversed, which is a cheerful trap for anyone who has moved between tools. Check which you have before copying a register from somewhere else.

Two rules may genuinely conflict, where a ticket could reasonably go to either department. In that case, the answer is not a cleverer rule but a conversation between the two departments about who owns that kind of ticket. The conversation is written into the register, and one rule reflects the decision. Fewer rules, each one a sentence a new technician could understand, beat a precise cascade that only its author could follow. The author has usually left.

Testing a Rule With Ten Real Tickets

No routing rule goes live until it has been applied by hand to ten real tickets, and the test is more useful than it sounds. Pull ten tickets from the last month that the rule would have matched. Print the rule's one sentence at the top of the page. Have two people, separately, write down where each ticket should have gone. Then compare. A mailbox or form rule will usually score ten out of ten with both people agreeing. A sender rule will score ten unless a forwarder is in the sample, which is a useful thing to find. A keyword rule will score somewhere between six and nine, and the two people will disagree about one. That disagreement is the misfire rate you are about to automate.

Then pull ten tickets the rule would not have matched and check that none of them should have. This is the half of the test everyone skips, and it finds the rule that is too narrow. One example is the sender rule that lists one partner domain when the partner uses two. Another is the form rule that maps six of the seven choices and leaves one falling to the default. A rule can be wrong by routing a ticket it should not have. It can be wrong by missing a ticket it should have caught, and the second kind is silent.

Switch the rule on with its owner watching for a week. The owner reads the receiving department's new tickets daily for the first five working days and the default department's for the same period. They look for strays in either direction and write any misroute in the register with the ticket number. Five misroutes in a week means the rule comes off and goes back to the test. None means it stays, and the owner's job drops to the quarterly review. A week of watching costs an hour. The alternative is Lena's Tuesday, two years later.

The Quarterly Review

Once a quarter, read the register against the routing data, and ask three questions of every rule. Did it misroute anything, and how often? The internal notes left by the triager when moving a ticket are the evidence; count them by rule. Is the fact it reads still true? Domains change, forms are redesigned, and mailboxes are retired. A rule that reads a fact which has stopped being true is a rule that has quietly started doing nothing. Does anyone still know why it exists? A rule whose owner has left and whose reason nobody can state is switched off for a month to see what happens. If nothing happens, it stays off. If tickets start landing in the default from somewhere unexpected, you have learned what the rule was for. In that case, you write it down this time.

The review also looks at the default's traffic for the quarter, because that is where the missing rules show. A department that received thirty tickets via the default in three months needs its own door. A partner whose mail has been arriving in the default since their domain changed needs its sender rule updated. The whole review for a desk with a dozen rules takes an hour, and the hour is the difference between a routing design and a routing archaeology.

A Short War Story: The Silent Domain at Harbourview Clinic

At Harbourview Clinic, a sender rule routed every message from the pathology partner's domain to the clinical systems team. It had worked quietly for three years. Then the partner merged with a larger laboratory group and moved its staff to the group's mail domain over one weekend. The rule, which still named the old domain, stopped matching on the Monday. The partner's messages fell into the general IT default, which at Harbourview was read when someone remembered. A message reporting that the results interface was rejecting a batch of blood tests sat in the default for nine days. Meanwhile, a technician called Rosa in clinical systems wondered why the partner had gone quiet. The laboratory, hearing nothing back, re-sent two hundred results by fax for the clinic's staff to type in by hand. The cost was nine days of delayed results, three evenings of typing, and a conversation with the clinic's medical director that Rosa described afterwards as "brisk". The rule was updated in four minutes once anyone knew to look at it. Harbourview now reads the default twice a day and counts what lands there. It keeps a line in the register beside every sender rule that says which domain it reads and who confirms each quarter that the domain still exists.

The Routing Rule Register

The register is one page per desk, one block per rule, in the order the tool applies them. Fill in the first block for the default department before anything else, because the default is the rule that exists whether or not you write it down. Each rule block records the handle it uses, the fact it reads, and the one-sentence rule. It also records the test results from the ten real tickets, the owner, and the misroutes since the last review. Keep it beside the tool, and update the misroute line whenever the triager moves a ticket that a rule put in the wrong place. The review is a reading of this page and nothing more.

ROUTING RULE REGISTER — ONE PAGE PER DESK
Desk: ______________________   Maintained by: ______________   Last review: __________
Tool applies rules:  [ ] first match wins   [ ] last match wins   [ ] all in order
Test ticket sent to confirm this on: __________

DEFAULT DEPARTMENT
  Department: ______________   Read by: ______________   At: ____:____ and ____:____
  Tickets landed here last quarter: ____   Moved to:  ________ ____  ________ ____  ________ ____
  Department that needs its own door, if any: ______________

RULE 1   (order in the tool: ____)
  Handle:  [ ] mailbox   [ ] form   [ ] sender   [ ] keyword (system label only)
  Fact it reads: ______________________________   Still true, checked on: __________
  Rule in one sentence:  When ______________ if ______________ move to ______________
  Test: 10 matching tickets, correct ____ / 10   Two reviewers agreed: [ ] yes  [ ] no
        10 non-matching tickets, missed ____ / 10
  Owner: ______________   Deputy: ______________   Reason this rule exists: ______________
  Switched on: __________   Watched for one week by: ______________   Misroutes that week: ____
  Misroutes since last review: ____   Ticket numbers: ______________________________
  Review outcome:  [ ] keep   [ ] fix: ______________   [ ] switch off for a month   [ ] retire

RULE 2, RULE 3 ...   (one block per rule, in the order the tool applies them)

RULES WITHOUT A KNOWN OWNER OR REASON
  ______________________________   switched off on __________   effect after a month: ______________

QUARTERLY SUMMARY
  Rules in force: ____   Misroutes this quarter: ____   Worst rule: ______________
  Facts that changed (domains, forms, mailboxes): ______________________________
  Next review: __________   By: ______________

Redbrook's register, when Lena and the finance systems lead finally wrote it, had eleven rules in it. Four were rules nobody could explain, and two read domains that no longer existed. Sam's "account" rule became an internal note that says "subject mentions account; identity or finance?" The triager decides, which takes her about four seconds a ticket. The rule had been right, by its own lights, for two years. Nobody had asked it the question it was getting wrong.

Frequently Asked Questions