Improving Resolution Time Without Rushing Anyone

Monday, 10:20, at Larkfield District Council. Amara runs a desk of four for about six hundred staff. The chief executive's office has asked, in a one-line e-mail, whether the desk could be "a bit faster". The figures are honest: a median of fourteen business hours, nine in ten tickets inside sixty, reopens steady at three in a hundred, satisfaction unchanged for a year. Amara knows the quick ways to make fourteen into nine and has decided not to use any of them. Instead she takes the twenty slowest resolved tickets from the last quarter and asks each technician how long they actually worked on theirs. The answers are between one and three hours. The elapsed times are between thirty and eighty. She writes the two columns side by side and looks at the gap. The desk was not slow at fixing things. It was slow at being allowed to start.

Improving resolution time means shortening the elapsed time between a request arriving and a working fix reaching the requester, without shortening the work. The distinction is the whole article, because the work is a small share of the elapsed time on almost every slow ticket. The rest is waiting: for the ticket to be picked up, for the requester to answer, for an approval, for a part. Or it is waiting for someone with the right permission, or for a second-line team that has not replied. The waiting can be removed without anyone typing faster, and removing it is where nearly all the improvement is. This article is part of our Time to Resolution series. This is the last article, because the five before it produce the list of causes and this one is what to do with the list.

It covers where the time actually goes, with a table, then removing the waiting first, in its four forms. Next come putting knowledge within the technician's reach, and permissions, which are the quietest delay on most desks. We cover escalation paths that work. Then comes the discipline of one change a month with the measurement after, with Larkfield's three months as the worked example. We finish with what not to change, a short war story, and the improvement plan to copy. Every number is from a fictional desk and is an example, not a target.

Where the Time Actually Goes

The elapsed time on a ticket divides into a handful of stretches, and only one of them is a technician working. There is the time before anyone claims the ticket, and the time a technician spends on it. There is the time waiting on the requester for information, on an approval, or on a supplier or another team. There is the time nobody was waiting for anything and the ticket simply sat. And, on a reopened ticket, there is the second round of all of these. The tail review in Outlier Analysis: The Ten Slowest Tickets finds the longest stretch on each slow ticket. This section adds them up across the quarter so that the improvement starts in the right place.

Larkfield's twenty slowest tickets from the quarter, read this way, are in the table below as ranges, because the point is the shape rather than the decimals. The working time was one to three hours per ticket. Everything else was waiting of some kind, and the largest single stretch on most tickets was waiting on a requester or an approver. The right-hand column is who could shorten each stretch. And it is the column that decides where to begin, because a desk can only improve the stretches it has some say over. It has more say than it thinks.

Read the second column against the first row of fixes and the lesson is already there. The technician's one to three hours is the only stretch that rushing could shorten, and it is the smallest. Everything above and below it in the table can be shortened by removing a wait, and removing a wait does not make anyone's work worse. That is why this article's title is possible. The quick ways to a lower number, catalogued in Speed Versus Quality, all attack the one-to-three-hour row. The honest ways attack the rest, and the rest is bigger. (The spreadsheet, asked to improve the desk, would shorten the technician. Do not consult the spreadsheet.)

Remove the Waiting First

Start with the wait before anyone claims the ticket, because it is entirely the desk's and the fix is a habit. A ticket in the unassigned view is waiting for the desk itself. And the longer the view goes unread the longer every ticket in it waits before a single minute of work is done on it. The habit is a fixed rhythm. The unassigned view is read and claimed from at set times, at least at the start of the day and after lunch. A named person on a rota does this rather than everyone in general. That is what What a Queue Is For describes as the standing view's purpose. Where ownership is claim-based, as it is in QuerySolv, the unassigned view is the honest list of what is waiting for the desk rather than for a person. With claim-based ownership, a desk that keeps that list short has removed the first wait from every ticket at once.

The wait on the requester is next, and it has three fixes that are mostly about the first contact. Ask for everything the ticket will need in the first reply, not in instalments, which is the discipline of Gathering the Right Information Up Front. A ticket that asks a second question has bought itself a second wait. Chase on a fixed cadence, so that a ticket waiting on a requester is never waiting without a date. Close with a courteous note after a stated number of silent chases rather than holding the ticket open indefinitely, as User Confirmation Without Chasing Forever sets out. And check that a requester's reply to a waiting ticket actually changes its status in your tool. A reply that lands silently under "waiting on requester" is the most expensive wait of all: it is finished and nobody knows.

The wait on an approval is the organisation's, and the desk's part is to make it visible and dated. Every approval request on a ticket names the approver, names a deputy, and states the date by which the answer is needed. The request is sent to the approver and copied to the deputy on day one rather than to the deputy on day ten. Approvals that recur, for standard software, standard access, standard equipment, are approved once as a standing list rather than each time. That is the single most effective change a desk can propose outside itself and the one described from the slow end in the tail review article. At Larkfield, a standing list of fourteen applications removed approvals from the tail entirely within a quarter.

The wait on a supplier or another team is partly outside the desk. And the desk's share is the gaps around it: between the order and the chase, between the delivery and the ticket moving, between the handoff and the other team noticing. Record the supplier's own promised date on the ticket and chase on the day after it. Put the ticket number on the order so the post room can match the box to the ticket. And for the items that most often go on back order, hold a small loan pool so that the requester is working while the supplier is finding the part. The agreement with another internal team, that an escalated or handed-off ticket gets a reply within a stated time, is the subject of the escalation section below. None of these makes the supplier faster. All of them make the requester wait less.

Knowledge at Hand

The second share of a slow ticket, after the waiting, is the technician finding out: searching for the last time this happened, asking a colleague, trying three things before the fourth works. It is honest work and it is also repeated work, because most of the tickets a desk sees it has seen before. The time spent rediscovering the fix is time the requester waits. The fix is a runbook within reach of the ticket. This is a short internal article that says what the symptom is, what the cause usually is, and the steps. It is written the way Writing the Runbook describes. It is searched for before solving, every time, until searching first is a habit.

Within reach means beside the ticket, not in a folder. A knowledge base that technicians have to leave the ticketing tool to open will be opened on the days it is remembered. And a runbook that lives in one person's notes is a runbook that goes on leave. The knowledge base may sit inside the help desk and hold articles visible to agents only or to everyone, as it does in QuerySolv and most tools. In that case, the runbook can be looked up from the ticket. The user-facing version of the same fix can be sent to the requester in the same minute. Where the knowledge base does not sit inside the help desk and offer those visibility options, the first improvement is to put the twenty most-used runbooks wherever the technicians already are. The known-error list, which records faults with a workaround while the permanent fix waits, is the runbook's cousin for the hard tickets and belongs to the problem management series.

Measure the effect on the ticket type the runbook covers, not on the desk. Twenty tickets of a type before the runbook and twenty after, median of each, is the comparison. It is small, honest and specific. The hours saved across the desk are a separate sum with its own article, The Time Saved by Technicians. At Larkfield, the median for printer tickets fell from three hours to one in the month after two runbooks were written. The desk-wide median did not visibly move, because printer tickets were a twelfth of the volume. Both facts were reported. The first was the finding; the second was why the desk-wide number is a poor place to look for the effect of anything.

Permissions

The quietest delay on most desks is the technician who knows exactly what to do and is not allowed to do it. Examples include a password reset for an account in a protected group, a change to a distribution list, and a licence seat moved between users. There is delegated access to a shared mailbox, local administrator rights on a loan laptop, and a firewall rule for a new printer. Each is a two-minute job for someone with the right permission and a day's wait for someone without. That is because the someone with it is in a meeting. Nobody logs this as waiting. It appears in the history as "asked Sam", followed by a gap, followed by Sam. Larkfield's twenty slowest had this stretch on seven of them.

The fix starts with a list: the ten actions the desk does most often, and against each, who can do it today. Where the first-line technicians cannot do an action that they request daily, there is a question for whoever owns the directory and the systems. Is a delegated right, scoped to that action and logged, a smaller risk than a day's delay on every ticket that needs it? Often it is, and the delegation is a line in the directory's configuration. Sometimes it is not, and the action stays escalated with a stated turnaround instead. Least privilege is the principle either way: the right to do the common thing, not blanket administrator rights, and an audit trail on every use. The decision belongs to the owner of the identity system, not to the desk. And the desk's part is to bring the list and the ticket numbers.

At Larkfield, three of the ten most common actions needed a second-line person. Two of them were delegated to the desk with logging in the month that followed. The third, which touched the finance system, stayed escalated with a same-day turnaround agreed. The median fell by four hours in the month after, which was the largest single move the desk saw in the year. It came from a change that involved no training, no new tool and no one working faster. A technician who can do the job is faster than a technician who can describe it to someone else. (This is less widely understood than it should be.)

Escalation Paths That Work

An escalated ticket is a ticket that the desk has handed to someone with more skill or more authority. And the slow kind is the one that was handed over and disappeared. The second-line team received it, had no expectation about when to reply, worked it when they got to it, and did not tell the desk. The desk meanwhile told the requester that it was "with the specialists". Two weeks later the requester asked which specialists. The ways a handoff dumps rather than transfers, and the fix, are the subject of The Handoff That Does Not Dump, along with the question of who owns the ticket afterwards. This section is only about the time.

The fix is an agreement, not a redesign. The desk and each team it escalates to agree a turnaround for an escalated ticket. That means a first reply within a stated number of business hours and an update at a stated cadence. The agreement is written on one page and reviewed when it is missed. This is not a service-level target, which is a promise to requesters by priority and belongs to the SLA design series. It is an internal understanding between two teams about how long a ticket may sit between them. The honest test of it is the tail review, where an escalated ticket with a long gap after the handoff is a missed agreement with a ticket number on it. The desk keeps the ticket visible on its own waiting view until it comes back, and the requester is told the agreed turnaround rather than "soon".

Make escalation easy to see and separate from urgency. Some tools keep an escalation flag separate from priority. That lets a ticket be marked as needing a specialist without being promoted to urgent. Where yours does, use it, because a desk that raises the priority to get attention has broken its priority cut. Where yours does not, a status or a note serves. The point is that the second-line team has one list of what the desk is waiting on them for. And the desk has the same list, and both can see how old the oldest thing on it is. A handoff that nobody can see is a handoff that nobody is late on.

One Change a Month, and the Measurement After

Make one change at a time, and measure a full month later, before making the next. The temptation, with a table full of fixes, is to do five at once. The result is a desk that improved and does not know why. That means it does not know which change to keep paying for, which to extend to another category, and which did nothing and could be dropped. One change a month gives each its own month and its own before-and-after. And a year of it is twelve measured improvements rather than one unmeasured reorganisation. On a small desk, where a month is thirty tickets, the measurement period is a quarter and the pace is one change a quarter. That is still four a year, each known to work.

The measurement is the pair, never the resolution time alone. Before the change: median, 90th percentile, reopen rate, satisfaction, and the share of elapsed time that was waiting, from the tail tally. After the change, the same five, and a decision written down: keep, extend, or undo. The pairing check from Speed Versus Quality is the guard here, because a change that shortens the median and raises the reopen rate is not an improvement whatever it feels like. The most dangerous changes are the ones that feel most like improvements. Larkfield's first three months under the plan are below, and they are the worked example this article has been building toward: three changes, three measurements, and a decision on each.

Read the table for the shape, not the figures. The first two changes moved the 90th percentile and left the median almost alone, because they removed the long waits that lived in the tail. The third moved the median, because it removed a short wait that sat on a large share of ordinary tickets. Reopens did not move in any month, which is the sentence that makes the other columns believable. Satisfaction, read a month behind, held steady and then rose slightly in the quarter after, mostly in comments about "not having to chase". None of the three changes involved anyone working faster. The chief executive's office, which had asked for "a bit faster", received a one-page note with this table on it and asked for nothing further.

What Not to Change

Do not shorten the confirmation window to make the number fall, because resolution time is measured to resolved rather than closed, as What Time to Resolution Actually Measures insists. A desk that measures to closed and shortens the window has improved a number about a timer. Do not add waiting statuses so that tickets can be parked, and do not subtract waiting from the headline figure quietly. The waiting is the finding, and hiding it removes the one column the improvement plan is built from. Do not set per-person targets on resolution time, for the reasons the previous article in this series gives at length. The plan is a desk-level loop and the per-person figures in it are for coaching, on a sample of at least thirty, in private.

Do not hire into the waiting. A desk whose slow tickets are waiting on requesters, approvers and suppliers will, if given a fifth technician, have five people whose tickets wait on requesters, approvers and suppliers. In that case, the median will barely move while the cost rises. Hiring is the right answer when the waiting has been removed and the working time is the bottleneck. That means the unassigned view is read on time and still grows. At that point, technicians are working at capacity and the tail is made of hard tickets rather than forgotten ones. The improvement plan, run for two or three quarters, is the evidence that gets a desk to that point honestly. The form of the case once it is there is in The Headcount Case. A headcount request made before the waiting is removed asks for a person to do more waiting. One made after shows, in the same table, that there is nothing left to remove.

A Short War Story: The Loan Laptops at Kestrel Academy

At Kestrel Academy, a secondary school with a desk of two, the desk lead, Callum, had a hardware-repair median of seven working days that had not moved in two years. That was because every laptop repair waited for a part and the parts took a week. A teacher whose laptop failed taught for a week from printed notes and borrowed screens. The deputy head, adding it up one term, put it at about thirty-five staff-days of lost planning time across the year. Callum's tail reviews said the same thing every month and he had stopped reading them. Then came the quarter he read them as a tally. He saw that the requester's wait and the repair's duration were two different clocks that the desk had been treating as one. He bought five loan laptops with the school's own image on them. From the next term a teacher with a failed laptop had a working one within two business hours. At that point the teacher's ticket was resolved, honestly, because the teacher's problem was solved. The repair became a separate ticket linked to the device, in the open backlog where everyone could see it, resolved when the part arrived. The lost planning time fell to about five staff-days a year. The repair tickets still took seven days and now bothered nobody. And the reopen rate on the resolved teacher tickets was nil, because the fix was a laptop that worked. The requester's clock and the asset's clock are different clocks, and the one to shorten is the one the requester can feel.

The Improvement Plan

The plan below is one page a month, and it is the loop made into a form. The baseline block is filled in once a quarter from the percentile worksheet and the pairing check. The cause block comes from the tail tally. The change block is the one thing being done this month, with an owner and a date. The measurement block is filled in a month later, and the decision is written in words. Keep the completed plans in order with the tail sheets. A year of them is the desk's improvement history, with every change dated and every result beside it. That is a document very few desks have and every headcount case needs. Nothing on the plan is a per-person figure, and nothing on it is a target for anyone to be measured against.

RESOLUTION TIME IMPROVEMENT PLAN — ONE CHANGE, ONE MONTH, ONE PAGE
Desk: ______________________   Month: __________   Owner of the plan: ______________   Definition card version: ____

A. BASELINE (from the percentile worksheet and the pairing check; refreshed each quarter)
   Resolved tickets per month (n) ....... ____        Median ........ ____ h       90th percentile ........ ____ h
   Reopen rate .......................... ____ in 100   Satisfaction .. ____ on ____ ratings
   Share of tail hours that was waiting (from the tail tally) .................................. ____ in 10
   Largest waiting stretch in the tail: before claim [ ]  requester [ ]  approval [ ]  supplier/team [ ]  forgotten [ ]  permission [ ]

B. THE CAUSE CHOSEN THIS MONTH
   Cause: __________________________________________   Tickets showing it last quarter: ____   Hours in them: ______
   Why this one first: biggest share [ ]  cheapest fix [ ]  entirely the desk's to fix [ ]  three months running [ ]

C. THE ONE CHANGE
   Change: ____________________________________________________________________________________
   Fix family: remove a wait [ ]  knowledge at hand [ ]  delegated permission [ ]  escalation agreement [ ]
   Owner: ______________   Starts: __________   Who else must agree: ______________   Agreed on: __________
   Expected to move: median [ ]  90th percentile [ ]  tail count for this cause [ ]  waiting share [ ]
   Must not move the wrong way: reopen rate [ ]  satisfaction [ ]

D. THE MEASUREMENT (one full month after the start; one quarter on a desk under thirty tickets a month)
   Measured on: __________   n ____   Median ____ h (was ____)   90th percentile ____ h (was ____)
   Reopen rate ____ in 100 (was ____)   Satisfaction ____ (was ____)   Tail tickets with this cause ____ (was ____)
   Ticket type most affected, median before ____ h, after ____ h, on ____ tickets each

E. THE DECISION, IN WORDS
   Keep [ ]   Extend to: ______________________ [ ]   Undo [ ]   Too early to tell, measure again on: __________ [ ]
   Reason: _____________________________________________________________________________________

F. NOT ON THIS PLAN
   [ ] no per-person figure or target        [ ] no change to the confirmation window or the clock definition
   [ ] no waiting subtracted from the headline  [ ] no second change started before this one is measured
   [ ] the readers of the monthly report were told what is changing and what to expect, before the month began

Amara's first plan named the follow-up cadence, because it was entirely the desk's to fix and cost nothing. The chief executive's office was told in advance that the median would probably not move and the tail probably would. It did not, and it did, which is a sentence that reads oddly and was exactly right. Three plans later the median was nine hours and the desk had not once been asked to hurry. The e-mail asking for "a bit faster" is pinned above her desk, next to the table, which she regards as the correct answer to it.

Frequently Asked Questions