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 falls | What actually happened | What the requester experiences | Where the mark shows |
|---|---|---|---|
| The premature resolve | "Try this and let us know" sent and the ticket resolved in the same click | Replies that it did not work; waits again from the back of the queue | Reopen rate; satisfaction comments about "closing before fixing" |
| The workaround resolve | The problem is bypassed, not fixed, and the ticket is resolved without saying so | It works, differently; the real fault returns later as a new ticket | Repeat 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 twice | Ticket count rises while resolution time falls; satisfaction |
| The pause | Ticket parked in a waiting status that stops the clock, with nothing awaited | Nothing changes; the ticket is quiet | Waiting time beside elapsed time; waiting statuses with no note |
| The resolve-and-reopen loop | Resolved early, reopened, resolved again; the report counts the first resolve | Fixed on the second or third attempt | Reopen rate; the definition card's stop-stamp rule |
| The cherry-pick | Quick tickets claimed first; slow ones left for someone else or for later | The simple ask is instant; the hard one waits a week | Median 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 time | Reopens and satisfaction | Reading | What to do |
|---|---|---|---|
| Falling | Steady or improving | Genuine improvement; the desk is fixing things faster | Find out which change did it, from the improvement plan, and keep paying for it; say so to the team |
| Falling | Worsening | Rushing; the number is being bought with premature or silent resolves | Take the target off the wall; read ten reopens; restore the quality condition before the speed one |
| Rising | Steady or improving | Deliberate slowing, or load; check which | If the desk chose to fix properly, say so and accept it for a quarter; if load, the volume series and the headcount case |
| Rising | Worsening | Something has broken: a new system, a leaver, a supplier, a backlog forming | Read 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?
Our satisfaction response rate is tiny. Is the score still useful as a check?
Should we have a resolution-time target at all?
How do I spot the resolve-and-reopen loop in the figures?
Is a slower resolution time ever the right result?
Should technicians see each other's resolution times?
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.
