Home › Topics › Time to Resolution › Speed vs Quality

Speed Versus Quality: The Tension and the Pairing

Thursday, 15:05, at Meridian Parts. Oskar runs a desk of three, and in the spring he put a target on the wall: median resolution time under four business hours. It worked. Two months later the median is 3.1 hours and the chart has the shape charts are supposed to have. This afternoon the finance lead stops by to ask about an export that still does not run and says, meaning it kindly, "Your team is very quick to close things." Oskar looks at the finance lead's ticket. It was resolved in eleven minutes with the desk's most-used canned reply, "Please try restarting and let us know if it persists". It reopened two days later when she replied that it had persisted. He looks at the reopen count, which he has not looked at since the target went up. It was four a month in the winter. Last month it was fifteen.

The speed-quality tension is the plain fact that most of the quick ways to make resolution time fall are ways of resolving tickets badly. So a desk that chases the number alone will get the number and lose the thing the number was supposed to stand for. The pairing is the cure. Resolution time is never read on its own, but always beside a quality measure, usually the reopen rate and the satisfaction score. That way, a gain in speed that was paid for in quality is visible in the same glance. This article is part of our Time to Resolution series. This article is about the tension, the two checks, and the kind of target that produces rushing. It covers the one-page monthly check that keeps a desk honest with itself. The general idea of reading metrics in pairs, and the full set of pairs, is in Reading Metrics Together. This article is that idea applied to one metric.

This article covers the ways a resolution time falls without anything getting better, with a table. Next come the reopen as the first check, satisfaction as the second, and the ticket that comes back as a new one. Then come the target that produces rushing and what to set instead, and reading the pair as four quadrants. A short war story follows, then the pairing check to copy. The numbers are Meridian's and belong to a fictional desk.

Fast and Wrong Is Still Fast

Resolution time measures the gap between two stamps, and the resolved stamp is set by a technician. So the number can be made to fall by setting the stamp sooner, whatever has happened to the ticket. Nobody on a desk decides to do this. It happens the way a hedge leans toward the light. A target is on the wall, a canned reply is one click away, and a ticket that is "probably fixed" gets resolved at ten to five instead of being checked in the morning. Each shortcut is small, reasonable in the moment, and leaves a mark somewhere other than the resolution-time chart. The table below is the six commonest, what the requester experiences, and where the mark shows up.

How the number fallsWhat actually happenedWhat the requester experiencesWhere the mark shows
The premature resolve"Try this and let us know" sent and the ticket resolved in the same clickReplies that it did not work; waits again from the back of the queueReopen rate; satisfaction comments about "closing before fixing"
The workaround resolveThe problem is bypassed, not fixed, and the ticket is resolved without saying soIt works, differently; the real fault returns later as a new ticketRepeat tickets from the same requester on the same subject; problem records
The split"Resolved; please raise a separate ticket for the second part"Does the desk's filing for it; waits twiceTicket count rises while resolution time falls; satisfaction
The pauseTicket parked in a waiting status that stops the clock, with nothing awaitedNothing changes; the ticket is quietWaiting time beside elapsed time; waiting statuses with no note
The resolve-and-reopen loopResolved early, reopened, resolved again; the report counts the first resolveFixed on the second or third attemptReopen rate; the definition card's stop-stamp rule
The cherry-pickQuick tickets claimed first; slow ones left for someone else or for laterThe simple ask is instant; the hard one waits a weekMedian falls while the 90th percentile rises; the tail review

Notice that none of these marks is on the resolution-time chart. A desk that watches only that chart will see six shortcuts as six improvements. It will keep the target that caused them because the target appears to be working. The pairing is the habit of looking at the column on the right at the same time as the chart, every month, before anyone says the word "improvement". The first article in this series, What Time to Resolution Actually Measures, closes off the pause and the resolve-and-reopen loop at the definition stage. The four others need the checks below.

A workaround is not a shortcut when it is called one. Suppose you tell a requester "I have given you a way round this for now; the underlying fault is logged and I will update you when it is fixed". Resolving the ticket with that said and a problem record raised is good practice, not gaming. That is because the requester knows where they stand and the fault has somewhere to live. The mark of the bad workaround is silence. The ticket says resolved, the reply says nothing about what was and was not fixed, and the requester finds out in a fortnight. The difference is one sentence in the resolving reply, which is a cheap place to put honesty.

The Reopen as the First Check

A reopen is a resolved ticket that the requester brings back, usually by replying to say the fix did not work. It is the cleanest signal that a resolution was not one. Most tools reopen a resolved ticket automatically when the requester replies to it. In QuerySolv a requester's reply reopens a resolved or closed ticket. So a resolution that did not hold leaves its mark on the same ticket rather than vanishing into a new one. The reopen rate is the number of tickets reopened in a period divided by the number resolved in it. The honest ways of counting it, including what to do about the reopen that is really a new question, are in Measuring Reopens Honestly. Here the rate is read for one purpose only: beside the resolution time.

Read the two together and the shortcuts become visible. Resolution time falling while the reopen rate holds or falls is a desk getting faster at fixing things. Resolution time falling while the reopen rate rises is a desk getting faster at saying things are fixed. That is what Oskar's wall had bought: a median down by a third and a reopen count nearly four times what it was. Nothing on the resolution-time chart distinguished the two cases. The reopen count did it in one glance. That is why the two belong on the same page, in the same chart if the tool allows it, and never in separate reports read by separate people.

Two cautions keep the reopen check honest. The first is that reopens are rare, so a month's count on a small desk is a handful and a handful is noise. Read the quarter, and read it as a direction rather than a level. The second is that not every reopen is a failed fix. Some are a requester adding a new request to an old ticket because it is the one they have open. Some are a thank-you that the tool treats as a reply. A sample of ten reopens read each month, which is the reopen review in its simplest form, tells you what share are the real kind. That share is what you pair with the resolution time. (A thank-you that reopens a ticket is the tool's way of ensuring that nobody says thank you twice.)

Satisfaction as the Second Check

The satisfaction score is the requester's own rating of how the ticket went, usually gathered by a one-question survey sent with the resolving reply. It catches what the reopen does not. A reopen says the fix failed. A low rating says the requester felt rushed, or unheard, or was fixed without being told what had been done. A workaround that technically holds will never reopen and may still score badly. The survey rides on the resolving reply in many tools, which is one more reason never to resolve silently, as Avoiding the Silent Close argues. Where QuerySolv is the tool, the rating request goes out with the resolving reply and satisfaction appears in the standard reports alongside the time figures. That is where it needs to be read.

Pair it the same way: speed up and satisfaction steady is good; speed up and satisfaction down is rushing, even when reopens are flat. Satisfaction lags, because a requester rates the ticket after it is resolved and the ratings for a month arrive over the following weeks. So read it a month behind the resolution time and over a quarter rather than a month. Response rates are low on most desks, and a dozen ratings out of two hundred tickets is a sample with a loud minority in it. So read the comments before the score. Three comments saying "closed before it was fixed" are worth more than a tenth of a point either way. What the score measures, and how to read around the bias in who answers, is the subject of the Measuring Satisfaction series.

The two checks disagree sometimes, and the disagreement is useful. Reopens up and satisfaction steady often means the desk is resolving early but recovering well. In that case, the requester replies, the ticket is picked up quickly, the second attempt works, and the requester ends up content. That is still a cost, in the requester's time and the desk's. But it is a different problem from reopens up and satisfaction down, which is a desk that resolves early and then makes the requester wait again. Read both, and when they disagree, read ten tickets to find out why.

The Ticket That Comes Back as a New One

The reopen check has a blind spot: the requester who does not reply to the resolved ticket and raises a new one instead. That may be because the old one was closed and they thought it was finished, or because they did not know that replying would work. Or it may be because the form is the only way they have ever asked. The resolution is just as failed and the reopen rate does not move. The check is a search for new tickets from the same requester, on the same subject, within two weeks of a resolve. They are counted by hand from a sample or by the tool if it links tickets. On Oskar's desk this found another six a month that the reopen count had missed, most of them replies to the restart message that had come in as fresh requests.

The fix is partly to count them and partly to prevent them. Tell the requester in the resolving reply that a reply will reopen the ticket. Link the new ticket to the old one when it arrives so that the history is in one place and the resolution-time clock is read from the original. What a reopen of either kind is telling the desk, and the habits that stop them happening, are in Preventing Reopens. The related measure that asks whether the ticket was fixed at the first contact, which has its own gaming problem and its own series, is The Limits of First Contact Resolution. The two pair with resolution time in the same way and for the same reason.

The Target That Produces Rushing

A target produces rushing when it has four features at once. It is on a single number, it is per person, it is visible, and something good or bad happens as a result of it. Oskar's wall had all four. The median was the only number on it; the chart was broken down by technician; everyone walked past it. The team had understood, without anyone saying so, that the person at the bottom would be having a conversation. Under those conditions the six shortcuts are not a failure of character; they are what any reasonable person does when the quickest way to look good is one click away. A measure that becomes a target stops measuring what it used to, because the people measured start managing the measure instead of the work. The general cures are in Metric Gaming and Its Cures. The specific ones for resolution time are below.

Set the target on the desk, not the person. A desk-level median is something the team improves together, by fixing the causes the tail review finds. Nobody can improve it by cherry-picking because the cherry-picked ticket still counts for the desk. Per-person figures in this series are for coaching, in private, on at least thirty resolved tickets per person, within a category, and are never the thing a target is set on. Set the target on the pair, and say the quality half first. The target "reopen rate no higher than last quarter, and within that, median resolution time under four hours" is one nobody can hit by resolving early. That is because resolving early moves the first half the wrong way. Make the target a direction rather than a line where the sample is small, and say so on the chart.

Keep service-level targets, which are promises about individual tickets at each priority, separate from this. A service-level target says that a top-priority ticket will be resolved within a stated time. It is a promise to requesters, and it is measured as the share of tickets that met it. The design of such targets belongs to the SLA Design series and is not redone here. The desk's internal target on its median is a different thing, a goal for the team's own improvement. Confusing the two produces a desk that treats a requester promise as a personal score. The service-level target is for the requester. The pair is for the desk. The wall chart, if there is one, shows the pair.

Remember: never read resolution time without the reopen rate and the satisfaction score beside it. A fall in resolution time with reopens or satisfaction moving the wrong way is rushing, not improvement. A target on resolution time alone, per person and on a wall, will produce exactly that.

Reading the Pair: Four Quadrants

Each month the pair lands in one of four places, and each place has a reading and a response. The table below is the four, with the resolution time as the row and the quality checks as the column. "Quality" here means the reopen rate and the satisfaction score read together, with the repeat-ticket count folded in where the desk has it. The readings are directions over a quarter, not single-month levels, because on a small desk a single month of reopens is a handful.

Resolution timeReopens and satisfactionReadingWhat to do
FallingSteady or improvingGenuine improvement; the desk is fixing things fasterFind out which change did it, from the improvement plan, and keep paying for it; say so to the team
FallingWorseningRushing; the number is being bought with premature or silent resolvesTake the target off the wall; read ten reopens; restore the quality condition before the speed one
RisingSteady or improvingDeliberate slowing, or load; check whichIf the desk chose to fix properly, say so and accept it for a quarter; if load, the volume series and the headcount case
RisingWorseningSomething has broken: a new system, a leaver, a supplier, a backlog formingRead the tail review and the cut table this week, not next month; this is the quadrant that becomes a backlog

The bottom-left quadrant is the one most often misread, and it is worth a sentence. A desk that stops resolving early will see its resolution time rise for a quarter while its reopens fall. That is because tickets that used to be resolved in eleven minutes and reopened two days later are now resolved once, properly, in two hours. That is the desk getting better and the chart getting worse. A desk lead who has not told the readers of the chart in advance will spend the quarter explaining. Tell them in advance. "The median will rise for a quarter while we stop closing tickets before they are fixed; the reopen rate is the number to watch" is a sentence that turns a bad-looking quarter into a planned one. It is only available before the quarter starts.

A Short War Story: The Four-Hour Target at Acme

At Acme, the desk lead, Jonah, set a personal target of four business hours on median resolution time for each of his three technicians. He published the three medians weekly. Within six weeks all three were under target, which he reported as a success. In the same six weeks the finance team's month-end tickets had begun to be resolved differently. Those tickets arrive in a cluster in the last three days of each month and are mostly about report exports that fail on large data sets. They were being resolved with "workaround applied: export in two halves" in a median of forty minutes. The resolves met the target and did not fix the exports. The finance team split exports by hand for two month-ends. The second month-end close ran two days late because a reconciliation that depended on a single export could not be split. The finance manager's team logged about thirty hours of overtime putting the halves back together. The finance manager asked the operations director why IT's performance reports said the desk had never been faster. Jonah withdrew the per-person targets and put the reopen rate and the repeat-ticket count beside the median on the one chart the desk now shows. The export fault was raised as a problem record and fixed by the vendor in the following quarter. The median went back up to five hours and nobody has mentioned it since. A target on speed alone will be met, and the cost will be paid by whoever is not in the room when it is set.

The Pairing Check

The check below is one page a month, filled in before the resolution-time figure goes anywhere. The first block is the speed half, from the percentile worksheet. The second is the quality half, from the tool's reopen and satisfaction reports and a ten-minute search for repeat tickets. The third is the quadrant and the sentence. The last is the list of things that are not allowed to be true before the figure leaves the desk. It is deliberately short, because a check that takes an hour will be done for two months. This one takes fifteen minutes once the reports exist.

THE PAIRING CHECK — ONE MONTH, ONE PAGE
Desk: ______________________   Month: __________   Prepared by: ______________   Definition card version: ____

A. SPEED (from the percentile worksheet)
   Resolved tickets (n) ............................ ____        last quarter ____
   Median resolution time .......................... ____ h      last quarter ____ h    direction: up [ ] flat [ ] down [ ]
   90th percentile ................................. ____ h      last quarter ____ h    direction: up [ ] flat [ ] down [ ]

B. QUALITY
   Tickets reopened by the requester ............... ____        reopen rate (reopened / resolved) ____ in 100
   Reopen rate last quarter ........................ ____ in 100                        direction: up [ ] flat [ ] down [ ]
   Of ten reopens read: real failed fixes ____  new requests ____  thank-yous ____
   Satisfaction: ratings received ____  of ____ surveys   score ____    last quarter ____   direction: up [ ] flat [ ] down [ ]
   Comments mentioning closed-too-soon, rushed, or not told what was done: ____
   New tickets from the same requester on the same subject within two weeks of a resolve: ____

C. THE QUADRANT
   Speed: falling [ ] rising [ ]      Quality: steady or improving [ ] worsening [ ]
   Reading: genuine improvement [ ]  rushing [ ]  deliberate slowing or load [ ]  something broken [ ]
   If rushing or broken: ten tickets read on __________   cause found: ______________________________

D. THE SENTENCE FOR THE REPORT
   "Median resolution time ______ h (____ last quarter), 90th percentile ______ h, with the reopen rate at ____ in 100
    (____ last quarter) and satisfaction at ____ on ____ ratings; read together, the month is ______________________."

E. NOT TRUE BEFORE THIS LEAVES THE DESK
   [ ] the resolution-time figure is nowhere on its own, on a wall, in a summary or in a chart
   [ ] no per-person resolution-time target exists; per-person figures are coaching only, thirty tickets minimum
   [ ] any target in force names the quality condition first and the speed condition second
   [ ] a planned rise in resolution time has been announced to the report's readers before the quarter, not after
   [ ] the waiting time beside the elapsed time has been checked for pauses with nothing awaited

Oskar took the target down that Thursday and replaced it with a single chart of the median and the reopen count on the same axes. It was for the desk as a whole, with no names on it. The median rose to four and a half hours over the next quarter and the reopens fell back to five a month. The finance lead's export, which had been a workaround for two months, was fixed at the third attempt and stayed fixed. The chart looks worse than the old one did. It is also the first one on that wall that has been true, which Oskar has decided is a feature.

Frequently Asked Questions

What reopen rate is acceptable?
There is no general figure, and anyone who gives you one has not seen your tickets. Compare the desk with its own previous quarter. Treat a rising reopen rate alongside a falling resolution time as the signal, whatever the level. Read ten reopens a month to learn what share are real failed fixes rather than new requests or thank-yous. Pair that share, not the raw count, with the resolution time.
Our satisfaction response rate is tiny. Is the score still useful as a check?
As a direction over a quarter, yes; as a monthly level, no. Read the comments before the score, because three requesters saying "closed before it was fixed" is a finding even when the score has barely moved. Look at who is answering, since a low response rate usually means the very pleased and the very annoyed. The reopen rate carries more of the weight on a desk with few ratings.
Should we have a resolution-time target at all?
A desk-level one, as a direction, with the quality condition stated first, is useful: "reopens no higher than last quarter, and within that, a median under four hours". A per-person target on the number alone will be met and will cost you reopens, repeat tickets and satisfaction. Service-level targets per priority are a separate thing, a promise to requesters, and belong to the SLA design series.
How do I spot the resolve-and-reopen loop in the figures?
Check which resolved stamp your tool's report uses by reopening a test ticket, resolving it again a day later, and reading the report. If it uses the first stamp, the loop is invisible in resolution time and shows only in the reopen count, so the pairing is the only defence. If it uses the last, the loop lengthens the resolution time and the rushing penalises itself. Write what you find on the definition card.
Is a slower resolution time ever the right result?
Yes, for a quarter after a desk stops resolving tickets before they are fixed. That is because tickets that used to be resolved in minutes and reopened in days are now resolved once in hours. The reopen rate falls at the same time and that is the number to point at. Announce the planned rise to the report's readers before it starts; a rise explained afterwards looks like an excuse.
Should technicians see each other's resolution times?
No. Per-person resolution times are for a private coaching conversation, on at least thirty resolved tickets within a category. They are a prompt to ask which tickets were slow and why, not a score. A shared or ranked list teaches a team to claim quick tickets and resolve early, which makes the reopen rate, the tail and the satisfaction score all worse. The team sees the desk-level pair.

From the QuerySolv team: we build self-hosted help desk software for Windows. QuerySolv runs as one Windows service on your own network. It takes requests by web form, e-mail, live chat, social messages and REST API. It is licensed once per installation rather than per agent per month. The free trial runs the full product for 30 days.