Moving Resolutions From the Specialists to the Front Line

Thursday, 15:10, at Stonebridge Insurance. Nadia, who runs the desk, has the shift-left map open. The top line on it is "policy system says session already open". That is thirty-odd tickets a month, every one resolved by Grace. She looks after the policy administration system and is the only person with the console that clears a stuck session. Nadia asks Grace whether the front line could take it. Grace says, in order: "It's not always a stuck session, sometimes it's the licence pool." "They'd clear the wrong one; there are three sessions per user and only one is stuck." "They'd need the admin console, and I'm not giving the front line the admin console." "Honestly it takes me two minutes, it's faster if I just do it." Then, after a pause: "And if they're doing that, what am I for?" Nadia writes all five down. She has just been given the handover plan, in the form of objections.

Moving a resolution to the front line is giving the people who first touch a ticket everything they need to finish a type of ticket they currently hand upward. It is three things done together. A runbook is the procedure written so a competent stranger can follow it. A permission to act is the right, technical and social, to do that one thing without asking. A written limit says when the front line stops and hands the ticket up. Any one of the three without the others fails in a way you can predict in advance. This article is part of our Shift-Left Strategy series. It is about the first step down the staircase, which is the step most desks get stuck on.

It covers the three things and why each fails alone; and the runbook as the specialist's minutes written down. It covers the permission to act; and the scripted fix as a permission with guardrails. It covers the specialist's reluctance and what each objection is really saying; the safety limits written down; and the rehearsal and the first month. It ends with a short war story and the handover-to-front-line checklist to copy, in that order.

Three Things, Not One

A runbook without a permission produces a front line that reads the procedure, reaches step three, and finds it needs a console they do not have. They escalate anyway, now with a note saying "see runbook". Nothing has moved except the paperwork. A permission without a runbook produces a front line with administrative rights and a memory of something Grace said once. That is how the wrong session gets cleared, and then the wrong user's session, and then the permission gets taken back with a story attached. A runbook and a permission without a written limit produce a front line that keeps going past the point where the procedure stopped applying, because nobody told them where that point was. Stopping feels like failing. Each failure is a predictable consequence of a missing third. The handover is complete only when all three are in place. That is why the checklist at the end of this article has three sections and the shortest one is the most often skipped.

Put the three in that order, because each depends on the one before. The runbook comes first because the permission can only be scoped to what the runbook does. The limit can only be written against the steps the runbook contains. A desk that grants permissions first, meaning to write the runbook later, has given the front line a key and a promise. The promise is the thing that gets lost. I have never once seen the later runbook arrive before the first wrong session was cleared.

The Runbook Is the Specialist's Minutes Written Down

The runbook for a shift-left move is the specialist's two minutes written so a stranger can do them. The craft of writing one, from the assumptions to the last-run date, is in Writing the Runbook. This article leans on that and does not repeat it. What this article adds is who writes it and from what. The specialist dictates and a front-line technician writes, from a real ticket, with the technician stopping the specialist every time a step assumes something they do not know. Grace alone would have written "clear the stuck session in the console" and considered it complete. Theo, writing, asked "which of the three sessions?" Grace said "the one with no activity in the last hour, that's how you tell". The runbook gained the sentence that made it work.

The specialist discovers what they know by being asked for it, and the discovery is usually a surprise to them. Grace's "it's not always a stuck session" turned out to mean that about one ticket in ten with that error message was the licence pool being full. That looks identical to the user and different in the console. She had been telling the two apart by a glance she could not have described until Theo asked her to. That glance became the runbook's recognition test, two lines at the top saying how to tell this problem from the one that looks like it. Every objection of the form "it's not always that" is a recognition test that has not been written yet. Write it, and the objection becomes a step.

Keep the runbook where the front line looks when stuck, visible to the desk only. In most knowledge bases that is an article marked as visible to agents only, as it is in QuerySolv. The point of putting it there rather than in a folder is that the technician who searches for the words in the ticket finds it without knowing it exists. A runbook the front line has to be told about is a runbook the front line will forget about by the third week. One they find by searching the error message is one they will use on the day it matters.

The Permission to Act

The permission has two halves, and the technical half is the smaller. The technical half is the right in the system to do the one thing the runbook does. That could be to clear a session, add a user to a mailbox, delete one file in one folder, or reset one kind of password. Grant it to a role the front line holds, never by sharing the specialist's account, and grant the narrowest right that covers the runbook's steps. If the console that clears a session also allows deleting policies, the permission is too wide for the runbook. In that case, the answer is either a narrower role in the console, or a script that does only the one thing. The next section is about that. The thinking on granting the least a job needs, under the pressure of someone waiting, is in Least Privilege Under Pressure. That thinking applies to the desk's own permissions as much as to anyone's.

The social half is the sentence, said out loud by the specialist and the desk lead to the front line, "you may do this without asking". It sounds too small to matter and it is the half that most often is missing. A front line that has the right in the system and has not been told it may use it will keep asking. That is because asking is safe and acting is a risk they have not been told they are allowed to take. Grace had to say to Theo, in front of the team, "clear it yourself, don't message me first". She had to say it twice, because the first time Theo did not believe her. The permission is granted when the front line stops asking. Until then, the console right is scenery.

Record the permission as a change, lightly. Who was given which right, for which runbook, on which date, approved by whom: four lines in the change log or on the runbook's own page. When the runbook is retired, the permission is retired with it. The four lines are how anyone will know it existed. A desk that cannot list the rights its front line holds is a desk that will fail its next access review for reasons that began as good intentions.

The Scripted Fix: Permission With Guardrails

Where the permission the runbook needs is too wide to grant safely, wrap the fix in a script that does only that one thing and give the front line the script instead of the right. A script that clears the session for a named user, after checking that it has been idle for an hour, is a narrower permission than the console that could clear anyone's. The script carries the limit inside it. It refuses the cases the runbook says to escalate, logs what it did and when, and it cannot be talked into doing anything else by a user on the phone. How to turn a manual fix into a script without losing the safety that was in the manual steps, including the checks that must survive the translation, is in Turning a Fix Into a Script Safely. The move from script to a button the front line can press is in the same series.

The script is also how a fix reaches a front line that should not hold the underlying right at all. Grace was never going to give the front line the policy system's admin console. She was right not to, because the console does a hundred things and the runbook needed one. A script that does the one thing, runs under a service account the front line never sees, and writes a line to a log for every run gave Theo the ability without the exposure. The objection "I'm not giving them admin" is almost always correct about the admin and wrong about the ability. The script is the way to agree with the first half and still make the move.

Keep the script's limits identical to the runbook's. If the runbook says "escalate when the user has more than three sessions", the script checks the count and refuses above three. If the runbook says "never clear a session belonging to the batch account", the script refuses that name. A script whose guardrails differ from the runbook's produces a front line that trusts the wrong document. That document will be the more permissive one. Write the limit once, on the runbook, and make the script enforce exactly that. The script is permission with the limit built in. It is not permission to stop reading.

The Specialist's Reluctance and What It Is Really About

Every specialist resists the first handover, and the resistance is information, not obstruction. Grace's five objections are the five that every desk lead hears, in roughly that order. Each one points at a specific piece of missing work. Hear them as a list of tasks and the conversation stops being an argument. Treat them as stubbornness and you will win the meeting and lose the move. That is because the specialist who was overruled will be the specialist who says "I told you" when the first wrong session is cleared, and will have been right.

The last objection is the one that matters and the one least often said aloud. A specialist who has been the catalogue person, or the policy system person, for six years has an identity built partly from being needed for it. Shift-left asks them to dismantle that for the good of a queue. The honest response is not reassurance but a destination. Here is the project that has waited a year for your hours. Here is the prevention work that only you can do. Here is the hard case the front line will still send you, now without thirty easy ones in front of it. Say what the hours are for before you take them. A specialist who can see where their time is going will hand over the easy work and feel promoted. One who cannot will hand it over and feel replaced. They will find reasons for the handover to go badly. (They will not do this on purpose. It will simply turn out that the runbook needed one more thing.)

"It's faster if I do it" deserves a straight answer too, because it is true. Grace's two minutes beat Theo's eight every time, per ticket. Per month, thirty tickets at Grace's two minutes plus the ten minutes of interruption around each, plus the front line's fifteen minutes before the handoff, is around thirteen hours of people time. Thirty tickets at Theo's eight is four. The nine hours between those numbers are the argument, and six of them are Grace's. The requester's wait falls from a couple of hours to a few minutes besides. Show the specialist the month, not the ticket. The ticket is on their side. The month is not.

The Safety Limits, Written Down

The limit is the shortest part of the handover and the part that makes the other two safe to grant. It has three kinds of line. When not to start: the signs that this is not the problem the runbook fixes, which is the recognition test. When to stop: the point at which the procedure has not worked and the front line hands the ticket up rather than improvising. It is usually a time ("after fifteen minutes") and a condition ("if the session will not clear twice"). What never: the actions that are outside the front line's permission under any circumstances, named plainly. Examples are the batch account, the production database, or anything belonging to a named list of systems. Where the tier boundaries for the whole desk are drawn, and how escalation criteria are written so they are the same for everyone, is in Escalation Boundaries. The limit on a runbook is that boundary applied to one ticket type.

Write the limit on the runbook's own page, not in a policy document elsewhere. The technician reading the runbook at step four, with the user on the phone, will read the limit if it is the next line. They will not read it if it is in a document called "Front Line Operating Boundaries" that was circulated in a quarterly meeting. The limit belongs with the steps because it is a step. "If the session count is above three, stop here and escalate" is an instruction, and it lives where the instructions live.

Make the stop an action, with a visible mark on the ticket. "Escalate" should mean: write what you did and what each check showed, set the escalation marker, assign to the role, tell the requester the ticket has gone up and roughly when they will hear. Where the tool has an escalation flag that is separate from priority, as QuerySolv does, the runbook says to set it. That way, the handed-up ticket is visible on the queue as a handed-up ticket and not as an ordinary one that happens to belong to Grace. The point of a written stop is that stopping becomes something the front line did, and can be seen to have done, rather than something that happened to them.

The Rehearsal and the First Month

Before the first real ticket, the front line runs the runbook once with the specialist watching and saying nothing. On a test account if there is one, on the specialist's own stuck session if there is not. The point is to find the step that was obvious to Grace and is missing from the page. That step is found by Theo stopping and the room going quiet. Grace's first rehearsal at Stonebridge found two: the console's search needed the user's identifier rather than their name, and the "idle for an hour" test was in a column the runbook had not named. Twenty minutes of silence saved a quarter of wrong sessions. The method of watching someone do the work without taking over, which is harder than it sounds, is the subject of Shadowing That Actually Teaches.

For the first month the specialist stays on call for the type, and reviews every ticket of the type the front line resolved. Not to check up on the front line; to read the runbook through their notes and find where it bent. The ticket that took Theo twenty minutes instead of eight is a step that needs a sentence. The ticket Theo escalated that Grace would have fixed is a limit set too tight. The ticket Theo fixed that Grace would have escalated is a limit set too loose, and the most important one to catch. It takes fifteen minutes a day, for a month. The runbook that comes out the other end is one that the next front-line technician can use without Grace at all. That was the destination. The month is the price of the move. Desks that skip it pay in a different currency and later.

Watch three things in that month, by hand, for that type only: how many were resolved on the front line without a handoff; how many were escalated and why; and how many came back. A type that is being resolved on the front line, escalated for the reasons the limit names, and not reopening has moved. A type with rising reopens has a runbook with a gap in it. The gap is in the notes of the reopened tickets. The full measuring method, across types and over quarters, is the last article in this series; the first month is three tallies on a sheet of paper.

A Short War Story: The Handover by E-mail at Redbrook Engineering

Redbrook Engineering's one specialist for the design licence server, Priya, was due three weeks' leave. The evening before she left she e-mailed the desk a document called "Licence server fixes" with eleven procedures in it, carefully written, and a note saying "you should be fine with these". Within two days the front line had hit the first stuck licence, opened the document, and reached the step that said "release the seat from the licence console". They discovered that nobody but Priya had an account on the licence console. The account request needed Priya's approval. Nobody had been told they were allowed to release seats in any case. Twenty-three licence tickets waited the full three weeks. Three design engineers worked from a borrowed workstation in turn. The cost, counted afterwards, was somewhere between sixty and ninety engineering hours lost to waiting, against about two hours it would have taken to grant a role and say the sentence. Priya came back to a queue and a reputation for having written a document nobody could use, which was unfair to the document. A runbook without the permission to act on it is a description of someone else's job.

The Handover-to-Front-Line Checklist

The checklist below is one page per ticket type, in the three sections the article has been about, with a fourth for the month after. Run it with the specialist and a front-line technician in the room together, which takes about an hour. Keep the completed copy on the runbook's page so that anyone asking "why does the front line have this right?" finds the answer where the right is used. The type has moved when every box is ticked and the month's three tallies look like the last section says they should.

HANDOVER TO THE FRONT LINE — ONE TICKET TYPE, ONE PAGE
Ticket type: _________________________________   Tickets per month: ____
Specialist handing over: _______________   Front-line technician writing: _______________
Handover started: ____________   Target date for front line to own it: ____________

A. THE RUNBOOK
   [ ] Written from a real ticket, specialist dictating, front-line technician writing
   [ ] Recognition test at the top: how this problem looks, and how to tell it from the one like it
   [ ] Every action followed by its check and the expected result
   [ ] Timing stated where a step takes time; "do not repeat before ____ minutes"
   [ ] Rollback stated for every step that changes something
   [ ] Stored where the front line searches, visible to the desk only
   [ ] Titled by the symptom, in the words a ticket would use
   [ ] Last-run line present, with a ticket number

B. THE PERMISSION TO ACT
   [ ] Narrowest right that covers the runbook's steps, identified: ______________________
   [ ] Granted to a front-line role, not an individual, never by sharing an account
   [ ] Where the right is too wide, a script or button does the one thing instead: ____________
   [ ] Script's refusals match the runbook's limits exactly
   [ ] Every use is logged (by the system, the script, or the ticket note)
   [ ] Recorded as a change: who, which right, which runbook, which date, approved by whom
   [ ] Said aloud to the front line by the specialist and the desk lead: "do this without asking"

C. THE LIMIT, ON THE RUNBOOK'S PAGE
   [ ] When NOT to start: ____________________________________________________
   [ ] When to STOP: after ____ minutes, or if ______________________________
   [ ] What NEVER: ___________________________________________________________
   [ ] What "escalate" means here: note what was done and seen, set the escalation marker,
       assign to the role: ______________, tell the requester it has gone up
   [ ] Specialist has read the limit and agrees it is where they would stop

D. THE REHEARSAL AND THE FIRST MONTH
   [ ] Rehearsed once with the specialist watching in silence; gaps found: ____
   [ ] Specialist on call for this type until: ____________
   [ ] Specialist reviews every resolved ticket of this type for one month
   [ ] Tallies kept for the month: resolved on front line ____  escalated ____  reopened ____
   [ ] Runbook corrected after the month; last-run line updated
   [ ] Freed hours have a named use: ______________________________________

Stonebridge's checklist for the stuck-session ticket took Nadia, Grace and Theo an hour and ten minutes. Most of it was on section C, where Grace discovered she had four different limits in her head and had been applying them inconsistently for years. The front line owned the type five weeks later. Grace used the first of her freed hours to write the recognition test for the licence pool, which she described as "the thing I've been meaning to do since I started". She used the second to look at the next line on the map.

Frequently Asked Questions