Escalation Boundaries That Hold

"See above." That is the entire escalation note on ticket 4471, which arrived in the second-line queue at 11:52 on a Wednesday. Above the note is the user's original message, which says the supplier invoice export "isn't working again," and nothing else. No error text, no list of what was tried, no guess at a cause. Marcus, who is second line this week, reads it twice and starts the diagnosis from the beginning. That is where first line started it ninety minutes ago.

Nobody on that desk is careless. The ticket moved because the person holding it ran out of ideas. It moved empty because nobody had ever written down what a ticket must carry when it moves. An escalation is moving a ticket to a higher tier. A bounce-back is the higher tier sending it down again. An escalation boundary is the written rule that says when each of those happens and what travels with the ticket. This article is part of our Support Tiers series. It is about the lines between the tiers: where to draw them, how to cross them, and why they leak.

It covers why boundaries leak and the three rules that make one hold (a list, a time box, and a handoff). Then come the four-line handoff note and the bounce-back rule. Next it covers the "kick it upstairs" habit and the two numbers that cure it, then one ticket worked end to end. It ends with a war story from a bank, and a handoff template and a boundary card to copy. Writing a handoff a stranger can act on, in depth, is a later subject. Here we keep to the contract.

Why Boundaries Leak

Boundaries leak for three reasons, and none of them is a person. The first is that nobody wrote the boundary down. "Escalate when you need to" lives in the head of whoever set up the desk. So each first-line technician draws the line in a different place, and somewhere else again on a bad day. A rule that exists only in heads is not a rule. It is a mood.

The second reason is that there is no time box. A time box is a fixed amount of effort after which a ticket moves whether or not it feels close. Without one, escalation happens on frustration. A technician who enjoys the puzzle keeps the ticket for three hours; one with a difficult morning passes it on at minute four. Neither has broken a rule, because there is no rule to break.

The third reason is that the higher tier accepts anything. If second line picks up every ticket that lands, however empty, the queue learns that empty is acceptable, and the leak is rewarded every time. This leak does the most damage, because it is invisible. The tickets still get solved. They get solved twice, once in each queue, and the first time does not count.

The ticket that has visited four queues by Thursday is the end state of all three leaks together. Each queue looked at it, recognized nothing, and passed it on with a note shorter than the one before. By the fourth queue the note is one word, and the word is "escalating". The ticket has been diagnosed in none of them.

The Three Rules That Make a Boundary Hold

A boundary that holds has three parts, each written down and each short enough to fit on a card. What is a list: the ticket types first line resolves, and the ticket types it escalates at once. When is a time box plus a trigger: thirty minutes of first-line effort, or any change to a system, whichever comes first. How is the handoff content: four lines that travel with the ticket when it moves. The next three sections take them in turn.

I have seen a tier diagram with seven levels on a desk of three people. Each level had its own color, which was helpful, because nothing else about it was. The three rules are the opposite of that diagram: fewer lines, more words on each, all of them about what happens to a ticket rather than who outranks whom.

What: The List

The "what" rule is two lists, and the first is the longer one. The resolve-here list names what first line finishes without asking anyone: the known-error list (problems with a known cause and a written fix), and password resets and account unlocks. It also names access requests that are inside policy and the ten ticket types that make up most of the volume. This list is the first-line section of the tier charter in L1, L2, L3 in Practice, which has a template for the whole thing.

The escalate-now list is short and absolute. Anything that needs a change to a system rather than a fix within it. Anything affecting more than a handful of people at once. Anything that looks like a security event. Anything involving lost or altered data. These do not wait for the time box. They move in the first five minutes, with as much of the handoff note as five minutes allows.

The point of the lists is to turn a judgment call into a lookup. A judgment call costs the technician something every time, and the cost goes up as the day goes on. A lookup gives the same answer at 09:00 and at 16:40. The lists also make the boundary arguable in a useful way. If a ticket type keeps bouncing, the argument is about moving one line on a card, not about whether someone is pulling their weight.

Without the lists, first line escalates what it finds boring and keeps what it finds interesting, and so would anyone. The lists exist to stop the queue sorting itself by interest.

When: The Time Box, Done Honestly

The "when" rule is a time box measured in effort, not elapsed time. Thirty minutes of actual work is a sound default for a small desk. It is long enough to work through the known-error list and the obvious checks. It is short enough that an escalated ticket still has most of its resolution target left. Waiting for the user does not count. Working another ticket does not count. The clock runs when hands are on the problem.

Escalate on time, not on frustration. When the box runs out, the ticket moves, including when you are sure you are nearly there. "Nearly there" is the most expensive phrase in the queue, because it is said with equal confidence at minute thirty and at minute ninety. The user cannot tell the difference. The time box protects the user's afternoon from a feeling.

The time box has a floor as well as a ceiling. Escalating at minute four, before checking the known-error list and trying the first two things on the card, is not early; it is empty. The rule is therefore: the lists first, then up to thirty minutes, then move.

The time box and the SLA clock are different clocks. A service level agreement, or SLA, is the promise to the user about response and resolution times. Its clock runs on the user's time from the moment the ticket exists. The time box runs on the technician's effort. Set the box so that a ticket escalated at the limit can still be resolved inside the promise. The SLA Design series covers the promises themselves.

How: The Four-Line Handoff

The "how" rule is that a ticket never moves without four lines, written as an internal note the user does not receive. Reported: what the user said, in their words, with who and where. Tried: what first line did, in order, and what each step showed. Found: what is known now, facts first, with any guess marked as a guess. Asked: what first line wants from second line, in one of four words: diagnose, change, advise, or take over.

Four lines is the minimum that lets the next person start where the last one stopped. "Reported" saves them re-reading the thread. "Tried" stops them repeating the obvious checks, which is where most of the ninety minutes on ticket 4471 went. "Found" is the diagnosis so far, often further along than first line realizes. "Asked" tells second line what finished looks like, so they do not take over a ticket that needed one sentence of advice.

Without the four lines you get "see above", and above is empty. The user explains the problem twice. Second line repeats first line's first twenty minutes. The thing first line noticed but did not write down, which was the actual clue, is noticed again on Friday by somebody else. The note takes three minutes. The repeat takes forty.

The Bounce-Back Rule

A ticket may come back down once, with a reason, and never silently. That is the whole rule, and each clause does a job. Once: if the two tiers disagree a second time, the ticket does not go back. It goes to whoever owns the boundary, who settles it and changes the card if the card was wrong. With a reason: one of three. The ticket is on the resolve-here list (say which item). The handoff is missing a line (say which). Or the cause is now known and the fix belongs to first line (say the cause, and point at the article).

Never silently is the clause that matters most, because a bounce is information. Every bounce says one of two things: the line is in the wrong place, or the handoff was incomplete. Both are fixable, and only if the reason is written down. The illegitimate bounces are easy to name: "not ours" with nothing after it, a reassignment with no note, a reply asking the user a question first line already asked. Each sends the ticket back down the stairs without telling it why. A ticket passed up and down is not being worked. It is being exercised.

The good bounce is a teaching move, and it is where the boundary learns. When second line sends a ticket back with "group membership change, list item three, article 112," first line has learned one thing. The known-error list has grown by one entry. The next three tickets of that kind never leave first line at all. Over a year, most of the resolve-here list gets written by bounce-backs with reasons.

One Ticket, One Escalation, One Bounce

Here is the whole boundary working on a single ticket at Acme. At 09:12 on a Tuesday, Lena in accounts e-mails the desk: the supplier-invoices folder on the shared drive shows as empty. She needs the files for a payment run at noon. It becomes ticket 6230. Sam, on first line, acknowledges at 09:14 and names 09:50 as the next update time.

Sam works the lists. The known-error list has nothing for "folder empty." He opens the folder from his own account on files.example.com and sees forty-three files, so the data is there. On Lena's machine, WS-ACC-07, the drive is mapped, the folder opens, and it is empty from her side. The folder's permissions show a group name he does not recognize, FS-Invoices-RW. At 09:44 his effort is at thirty minutes. He does not keep going.

At 09:46 he escalates to Marcus with the four lines as an internal note, and tells Lena the next update will come by 11:00.

Reported: Lena (accounts, WS-ACC-07) sees the supplier-invoices folder on
          files.example.com as empty since this morning. Payment run 12:00.
Tried:    known-error list (no match); folder from my account (43 files);
          Lena's machine, drive mapped, folder opens but empty; folder
          permissions show group FS-Invoices-RW, which I do not know.
Found:    data is on the server; the problem is on the permission side;
          FS-Invoices-RW is new to me (guess: added recently).
Asked:    diagnose. If it is a group change I can do it once I know which.
Effort so far: 30 minutes.   Next update promised to user: 11:00

Marcus picks it up at 10:02 and the "Tried" line saves him the first twenty minutes. He goes straight to the group. At 10:11 he finds that the folder was moved to a new share on Friday. The old group was replaced by FS-Invoices-RW. The new group was built from a stale list that did not include Lena. Adding a user to a group is item three on the resolve-here list. At 10:13 he sends the ticket back, once, with a reason: "Cause: folder moved Friday; Lena not in FS-Invoices-RW. Group membership is first line, item 3. Known-error entry added; expect more from accounts."

Sam adds Lena to the group at 10:19, she confirms the files are visible at 10:24, and the ticket resolves. Elapsed time seventy-two minutes; first-line effort thirty-eight minutes; second-line effort eleven. Lena had three updates and never explained the problem twice. The next day two more people from accounts report the same folder. Both tickets finish on first line in under ten minutes, because the bounce came back with a reason.

"Kick It Upstairs" and How Tiers Create It

Tiers create the sport of kicking tickets upstairs. The moment there is an upstairs, the fastest way to make a ticket leave your queue is to send it there. This is not laziness. It is arithmetic. If first line is measured on queue length, every escalation makes first line's day lighter and second line's week heavier. In that setup, nothing in the tool shows the transfer as a cost. Like most sports, it is more fun for the people not holding the ball.

The first fix is credit for resolving at first line. The number first line is praised for, in the weekly review and out loud, is tickets resolved without escalation, not tickets touched or queue length at 17:00. Say it, show it, and the sport loses its scoring system. The second fix is making the first-line resolution rate visible where the whole team sees it. That is the share of tickets closed without ever leaving first line. Put it next to the bounce-back rate. Measuring Whether Your Tiers Work sets out what both look like when healthy and when gamed. The third fix is the one from the previous section. Every bounce-back with a reason moves the boundary down by one ticket type, which is slower than a rule and lasts longer.

Without the fixes, first line hollows out into a routing desk that reads tickets and forwards them. Second line fills with resets. The senior engineer ends up drowning in the shallow end, put there by the system. That is the desk tiers were supposed to prevent, running on tiers.

A Short War Story: Bluewater Bank

Dana ran the Bluewater Bank support desk, three people on first line and two on second. For one month she counted the bounce-backs. Of eighty-five escalations, thirty-four came back down, twenty-nine of them without a note of any kind. The second-line engineers had begun quietly re-triaging the whole first-line queue each morning to save themselves the trouble later. Dana made the four lines mandatory in the tool: the transfer form would not submit with Reported, Tried, Found or Asked left blank. The first week produced a few notes that read "n/a," which she treated as the form's problem rather than the technicians'. She reworded the labels into questions. By the fourth week the bounces were nine out of ninety-two. The morning re-triage had stopped on its own, and nobody had been spoken to about anything.

I have written "see above" on an escalation myself. Twice. The second time, by an administrative accident, I was also the person who had to read it, which is the only training on the subject I have ever needed.

The Handoff Note and the Boundary Card

Both templates are meant to be copied, shortened, and pinned up. The handoff note goes in the tool as the internal note on every transfer, or as four fields on the transfer form. The boundary card is one page, owned by one named person, and reviewed when the bounce-back rate says it should be.

HANDOFF NOTE (internal; travels with every escalation)
Reported: who, where (machine or location), what they said in their own
          words, and any deadline they mentioned.
Tried:    each step in order, with what it showed. Include the known-error
          list check even when it found nothing.
Found:    what is known now. Facts first. Mark any guess as a guess.
Asked:    one of: diagnose / change / advise / take over.
Effort so far: ___ minutes.   Next update promised to user: __:__

ESCALATION BOUNDARY CARD        Owner: ____________   Reviewed: ________

RESOLVE HERE (first line finishes these without asking)
  1. Anything on the known-error list, by its written fix
  2. Password resets and account unlocks, after the identity check
  3. Access requests inside policy (groups, shared folders, lists)
  4. ___________________________   (the top ten by volume go here)

ESCALATE NOW (no time box; move within five minutes, note follows)
  - Any change to a server, network device or shared system
  - Anything affecting more than ___ people at once
  - Anything that looks like a security event or lost data

TIME BOX: ___ minutes of hands-on effort, after the lists have been tried.
          Waiting on the user does not count. At the limit, the ticket moves.

HANDOFF: four lines, every time. Reported / Tried / Found / Asked.

BOUNCE-BACK: once, with one of three reasons, never silently.
  (a) on the resolve-here list, item ___
  (b) handoff missing line ___
  (c) cause found; fix is first line's; see article ___
  A second disagreement goes to the owner, who changes this card.

A tool that records every transfer and assignment with a state snapshot shows you where tickets bounce, because the history is there to count rather than to remember. QuerySolv records every reply, note, status change, assignment and transfer that way. Nobody can delete a ticket, so the count of bounces is the count of bounces. On any tool, the discipline is the same: the note travels with the ticket.

Where the Boundary Stops Applying

The time box does not apply to a major incident. When the message is "the whole floor cannot log in," the escalate-now list already applies. In that case, the handoff is one line sent in the first minute with the other three following as they become known. Boundaries are for the steady state. In an incident, speed matters more than completeness, as long as the completeness arrives.

On a very small desk, first line and second line are sometimes the same person on different days. The four lines still matter, because they are being written to your future self, who will have forgotten everything. Tiers for a Three-Person Team covers what that looks like with one rotating lane. When third line is a vendor, the four lines become the opening of the vendor case almost unchanged. Vendors answer a case that contains "Tried" and "Found" faster. That is not generosity. Their first reply would otherwise be a request for exactly those lines.

Ticket 4471, the one that opened this article, would have arrived with Reported, Tried, Found and Asked. Marcus would then have started at minute ninety instead of minute zero. Above is no longer empty. That is the entire point of a boundary, and it fits on a card.

Frequently Asked Questions