Resolution Time

The first number support teams measured was time to first reply. It's easy to measure and easy to improve — add people or widen coverage hours and it drops immediately.

Which produced something strange in teams that watched only that number. First reply time is a healthy thirty minutes and customer complaints don't fall. Open the records and the reason appears: a reply went out inside thirty minutes and its content was that someone would look into it and get back to them. Four days have passed since.

It isn't the agent's fault either. When the measured number is first reply, people move toward hitting first reply. Attach a quick line to every incoming request and the day's numbers are satisfied, while the actual solving gets pushed back.

Resolution time exists to measure that back half. It shows whether requests get carried through, which means it only means something read next to first reply time.

Take the difference between when a request was received and when it was closed as resolved, then produce a representative figure from the set.

Four things need settling first.

1. The start point — when the customer sent it, not when you saw it. Count a weekend request from Monday morning and the hours the customer spent waiting vanish from the number.
2. The end point. Better to use when the customer confirmed than when the agent decided it was solved. Send an answer and close immediately, and when that answer doesn't work the follow-up gets logged as a new request. One problem becomes two tickets and both read as short, while the customer experienced one long wait.
3. How waiting is handled. Decide whether the two days spent waiting on the customer for more information count. The usual approach keeps a second figure with those stretches excluded. When the two figures differ a lot, the signal isn't that you're slow but that you aren't asking for everything at once.
4. The representative figure. Mean and median diverge. Ten tickets at 2, 3, 2, 4, 3, 2, 5, 3, 2 and 90 hours give a mean of 11.6 and a median of 3. One 90-hour ticket pulled the mean up, so the median is better for running the team, and the worst experience gets read from the top 5 percent separately.

Splitting by request type isn't optional. Put password resets and data migration requests in one average and the result can't inform anything. Split into simple questions, configuration questions, outages, and feature requests and each branch's number points at different work. A rising figure in one branch is a specific problem; a rising blended figure is only a mood.

There's no absolute benchmark. What you sell and what you promised set it. If a support SLA — the committed number of hours to respond — exists, that commitment is the baseline. Against a 24-hour promise, a three-hour median is comfortable; against a four-hour promise, the same three hours is tight, because the median tells you nothing about how often you missed.

Three things are worth reading.

1. Change by branch. When the same type of request takes longer than last month, there's a cause: fewer agents, a product change creating territory nobody knows, or a blocked path for escalating to engineering.
2. The tail. A median of three hours with a top 5 percent at ninety means a small number of customers are having a very bad experience. Open those ninety-hour tickets and they're usually one kind — requiring engineering confirmation, or handed between agents three times.
3. The reopen rate. If resolution time dropped while the same customers came back more often, tickets were closed fast rather than solved. The two have to be read together, because the same improvement in one can be produced either by solving faster or by giving up earlier.

Reducing it isn't about pressing agents harder. Three things usually do it: ticket deflection, reducing intake by letting customers resolve common questions themselves; organizing internal material so agents can find answers; and fixing in advance the criteria and route for anything that has to go to engineering. The third shrinks the tail most, and it's also the cheapest of the three, since it's a decision rather than a body of work.

"First response is thirty minutes and resolution is four days. We have to read both."

Naming a state where only one half is healthy.

"Median is three hours and the top 5 percent is ninety. Let's look at just those."

Separating the tail to find the cause.

"Resolution time fell but reopens went up. I think we're closing fast."

Doubting the reason a number improved.

At Pagedeck, Sofia reads requests in four branches: simple questions, configuration questions, outages, and feature requests. Simple questions run a one-hour median, configuration questions four hours, outages are measured separately from occurrence to recovery, and feature requests stay out of this number entirely.

There's a reason feature requests are excluded. That branch contains tickets that take months or get decided against altogether, so counting them makes the average meaningless and pushes agents to close them hastily. Instead, feature requests are read on a different measure: whether a yes-or-no answer went out within a few days of intake. A request declined clearly in three days is handled; a request left open for four months is not, however the resolution figure looks.

A common belief is that the goal is to make resolution time small. A lower number looks better, which is natural enough. But the value is computed from when someone presses close. Tie an agent's performance to this number alone and they move toward sending a guess and closing immediately. The same problem then arrives as a new ticket two or three times, each one recorded as short, while the customer tells the same story three times. What belongs on a scorecard isn't this figure by itself but this figure read with the reopen rate and satisfaction.

The other belief is that adding agents reduces it. First reply time does respond directly to headcount, so this should too. But the tail of resolution time comes from blocked paths, not from staffing. If nobody has defined where a ticket requiring engineering confirmation goes, that ticket waits four days with ten agents on staff. Headcount reduces queue time; procedure reduces the tail. Confusing the two is how a support team doubles in size with the worst tickets unchanged.