No Shadow SLA: Keeping Priority Honest for Executives

Thursday, 07:58, at Tollgate Foods. Two tickets arrive a minute apart. Ticket 4470 is from the warehouse: the handheld scanner that checks goods onto lorries has stopped. A shift of twelve is standing still, and a lorry is at the bay with a driver on a clock. Ticket 4471 is from Beth, assistant to Lorna, the finance director: Lorna cannot print the pack for the auditors, who are due at ten. Dev, on the desk for eight months, reads both and reaches for 4471. Amira, who runs the desk of three, watches him do it and asks why. He thinks about it. "Because it's Lorna." He is not wrong about what he was taught. He is wrong about who taught it, which was nobody.

A service level agreement, usually shortened to SLA, is the written promise of how fast the desk will respond to and resolve a ticket. It has a different target for each priority. A shadow SLA is the same promise made to a few people, never written, enforced by habit and nerves, and measured by nobody. It is the fastest kind of promise there is: nobody has to write it, nobody can check it, and everybody keeps it. Dev reaching for Lorna's ticket while a shift stood still was the shadow SLA at work. The cure is not to make him slower for Lorna but to separate two things the desk had quietly fused. Those are how a ticket is handled, and where it sits in the queue. This article is part of our VIP & Executive Support series. It is about keeping that separation honest.

It covers why priority is impact and urgency rather than rank, then how a shadow SLA forms. Next come the VIP marker as context rather than priority, with a picture, and being fast for the executive without breaking the queue. Then come the cases where the executive's ticket genuinely is high priority, and saying no upward when it must be said. The marker in the tool, a decision table, and keeping the rule honest month to month follow. A short war story and the VIP marker rule to copy finish the article, in that order.

Priority Is Impact and Urgency, Not Rank

Priority is the desk's answer to "which ticket is worked first when two compete". On a well-run desk it comes from two questions only. The first asks how much of the organisation is affected, which is impact. The second asks how soon the harm starts, which is urgency. The scanner ticket affects twelve people and a lorry, now, with no way round; its impact is high and its urgency is high. Lorna's ticket affects one person who has a working printer in the next office. Its impact is low, and its urgency, with the auditors two hours away, is moderate at most. Run through any honest grid, 4470 comes first. The grid itself, and how to apply it in the moment, is the subject of Impact Times Urgency in Practice, and this article does not redo it. It assumes the desk has one and asks what rank is allowed to do to it.

The honest answer is nothing, directly. Rank is not a column in the grid, and the moment it becomes one the grid stops measuring harm and starts measuring the organisation chart. Rank does, however, show up indirectly and legitimately, because the people at the top of the chart tend to have higher-impact problems. More people wait on their decisions, bigger audiences watch them fail, and their hour is attached to more of the organisation's work. When the chief executive cannot present to the board in forty minutes, the impact is a boardroom of people and a decision that will not be taken. That is high impact by the grid, not by the title. The rule is that the executive's ticket may be top priority because of what it stops, never because of who raised it. The difference sounds small on paper and is the whole difference in a queue.

Who decides the priority is also settled, and it is the desk. The requester proposes, the desk decides, the manager arbitrates, in that order, and the etiquette of lowering a self-selected priority without a slight is in Who Decides the Priority. The executive is a requester like any other for this purpose, with one practical difference. They rarely set the priority themselves, because the assistant raises the ticket. The assistant has learned to say "urgent" because it works. It works because of the shadow SLA. Remove the shadow and "urgent" from the assistant becomes what it is from anyone, a proposal the desk reads and decides on.

How a Shadow SLA Forms

A shadow SLA starts with one fast fix that went well. A director's laptop died before a client meeting, a technician dropped everything, the meeting happened, and the director said thank you to the technician's manager. Nothing about this was wrong. The next time the director had a problem the same technician moved just as fast, because the first time had been praised. The time after that a different technician moved fast because they had seen the first one do it. Within a year the desk had a rule that nobody had made, that nobody could cite, and that nobody felt able to break. Dev learned it in eight months from watching. That is the only way anyone learns a shadow SLA, which is how you can tell one from a policy.

The shadow is enforced by two things, neither of them a document. The first is anxiety: the technician does not know what happens if the director waits, and a thing you do not know the cost of feels expensive. The second is silence from above: the desk lead has never said "the outage comes first, whoever is waiting". So the technician fills the silence with the safest guess, which is to serve rank. Shadow SLAs are not created by executives. In my experience, executives are mostly unaware that one exists. They are created by desks that were never told what the rule was and worked one out from the praise.

The cost of a shadow SLA lands on the people who are not under it. Every time a technician leaves a shift-stopping ticket to swap a dock, the shift pays and the ordinary queue's response time stretches. The people in it learn that the desk is slow, which is not true but is what they can see. The shadow is never measured because it is never named, so the desk's reports show a slightly worse ordinary queue and no reason for it. The reason is standing on the fourth floor, being thanked.

The Marker Is Context, Not Priority

The fix is a VIP marker: a flag on the ticket or the requester. It tells the technician the ticket is from someone on the list and changes how the ticket is handled. The priority beside it is set by impact and urgency exactly as for anyone. The marker and the priority are two separate fields with two separate jobs, and the entire discipline of this article is keeping them separate. The marker says a person answers, now. One of the two named technicians takes it. The work happens by visit or through the assistant. The screen is turned and the note stays plain. The priority says: where this ticket sits against every other ticket in the queue. The marker never writes to the priority field. Not once, not for the chief executive, not "just to be safe".

The picture below shows the two tickets from the opening scene side by side. Lorna's ticket carries the marker and a Low priority, because one person is affected and a printer next door works. The warehouse ticket carries no marker and a High priority, because a shift has stopped with no way round. The bar under both says they sit in the same queue on the same clock and are worked in priority order, 4470 first. The two panels at the bottom are the list the whole rule reduces to. One shows what the marker changes: who answers, how fast a human replies, where the work happens and how discreetly. The other shows what it never changes. Those are the priority, the order of work against a higher priority, the service-level clock for everyone else, and the identity check before any reset or access.

The picture has one deliberate omission. There is no arrow from the marker to the priority, and there is no row in the bottom-right panel that the marker is permitted to touch. A desk that draws its own version of this picture and finds itself adding "unless the executive is in a meeting" has found its shadow SLA. It should write this in the "what the marker changes" panel instead, where it belongs. The executive in a meeting gets a visit and a loaner in minutes. They do not get the lorry's place in the queue.

Fast for the Executive Without Breaking the Queue

Being fast for the executive is almost entirely about the first minute, and the first minute costs the queue nothing. Dev's correct move at 07:58 was to pick up the phone to Beth: "I've got Lorna's ticket. The printer in the next office is on the same queue and will print the pack now. I'll be up to look at hers as soon as the warehouse scanner is back, which I expect inside the hour." That call takes ninety seconds. It gives the assistant a person, a workaround and a time, which is everything the shadow SLA was delivering. It leaves Dev free to work the scanner. The executive's experience of the desk is that it answered at once and solved the problem. The warehouse's experience is that the desk worked their outage first. Both are true, and nothing in the queue moved.

The second tool is the workaround-first habit. Most executive tickets have a workaround the executive does not know about and the assistant can apply. Examples are the printer next door, the loaner on the shelf, the deck sent to the assistant's laptop, and the phone's own mail instead of the laptop's. A technician who offers the workaround in the first call has bought the time to work the queue honestly. The executive has lost nothing but a few steps down a corridor. The fix still happens, at the right place in the queue. The pack still prints at 08:05.

The third tool is the named technician who does not hold the outage. On a desk of three, the two technicians named for the list should be the ones least likely to be holding a shift-stopping ticket at any given moment. When both are, the lead takes the executive's first call. This is a rota question rather than a priority question: the queue order does not change. The person who steps up the stairs for the dock is the person whose current ticket can wait, not the one with the lorry. And the small-fix exception applies to the executive as to everyone. A fix that takes two minutes at the desk, a password unlock, a print queue cleared, is done at once regardless of priority. The cost of recording it exceeds the cost of doing it. The exception is for everyone, which is what keeps it from being a shadow.

When the Executive's Ticket Really Is High Priority

Sometimes it is, and the rule has to let it be, or technicians will learn that the rule is a lie and go back to the shadow. The chief executive presenting to the board in forty minutes with a laptop that will not start has a high-impact problem. There is a boardroom of people, an external audience, a decision that will not be taken today. The finance director who is the only person able to release the payroll, with the payroll due at noon, has a high-impact problem. Three hundred people's pay is behind that ticket. The sales director who cannot join the client call in ten minutes, where the client is deciding, has a high-impact problem. In each case the priority is high by the grid, and the ticket goes to the front for the same reason the scanner did: what it stops.

The discipline is to write the impact in the ticket, in words the grid uses. "Board meeting at 09:00, twelve attendees, no other presenter" is a priority that can be read and checked a month later. "Chief executive" is not. Technicians who are made to write the impact learn quickly that most executive tickets do not have one that reaches High, and that the few that do are easy to defend. It also protects the technician. When the department head asks why the chief executive's ticket went ahead of theirs, the answer is in the ticket. It is in the same language as every other priority decision the desk has made.

The border case is the executive who says "this is urgent" about something that is not. The answer is the same courteous sentence the desk uses for anyone who has set a priority higher than the grid gives. The sentence says: the desk has it, here is what is being done now, here is what is ahead of it and why, and here is when it will be reached. The marker buys the executive that sentence from a named person within minutes, by phone, rather than in an automated reply. It does not buy a different sentence.

Saying No Upward When It Must Be Said

Occasionally the executive, or more often someone speaking for them, asks for the thing the rule forbids. The requests sound like "push it to the front", "pause the outage", or "skip the identity check because you know my voice". The technician cannot grant it and should not refuse it alone. The move is to say no to the method and offer what can be done now. Send the decision to the person who owns the rule, in writing, with the deadline. That shape, and the three mistakes of caving, refusing alone and going quiet, is the whole of Saying No Upward. This article leans on it rather than repeating it. The priority rule's owner is the desk lead or the sponsor who signed the charter; the identity rule's owner is whoever owns security. Both are a phone call away. The technician's sentence is "that's a call I can't make; I've sent it to Amira now, and here is what I can do in the meantime."

What makes the sentence sayable is the charter from What VIP Support Is, and Is Not, in which the sponsor signed the line that priority is set by impact and urgency for everyone. A technician reading from a page the executive's peer signed is not expressing an opinion about the executive; they are describing the organisation's rule. Without the page, every upward no is a junior technician against a director. With it, it is the director against a decision they were party to, which is a conversation directors handle rather well.

A manager override is still possible and still legitimate: the desk lead can decide that this ticket, today, goes ahead for a reason the grid did not capture. The rule is that the override is recorded in the ticket with the name of the person who made it and the reason. That way, it can be read later and counted. An override written down is a decision. An override that lives in a technician's reflex is the shadow coming back.

The Marker in the Tool

Most help desk tools can carry a marker without being told what it means. It might be a tag on the ticket or a custom field on the requester. It might be a department or group the list's members belong to, or a flag the desk uses by convention. Pick one. Apply it to the requester rather than the ticket where the tool allows, so that every ticket from the person inherits it. Make it visible in the queue view so the named technicians see it without opening the ticket. Where the tool has none of these, a word in the subject line applied by the triager works until it does. The marker is a convention. The tool does not need to understand it; the technicians do.

What the tool must not be allowed to do is turn the marker into priority by a rule. Some tools can raise priority automatically when a ticket comes from a given requester or group. The temptation to set that up is strong, because it would make the handling automatic. Resist it, because an automatic rule is a shadow SLA with a configuration page. The priority is set by a person reading the impact. The marker tells that person to read it quickly.

Two things in the tool do help. Service-level targets that are set per priority on a business-hours schedule, as in QuerySolv and most tools, leave a shadow SLA nowhere to live in the system. The clock for a Low ticket is the Low clock whoever raised it. So the only place a faster promise can exist is in the technician's head, which is where the charter goes to work. And an escalation flag that is separate from priority, which QuerySolv keeps as a distinct thing, lets the technician pull the lead's attention to an executive's ticket that needs a decision. The technician can do that without inflating its priority to get noticed. Where the tool has no such flag, an internal note addressed to the lead does the same job, a little more slowly.

The table below is a decision table for the five executive requests that arrive most often. It shows the priority the grid gives, what the marker does, and the sentence the assistant hears. It is written for the triager, so it is short and has no exceptions in it. The exceptions are the overrides, and those are recorded, not tabled.

Keeping It Honest Month to Month

A rule about priority drifts unless it is checked, and the check is cheap. Once a month, list the tickets carrying the marker and read the priority on each against the impact written in it. Count how many were worked ahead of a higher-priority ticket that was open at the same time. The number should be close to zero and every one above zero should have an override note with a name on it. A month with four unexplained jumps is a shadow regrowing. The fix is a five-minute conversation with the technicians who made them, which is coaching, not a reprimand. The method for reading the marker tickets as a cut of the same queue, and what to report, is the last article in this series, Measuring VIP Support Without a Separate Desk.

Watch the ordinary queue as well, because that is where the shadow's cost lands. If the ordinary queue's first-response time gets worse on days with executive visits, the visits are being paid for by the people who were not visited. In that case, either the rota is wrong or the marker is leaking into the order. Executives rarely notice a shadow SLA. The warehouse always does.

A Short War Story: The Five-Minute Rule at Redbrook Engineering

At Redbrook Engineering, a desk of four had for two years answered the managing director's tickets inside five minutes and worked them before anything else. The rule appeared in no document and every technician could recite it. That was because a technician called Priya had once rescued the managing director's laptop before a customer visit and been praised in the company newsletter. The rule cost nothing anyone could see until a Tuesday morning when the file service that the design office worked from failed at 08:40. The managing director's docking station failed at 08:45. The technician on triage, Marcus, went to the docking station, because that was the rule. The file service outage waited twenty-six minutes for the second technician to arrive at nine. By the desk lead's later count, eighteen designers lost around eight hours of work between them, and a drawing deadline for a client slipped a day. The managing director, asked about it afterwards, said he had not known the desk did that and would have told them not to. The desk lead wrote the marker rule that week and had the managing director sign it, which was the easiest signature she had ever obtained. The shadow had been protecting a man who did not want protecting from a queue he had never seen.

The VIP Marker Rule

The rule is a half-page that sits with the charter and is read by every technician on their first day on the desk. Section 1 says what the marker is and where it lives in the tool. Section 2 lists what the marker changes and section 3 what it never changes, and the two lists are the same length on purpose. Section 4 is the triager's four-line procedure for a marked ticket, section 5 the override record, and section 6 the monthly check. Fill in the blanks once; the only lines that change afterwards are the names of the two technicians and the minutes in section 2.

THE VIP MARKER RULE — HALF A PAGE
Desk: ______________________   Owner of this rule: ______________________   In force from: ____________

1. THE MARKER
   Lives on: [ ] the requester record  [ ] a ticket tag  [ ] a field  [ ] the subject line (interim)
   Applied by: ______________ (triager) for every requester on the charter list and their assistant.
   Visible in the queue view without opening the ticket: [ ]

2. WHAT THE MARKER CHANGES
   [ ] A person replies, by phone or in person, within ____ minutes in business hours
   [ ] One of the named technicians takes it: ______________ or ______________
   [ ] The first call offers a workaround and a time
   [ ] A visit, at a time the assistant picks; a prepared loaner offered for anything over ____ minutes
   [ ] Discretion standard applies; the note records the fault and the fix only

3. WHAT THE MARKER NEVER CHANGES
   [ ] The priority, which is set by impact and urgency, by the desk, by the grid
   [ ] The order of work against any higher-priority ticket, whoever raised it
   [ ] The service-level targets and clocks, which are per priority, not per person
   [ ] The identity check before any reset or access change
   [ ] Any policy; exceptions go to the policy's owner, never granted by the technician

4. TRIAGE OF A MARKED TICKET (four lines)
   1. Set the priority from the impact and urgency written in the ticket; write them if missing.
   2. Call the assistant (or the person) inside ____ minutes: who has it, the workaround, the time.
   3. Work it in queue order; a named technician who is holding a higher-priority ticket hands
      the call, not the ticket, to the other named technician or the lead.
   4. Note what was done, and nothing seen.

5. OVERRIDES
   A marked ticket worked ahead of a higher-priority ticket is an override, and the ticket records:
   Decided by: ______________   Reason (in grid words): ______________________   Time: ______

6. THE MONTHLY CHECK
   Marked tickets this month: ____   Worked ahead of a higher priority: ____   Of those, with an
   override note: ____   Ordinary-queue first response on visit days vs other days: ______ / ______
   Read by the lead with the named technicians; coaching, not ranking.

Dev called Beth at 08:00, and the pack printed next door at 08:04. He was on the warehouse scanner until 08:35, when it turned out to be a charging cradle. He was at Lorna's desk by 08:50 with a new cable. Lorna, who had never known there was a rule about her, thanked him for the quick call and asked how the warehouse was. The lorry had left at 08:40. The auditors arrived at ten with a printed pack. Nobody on the fourth floor noticed that the queue had been kept honest, which is exactly what it looks like when it is.

Frequently Asked Questions