What Shift-Left Means for a Help Desk, Drawn as a Staircase

Tuesday, 10:40, at Meridian Parts. Ticket 5102 arrives from Carla in sales: "The parts catalogue won't open. It says licence check failed. I have a customer on the phone." Josh, on the front line, reads it and recognises it. He does what he has done with every ticket like it since he joined. He assigns it to Owen, because the catalogue is "an Owen thing". Owen is the desk's one specialist for the catalogue system and he is in a supplier call until two. At 14:20 he opens the ticket, connects to Carla's machine, deletes a stale lock file in her profile, and the catalogue opens. The work took four minutes. Carla waited three hours and forty minutes, and the customer did not. The ticket, when Dana who runs the desk reads it that evening, is marked resolved within target, which is true.

Dana does what nobody had done before, which is to search for every ticket mentioning "licence check failed" in the last quarter. There are fourteen. Every one was assigned to Owen; every one was resolved by deleting the same file; every one waited for a gap in his diary. Shift-left is the strategy of moving where a type of ticket gets resolved. It moves from the specialist to the second line, then from the second line to the front line. It moves from the front line to the user helping themselves. Where the cause can be removed, it moves to nowhere at all because the ticket stops arriving. The name comes from the picture people draw of a support desk, with the user on the left and the specialists on the right. The work moves left, towards the user. This article is part of our Shift-Left Strategy series, which is about making that move deliberately rather than hoping it happens.

It covers the staircase and its five steps, then why the strategy is called left. Next comes the cost in hours at each step, as a worked example from one fictional desk. The article covers what moves and what should not, then how to find where each ticket type resolves today. It explains why the move is one step at a time. It finishes with the worked map at Meridian Parts, a short war story, and the shift-left map to copy, in that order.

The Staircase and Its Five Steps

A tier is a group of people on a desk defined by how hard a ticket they are expected to finish. And most desks have between two and four of them whether or not anyone has drawn the chart. The front line is the first group to touch a ticket, the people who answer the phone and read the queue. The second line is the group the front line hands a ticket to when it cannot finish it. A specialist is the person who owns one system and is called when nobody else can fix it. On a small desk that is usually the senior administrator, who also has eleven other jobs. What each tier is for, and how the boundaries between them are drawn, is the subject of What Tiers Are For and its series. This article assumes you have tiers, however informal, and is about moving work between them.

Below the front line sit two more steps that are not tiers at all, because nobody on the desk works them. Self-service is the user resolving the problem themselves, usually from a knowledge base article they found before raising a ticket. Prevented is the problem never happening, because the cause was removed. Put the five together, specialist at the top and prevented at the bottom. You have a staircase: five places a given ticket type can be resolved. Each one is cheaper in hours and faster for the requester than the one above it. Every ticket type on your desk sits on one of those steps today. Shift-left is moving it down.

The staircase exists on a desk of two as surely as on a desk of twenty. If you run a desk with one junior and one senior, the junior is the front line. The senior is the second line and the specialist at once. The handoff is the sentence "can you look at this one?" The hours and the waiting are the same; only the chart is missing. A desk that has gone tierless and swarms every ticket, the model in Tierless Swarming, still has a staircase, because the person who ends up fixing the catalogue is still Owen. The steps are about who can finish the work, not about who is listed on which team.

Why It Is Called Left

Draw a support desk the way it is usually drawn. Put the user on the far left, then self-service, then the front line, then the second line, then the specialists on the far right. Time, cost and distance from the user all increase as you go right. A ticket that travels right is escalating; a resolution that travels left is getting closer to the person who had the problem. "Shift left" means moving the point of resolution leftwards on that picture. The term is used in software testing and in security for the same idea of doing a thing earlier and closer to its origin. On a help desk it means nothing more exotic than "the front line fixes this now, and next year the user will".

The staircase in this article is the same picture tilted, so that the cost shows as height. I prefer it because a staircase makes the one-step-at-a-time rule visible, and because height is what the specialist's hours feel like from the front line. Nothing about the idea depends on the drawing. Nothing about it depends on a framework either; shift-left is a strategy you can describe in a sentence to a manager, and a sentence is the right length. (The conference-slide version has everything on self-service by the third quarter. The slide has never met a front line.)

The Cost in Hours at Each Step

Every number from here on is a worked example from Meridian Parts, a fictional desk of four, and your own figures will differ. The point is the shape, and the shape is that each step down divides the cost by something between two and three. Two kinds of cost matter. People time is every minute anyone on the desk spends on the ticket. It includes reading it, trying something, writing the note, handing it over, and picking it up. It also includes the specialist's lost concentration when the interruption lands. Wait time is how long the requester goes without a fix. The first is the desk's cost and the second is the organisation's, and shift-left reduces both. That is why it is one of the few strategies a desk and its customers want in equal measure.

Take the catalogue licence ticket at the top of the staircase, where it lives today. Josh spends about fifteen minutes on it: reading, a restart that does not help, a note, the handoff. On a bad day it goes to the second line first, where someone spends half an hour trying the usual things before admitting it is an Owen thing. Owen spends four minutes on the fix and another twenty on everything round it. That includes opening the ticket, reading two sets of notes, connecting, writing his own note, and replying to Carla. He also has to get back into the supplier contract he was reading. Dana counted it at roughly an hour and a half of people time when the second line was involved. It was about forty minutes when it went straight to Owen, with the requester waiting most of a day either way. The diary is the most expensive queue in the building, and it appears in no report.

Now walk the same ticket down. On the second-line step, there is a runbook saying which file to delete. The ticket costs Josh's fifteen minutes and a second-line technician's twenty, with a handoff between them. Call it fifty minutes, and the requester waits half a day for the second-line queue to reach it. On the front-line step, with the same runbook and permission to use it, Josh deletes the file himself. It takes about twenty minutes including the note, and Carla is working again inside the hour. On the self-service step, there is an article on the portal called "The parts catalogue says licence check failed". It tells Carla to close the catalogue, delete one file from a folder the article names, and open it again. The desk spends nothing per ticket and about an hour a quarter checking the article is still right. On the prevented step, Owen adds one line to the sign-in script that clears the stale file before the catalogue starts. The ticket type disappears, for a one-off cost of about three hours including the test.

The picture below draws the five steps for that one ticket type, with Meridian's hours on each. Read it from right to left, which is the direction the resolution travels. The hours per ticket fall from about an hour and a half to about nothing. The requester's wait falls from a day to a moment. Neither of those happens by itself. Each step down is bought with a specific piece of work, which is the subject of the next two articles in this series. The picture names that work in italics under each step.

Multiply by volume to see why this is a strategy and not a tidy-up. Meridian gets about five catalogue licence tickets a month. At the specialist step that is somewhere between three and a half and seven and a half hours a month of people time. It depends on how often the second line gets involved first. At the front-line step it is under two hours. The difference is between two and six hours a month freed, from one ticket type, most of it Owen's. Owen's hours are the ones the desk has least of. The arithmetic for turning hours into something a manager can use, including the two figures for an hour that must never be mixed, is in What ROI Means for a Help Desk. This series borrows it and does not redo it.

What Moves and What Should Not

A ticket type is a candidate to move down a step when the same symptom leads to the same fix often enough to be worth writing down. The fix must also be recognisable from what the requester says, and doing the fix wrongly must do no lasting harm. The catalogue licence ticket passes all three: the error message is distinctive, the fix is one file, and deleting that file when it was not the problem costs the user a restart. Consider mapped drives that vanish after a profile reset, printer queues missing on a new machine, and a shared mailbox that needs adding. Another example is the quoting report that fails to export when the temp folder is full. These are the ordinary shift-left candidates on an ordinary desk. Most desks have fifteen or twenty of them hiding at the specialist step for no better reason than habit.

Some types should not move, and knowing which is as much a part of the strategy as moving the rest. Anything where the fix is a decision rather than a procedure stays where the judgement is. That includes whether to grant an access request outside the normal pattern or whether an unusual sign-in is an attack. It includes whether a change to a shared server is safe tonight. Anything where a wrong fix destroys data stays with the specialist until there is a reversible version of it. Anything touching the security of accounts moves only as far as the verification standard allows, and the standard itself does not move at all. The fifth article in this series, The Limits of Shift-Left, is about those boundaries. Here it is enough to say that the staircase is for ticket types, not for every ticket. The ordinary case of a type moves down. The hard case of the same type still goes up, and the runbook says where the line is.

Tickets climb on their own. Left alone, a ticket type drifts up the staircase, never down, because up is where the certainty is. The front line hands it to someone who knows. The someone who knows gets better at it every time, and the front line gets no better at all. Shift-left is the deliberate counter-current, and it only runs while someone is pushing. The month you stop, the catalogue ticket goes back to being an Owen thing.

Finding Where Each Type Resolves Today

The first job is a list of your ticket types with the step each one resolves on today. And it is built from the tickets, not from the organisation chart. Take a quarter of resolved tickets and group them by what the fix was; the categories in your tool are a starting point. But the fix is the honest grouping, because a category called "Catalogue" holds tickets that resolve on three different steps. For each group, record who wrote the resolving note, how many times the ticket changed owner on the way, and how long the requester waited. The person whose name is on the resolving note tells you the step. The owner changes tell you how many steps it climbed to get there.

Where the tool keeps a history of ownership on every ticket, this is a filter rather than an interview. If you run QuerySolv, the event history on each ticket already holds every claim and handoff. In that case, "which types does Owen end up with" is an afternoon with a filter and a spreadsheet. In a tool without such a history, or on a desk that works from a shared mailbox, ask the specialists directly. Ask: "what do you fix that you think someone else could?" Specialists know. They have usually been quietly annoyed about it for a year.

Weight the list by volume and by the step. A type that arrives twice a month and sits with the specialist is a nuisance. A type that arrives twenty times a month and sits with the second line is a strategy. Multiply the monthly count by the difference in hours between the step it is on and the step it could reach. Sort by the result. The top five on that list are your first year. I once moved a ticket type to the front line by announcing it in a meeting. The announcement resolved zero tickets, because the front line had been given a destination and no map. The map is the list, with the work each move needs written beside it.

One Step at a Time

Move each type one step, let it settle, then move it again, because each step down is built from the step above. The second line can take a type from the specialist once a runbook exists. The front line can take it from the second line once the runbook has been run by people who did not write it. The places where it was wrong must also have been fixed. The user can take it from the front line once the runbook has been turned into a user guide. That is a different document for a different reader. The method for deriving one from the other is in Writing the User Guide From the Runbook. Each step tests the fix in front of a less expert audience. A fix that goes straight from the specialist's head to a public article has been tested in front of nobody.

The settling matters as much as the move. After a type moves down, the escalations of that type that still happen are the information. Each one is a case the runbook did not cover, a step that did not work, or a limit that was set in the wrong place. Three months of those, fed back to whoever wrote the runbook, make the runbook good enough for the next step down. Skip the settling and the next step inherits every gap, in front of a reader who cannot tell a gap from a mistake of their own. The feedback path, and the work of keeping it open, is the subject of Enablement: The Work Behind the Shift.

The prevented step is the exception that proves the rule, because it is sometimes reachable in one jump and sometimes not reachable at all. A ticket type caused by a known defect with a cheap fix can go straight from the specialist to prevented. Meridian's catalogue ticket eventually did, with the sign-in script. A ticket type caused by people needing a thing they are entitled to, such as a new starter's accounts, can never be prevented, only made cheap. It walks down the stairs like everything else. Deciding which is which, and finding the hour to do the preventing, belongs to the series on moving from reactive to proactive support, which this one links rather than repeats.

The Worked Map at Meridian Parts

Dana's map, after an afternoon with the quarter's tickets and a conversation with Owen, had six lines. The table below is those six, with the step each type was on and the step it could reach in a year. It shows what the move would need and the hours a month the move would free, as a range, from Meridian's own counts. The ranges are wide on purpose. A desk that writes a point estimate on a map like this is promising a number it has not yet earned.

Six lines, and five of them move. The total at the bottom of Dana's map was between thirteen and twenty-five hours a month. That is between a day and a half and three days of desk time, most of it Owen's and the second line's. It came from ticket types nobody had thought of as a problem because each one was small. That is the ordinary shape of a first map: no single line is dramatic, and the sum is a part-time technician. The sixth line is on the map on purpose. A map that shows only what moves teaches the front line that everything should.

A Short War Story: The Quiet Leap at Tollgate Foods

Tollgate Foods' desk lead, Marta, had read about shift-left and was in a hurry. The quarterly report showed the remote-access certificate renewal as the top specialist ticket type. So she had the specialist, Dev, dictate the fix into a knowledge base article visible to everyone. She published it the same week with a link from the error message. The fix was "delete the expired certificate from your personal store and re-enrol". Dev had left out the two sentences about how to tell the expired one from the three others that looked the same. He had never needed them. In the next month forty-one users deleted the wrong certificate, nineteen of them twice. The desk spent somewhere around thirty hours re-enrolling people who had been working fine before they read the article. Marta pulled the article and had the front line run Dev's procedure as a runbook for a quarter. During that quarter, the missing two sentences were found by the third technician to try it. She republished the user guide from that runbook; it has been quiet since. The staircase has steps for a reason, and the reason is that the front line finds the missing sentences before the users do.

The Shift-Left Map

The map below is Dana's, blanked. There is one line per ticket type, filled in from a quarter of resolved tickets and one conversation with each specialist. The rules at the bottom are the ones that stop the map turning into a wish list. Fill it in once, sort by the last column, and the top five lines are the plan. Bring it back out every quarter, move the lines that have moved, and add the types that have appeared. Ticket types breed and the map is the only thing that notices.

THE SHIFT-LEFT MAP — ONE PAGE
Desk: ______________________   Prepared by: ______________   Period counted: ____________

STEPS (write one in each "today" and "could" box)
  Specialist / Second line / Front line / Self-service / Prevented / Stays

TICKET TYPES (one line each, from resolved tickets grouped by the fix)
  Type: ____________________________  Per month: ____
    Resolves today at: ______________   Who resolves it: ______________
    Could resolve at: _______________   Within: ____ months
    What the move needs (runbook / permission / user guide / fix): __________________
    Hours per ticket today: ____   Hours per ticket after: ____   Freed per month: ____ to ____

  Type: ____________________________  Per month: ____
    Resolves today at: ______________   Who resolves it: ______________
    Could resolve at: _______________   Within: ____ months
    What the move needs: ______________________________________________________________
    Hours per ticket today: ____   Hours per ticket after: ____   Freed per month: ____ to ____

  (continue; stop at the twenty largest types)

TYPES THAT STAY, AND WHY
  ____________________________  Reason: security / data / judgement / change
  ____________________________  Reason: security / data / judgement / change

RULES FOR THIS MAP
  [ ] Every type was counted from tickets, not from the category list
  [ ] "Resolves today" is where the resolving note was written, not where the ticket was assigned
  [ ] Hours are ranges from this desk's own tickets; no outside figure is on this page
  [ ] Each move is one step; a two-step move is written as two lines with two dates
  [ ] Every "could" has a "what the move needs" beside it
  [ ] At least one type is marked "stays", with its reason
  [ ] The map is dated and will be redone next quarter

TOTAL HOURS FREED PER MONTH IF EVERY MOVE LANDS: ____ to ____

Dana's map went on the wall by the queue screen, which was the first time Owen had seen his own hours written down as a column. He asked for the catalogue line to be moved first, on the grounds that he had been deleting that file for six years and would like to stop. The front line took it in a fortnight, with a runbook and a conversation about the lock file that took longer than the runbook. Carla's next licence ticket was resolved by Josh in eleven minutes, and the note at the bottom says so.

Frequently Asked Questions