Escalation Paths and Criteria, Written Down

Wednesday, 14:20. Ben has been on ticket 6137 since 12:05. It concerns a shared mailbox that opens for everyone in reception except Hana, who needs it to book the meeting rooms. He has removed and re-added her permission, cleared the cached credentials, signed her out and in, and rebuilt her profile. The mailbox still says "cannot be opened". Hana has asked twice, politely. The senior technician is in a meeting until three. Ben is about to try a fifth thing. He is not doing that because he thinks it will work, but because nobody has ever told him when he is allowed to stop. He is a good technician doing exactly what good technicians do when no one has drawn the line. The line is the problem, not Ben.

Escalation criteria are the written conditions under which a ticket must leave the hands of the person holding it. An escalation path is the written list of who it goes to, for each kind of ticket, when it does. Together they turn escalation from a personal judgement, made differently by every technician on every afternoon, into a rule the desk applies. This article is part of our Escalation Done Right series. It begins with What Escalation Means, the difference between moving a ticket sideways to a skill and raising it upward for attention. This article is about when either happens, and to whom.

It covers why the criteria have to be written rather than understood. Next come the four triggers that say "now": a time box, a skill gap, an impact threshold and a decision above your pay grade. Then come the written path for each kind of ticket and where that path ends, and the no-blame rule that makes the whole thing work. A short war story follows. The article ends with the escalation path table, which is the template to copy, and the week it takes to put the path on the wall.

Why the Criteria Must Be Written Down

Unwritten escalation criteria produce two kinds of technician, and both cost the desk. The first is the one who holds on too long, because asking for help feels like admitting something. Another reason is that nobody has said that the fourth attempt is the one too many. The second is the one who escalates everything at the first unfamiliar error, because nobody has said that the runbook's three steps come first. The first technician makes tickets slow. The second makes specialists busy with work the desk could have done. Neither is behaving badly. Both are guessing where the line is. A desk that makes people guess gets guesses.

Written criteria change the act of escalating from a confession into a procedure. When the rule says "thirty minutes of hands-on work without progress, then transfer", the technician who transfers at minute thirty-one has followed the rule. Under that rule, the specialist who receives the ticket knows that thirty minutes of sensible work precede it. Nobody's judgement is on trial. The rule is doing the judging. The rule can be argued with at the monthly review, in daylight, instead of in the technician's head at 14:20.

Written criteria also protect the requester, who is the person the whole exercise is for. Hana does not care whether Ben is being thorough or being proud. She cares that it is 14:20 and the meeting rooms are unbooked. A time box that says "stop at thirty minutes and hand this on" is a promise to Hana that the desk's stubbornness has a limit. Unwritten criteria make that limit whatever the technician's mood is that afternoon. The technician's mood is not something Hana can see on the ticket.

Four triggers cover almost every escalation a small desk makes, and the rest of this article takes them in turn. A time box is a fixed amount of effort after which the ticket moves on if it has not moved forward. A skill gap is the moment the next step needs knowledge or access you do not have. An impact threshold is a size of problem above which someone senior must know, whoever is working it. A decision above your pay grade is anything that needs money, a signature, a policy exception or a phone call you lack the standing to make. The first two usually send a ticket sideways; the last two usually send a flag upward. Any one of them is enough on its own.

The Time Box

The time box is the most useful of the four and the hardest to keep, because it asks technicians to stop doing the thing they are best at. The rule is simple: a fixed amount of hands-on effort. After that, if the ticket has not moved forward, it goes to the next stop on the path. Thirty minutes is a sensible default for an ordinary ticket. Fifteen minutes for a High or above, because the clock is tighter and a specialist is cheaper than a breach. The number matters less than its existence. A desk with a thirty-minute box and a desk with a forty-five-minute box both run better than a desk with none.

The box measures effort, not elapsed time. Thirty minutes of hands-on work spread across a morning of interruptions is still thirty minutes. A ticket that sat untouched for two hours while the technician handled an outage has used none of its box. This matters because the alternative, "escalate after two hours", punishes the technician for being busy and rewards the one who worked on nothing else. Keep a rough count of the time you actually spent, and be honest with yourself about it. The box only works if you stop when it says so.

"Moved forward" needs a definition or the box leaks. Progress means you learned something that narrows the cause. That could be a step that ruled something out, an error that changed when you changed a setting, or a log line that names a component. Trying a fifth thing that fails in the same way as the first four is not progress. It is the same failure with more history. Ben's rebuilt profile taught him that the problem was not Hana's profile, which is real progress. His time box should have ended there, with a transfer that said so.

The trap inside the time box is the phrase "one more thing". Every technician knows the feeling: the next idea is good, and it will only take five minutes. It feels as though handing the ticket on now means admitting that the last forty were wasted. They were not wasted. They produced a list of things that are not the cause, which is exactly what the specialist needs. The box exists to beat that feeling. It only does that if the desk agrees, out loud, that stopping at the box is the correct behaviour and continuing past it is the mistake. I spent two years thinking the opposite, and I was slower for every one of them.

Two refinements make the box fit a real desk. First, the box resets when the ticket genuinely changes shape. That could mean a new symptom, a reply from the requester with information that reopens the question, or a specialist's advice that gives you a fresh line to follow. Second, the box is shorter when the requester is waiting live, on chat or on the phone. Thirty minutes of silence on a chat is an abandoned chat. Ten minutes live, then either a specialist joins or the technician ends the live session with a promise of a time to come back.

The Skill Gap

The skill gap is the trigger that fires before the time box does, when you can already see that the next step is not one you can take. You do not have the login to the system. You do not understand the error well enough to type it into a search. The runbook's last step says "if still failing, contact the network team". The system belongs, by the desk's own written boundaries, to somebody else. Any of those is a skill gap. The correct response is to transfer the ticket now, with what you have learned so far. Do not spend the time box confirming that you cannot do what you already know you cannot do.

The honest sentence here is "I do not know what this subsystem does", and desks should make it an easy sentence to say. Nobody on a desk of four knows the mail server, the directory, the phone system, the line-of-business application, the firewall and the backup software to the depth needed to fix all of them. A desk that pretends otherwise gets technicians who type "exception" into a search box and hope. The skill gap is not about what you are capable of learning. It is about what you can do for this requester, today, inside this ticket's clock.

Which skills live where is a tier design question, not an escalation one, and this article will not redo it. There is a written list of which systems the desk owns outright and which it may touch up to a stated point. It also lists which belong to a specialist from the first minute. That list is the subject of Escalation Boundaries. What this article adds is the instruction to put that list's answer in the path table, one row per kind of ticket. That makes the skill gap a lookup rather than a feeling. If the row for "directory and sign-in" says "desk resets passwords and unlocks accounts; anything else to Ines", the technician who meets anything else does not have to decide whether they are out of their depth. The table decided in advance.

The skill gap has a quiet cousin, the access gap, where the technician has the knowledge but not the permission. The fix is sometimes to grant the permission rather than to escalate forever. The monthly review in Measuring Escalations is where a desk notices that it has transferred forty mailbox tickets to the same engineer for want of one admin role. Until then, an access gap is a skill gap for the purposes of the path, and the ticket moves.

The Impact Threshold

The impact threshold is the trigger that has nothing to do with whether you can fix the ticket. Above a certain size of problem, someone senior must know it exists, however well it is being handled. They will be asked about it by someone more senior still. They may need to tell other departments. And they may decide that two people should be on it instead of one. The threshold is written in terms of impact: a whole site, a whole department, a revenue process, a safety system, or more than a stated number of people. Cross it and the flag goes up, while the ticket stays with whoever is working it.

Pick numbers and write them down. "Significant impact" is not a threshold; it is an argument waiting to happen. A desk serving three hundred people might write: more than twenty people affected, or any whole team, or any site. It might also include anything that stops money moving or stops a shift working. The numbers will be wrong at first and the monthly review will fix them. A written wrong number beats an unwritten right instinct, because the written one is applied the same way at 09:00 by the senior and at 16:50 by the trainee.

The impact threshold overlaps with two other subjects, and the overlap is deliberate. How impact and urgency combine into a priority, and who gets to decide it, is the subject of Impact and Urgency in Practice. At the top of the impact scale, a ticket stops being a ticket. It becomes an incident with a coordinator and a communication rhythm of its own. That is the subject of What Makes an Incident Major. The escalation threshold sits below the incident line and above the ordinary ticket, and its only instruction is "tell someone senior now". What they do with the information is their job.

The threshold also catches the slow-growing ticket, which is the one most desks miss. A printer fault for one person is a Low. The same fault reported by the fourth person in the same building is no longer about a printer. The fourth technician to take one of those tickets may not know about the other three. A desk whose queue view shows the whole team's open tickets, not only each technician's own, gives technicians a chance to notice the pattern. Most tools can link related tickets, or at least let you note the other ticket numbers in each. That gives the lead one thing to look at instead of four. Noticing is the hard part. The flag is the easy part.

The Decision Above Your Pay Grade

The fourth trigger is any next step that needs authority rather than skill. A purchase. A policy exception, such as opening a mailbox that belongs to somebody on leave. Telling a director that the answer is no. Overriding a security control for a day. Choosing between two departments that each say the other owns the problem. Phoning a supplier's account manager rather than its help line. In each case the technician knows exactly what the next step is and is not the person who gets to take it.

The response is a flag, not a transfer, and the distinction matters more here than anywhere. The ticket stays with the technician, who continues to own the requester and the technical work. What goes up is a specific request: "I need approval to buy a licence key, roughly this much, by Thursday, because line two is running one scanner short." The lead decides and the ticket carries on. Transferring the whole ticket to the IT manager because one decision is hers puts a working ticket into a queue she does not watch. It puts the requester into silence too. The lead is a decision, not a destination.

Write the common decisions into the path table so the technician does not have to wonder whether a given thing is theirs to decide. Most desks find that six or eight cover nearly everything. They include spend over a stated amount, any access to another person's data, and any change to a security setting. They also include any deadline promise to a requester beyond the SLA and any work on a system outside the desk's catalogue. And they include any answer that amounts to "no" to someone senior. If the next step is on that list, flag it. If it is not, decide it. If you later turn out to have been wrong, the list gets a new row rather than the technician getting a conversation.

The decision trigger is where the hierarchy earns its keep, and it is also where it is most often abused in the other direction. A lead who insists on approving every transfer, every priority change and every reply to a manager has turned themselves into a trigger that fires on everything. They have turned the path into a queue of one. The list of decisions should be short, and the technician should be trusted with everything not on it. If the list grows past ten rows, the problem is not the technicians.

The Written Path for Each Kind of Ticket

A path is a row that says, for one kind of ticket, who the desk tries first and for how long. It says who the desk transfers to when the box runs out or the skill gap opens. It says who the desk flags when the impact threshold is crossed, and who makes the decisions that come up. One row per kind of ticket, ten to twelve rows for a small desk, on one page. The kinds come from the tickets, not from the organisation chart. Pull the last ninety days of tickets that were escalated, sort them into piles by what they were about, and name the piles. The piles are your rows.

Every stop on the path is a named person or a named role with a named person in it today, never a team. "Network team" is where tickets go to belong to everyone. "Ines, or Rafael when Ines is away" is a path. The second name is not decoration: a path with one name and no second is a path that closes when that person takes a day off. And the day they take off is the day the switch fails. If there is genuinely no second name, the row says so. In that case, it also says what to do instead. That is almost always "flag to the lead, who decides whether to wait or to call the vendor".

The path ends somewhere, and the end must be written too. For most rows the end is a vendor or an external team. Each such row names the contract, the support address and the case-opening steps, which the vendor escalation article covers in detail. For some rows the honest end is "nobody", because the system is unsupported. The path should say that plainly. Then the technician can tell the requester the truth in the first hour rather than the third day. A path that trails off into a blank cell is a ticket that will trail off into a blank month.

Where the tool can route a ticket to a team from the start, a good share of the path is already applied before a technician reads the ticket. Many tools let the requester pick a department on the form, give each team its own mailbox, or route on a form field. So a ticket about the phone system can land with the people who own the phone system without anyone transferring it. Some go further and assign tickets round-robin or by skill. That removes the first hop for the clear-cut cases. It does not remove the path. The ticket that arrives in the wrong queue, or that turns out to be about something else, still needs a row that says where it goes next. That ticket also needs somebody with the permission to move it there.

The No-Blame Rule

The no-blame rule is the one that makes the other rules work. It is the one most often broken by people who believe in it. The rule is: escalating a ticket according to the written criteria is never a mark against the person who escalated it, and never will be, in any review, appraisal or stand-up. Not "rarely". Never. The moment a technician learns that a transfer made in month three came up in a conversation in month six, the time box becomes a suggestion. Then the desk goes back to the fifth attempt at 14:20.

The rule binds the receiver as much as the sender. A specialist who sighs when a ticket arrives, who replies "did you even try restarting it", or who sends it back with "this is basic" has taught the whole desk that escalating is a social cost. The desk will respond by escalating less and sitting on tickets more. The two sentences a receiver says are "Thanks, I have it" and "What have you tried so far?" The second is only needed when the handoff note did not already say. The sentences a receiver never says are "why did this come to me" and "you should have known". If the ticket should not have come, the path table is wrong, and the table is fixed at the review.

No-blame does not mean no feedback. A desk that escalates the same kind of ticket forty times a quarter has something to learn. The place to learn it is the monthly review in Measuring Escalations. There, the question is "what would let the desk handle these" and the answer is a runbook, a permission, or a knowledge article. The feedback goes to the path and the training, not to the person. A path table that improves every month and a team that never gets blamed are the same achievement seen from two sides.

The handoff note is where the rule lives day to day. A note that says what was tried and what was learned is evidence that the time box was used well. A receiver who reads it can see the work rather than guess at it. The Handoff That Does Not Dump covers the note itself. Here the point is that the note is the sender's protection as much as the receiver's help. Nobody has ever been blamed for a transfer whose note listed four sensible steps and their results. People are blamed for "escalated, see ticket", and in a sense they should be, but it is the note that was wrong, not the escalation.

A Short War Story: Four Days of Trying at Harbourview Clinic

Harbourview Clinic's two-person desk had no written criteria. The appointment scheduling system began refusing to save bookings for one of the three reception screens. Nadia took the ticket on a Monday morning. She did what she had always been praised for, which was to keep going. She reinstalled the client on Monday, rebuilt the screen's profile on Tuesday, and swapped the machine on Wednesday. On Thursday she compared every setting against a working screen, between the forty other tickets of a clinic week. Meanwhile, reception double-booked the same slots on paper and rebooked sixty-three patients by phone. On Thursday afternoon the clinic's application specialist, who had been copied on nothing, saw the paper diary on the reception desk. The specialist asked what was going on, and found in twenty minutes that the screen's user account had a site setting pointing at a closed branch. Nadia had done nothing the desk's rules forbade, because the desk had no rules. She had worked harder than anyone that week to be the cause of the delay. The clinic wrote a thirty-minute time box and a path table the following Monday. The clinic put the lesson at the top of the table: the box protects the technician from their own diligence as much as it protects the queue.

The Escalation Path Table

The table below is the template, filled in for an invented desk so that the shape of each cell is clear. Replace the example names and the kinds of ticket with your own, keep it to one page, and put a date on it. The columns are the four triggers turned into questions. How long does the desk try? Who gets the transfer when the skill runs out? Who gets the flag when the impact is large? And who makes the decisions that come up? The last column is where the path ends when the desk's own people cannot fix it. Every cell names a person or says "none" in words; no cell is left blank.

Three things about the example are deliberate. The security row has a five-minute box and a flag every time, because a technician investigating a suspicious device alone is how a small problem becomes a large one. The "not in this table" row exists because the table will be wrong. A ticket that fits no row needs somewhere to go other than a technician's judgement at 16:50. And the "none when away" cells are written out in words, so that the day the specialist is away the technician reads "flag to lead" instead of an empty cell and a hope.

Add a row for each kind of ticket your desk actually escalates and no row for kinds it does not, however important they sound. Ten to twelve rows is right for most small desks. Beyond fifteen the table stops being read. The technicians go back to asking the person beside them, which is the system the table was meant to replace. If the number of rows keeps growing, look at whether several rows have the same answers and merge them. The row is there to give a different answer, not to list a different noun.

Putting the Path on the Wall

Rolling the path out takes about a week and almost no meetings. The order matters a little, because the table is only trusted once the people named in it have agreed to be named. Also, the no-blame rule has to be said out loud before the first time box fires. The checklist below is the whole rollout.

• Pull the last ninety days of escalated tickets and sort them into kinds; those kinds are the rows.
• Write one row per kind with a time box, a transfer name, a flag name, the decisions that go up, and where the path ends.
• Ask every named person whether they agree to be the name; change the name if they do not.
• Add a second name to every transfer cell, or write "none: flag to lead" in words.
• Write the impact threshold as numbers: how many people, which sites, which processes.
• Read the no-blame rule aloud at the stand-up and write it at the top of the page.
• Print the table, pin it where the queue is worked, and put it in the knowledge base with a date.
• Book the first monthly review before anyone has used the table.

The permissions in the tool should match the paper. Someone in the desk's most junior role may not be able to press the escalate button or reassign a ticket at all. Many tools ship a trainee role that sees only its own assigned tickets and can reply and leave private notes. These tools reserve escalation and the full queue for the next role up. A trainee's row in the path is therefore "write a private note with what you tried, and tell a named person who can move it". The named person is in the table. A path that assumes everyone can press every button will fail quietly on the first day a trainee meets a skill gap.

Expect the table to be wrong for the first month, and expect that to be fine. A time box that is too short will show up as transfers with thin notes. A box that is too long will show up as tickets that breach their response target before anyone else sees them. Most tools warn the assignee when a target breaches. A technician may get that warning on a ticket they have been trying to fix alone. In that case, they have just received the strongest possible argument for a shorter box. The table is a hypothesis about how the desk should work, and the monthly review tests it. By month three it is mostly right, and by month six nobody remembers deciding anything without it.

Ben's ticket 6137, from the opening, would have met the e-mail row's thirty-minute box at 12:35. It would have gone to Lukas with a transfer that said: "Shared mailbox opens for all of reception except Hana; removed and re-added permission, cleared credentials, rebuilt profile, same error each time; asking you to check the mailbox side; Hana books the meeting rooms and is waiting." Lukas would have found the mailbox's permissions had been applied to a disabled duplicate account in about ten minutes. Ben would have spent the afternoon on other tickets. Nobody would have had to tell him when to stop, because the paper on the wall would already have said.

Frequently Asked Questions