Two clocks, two entirely different problems. Teams that report them as one number lose the ability to tell a queue nobody is watching from work that genuinely takes time — and those need opposite fixes.
First response time measures how long the requester waited before a human engaged. Resolution time measures how long until the problem was actually fixed. They run independently: a ticket can be picked up in four minutes and still take four days. Response failures are almost always routing or coverage; resolution failures are capacity, dependencies or a target that was never realistic.
What Each Clock Actually Measures
First response time starts when the ticket is created and stops at the first genuine reply from a person. It is a measure of attention — whether anyone is watching the queue and whether the ticket reached the right one.
Resolution time starts at the same moment and stops when the issue is fixed. It is a measure of capability — whether the team has the skills, access and capacity to close the work.
Because they share a start and differ only in what stops them, they answer different questions about the same ticket. That is the point of running both.
The Auto-Reply Problem
This is where most first response numbers quietly become fiction.
If your ticketing system sends an automated acknowledgement on creation — “thanks, we've received your request” — and that acknowledgement is recorded as a public reply, your first response time collapses to near zero on every ticket. The metric will look excellent and mean nothing.
Worth checking in your own system before trusting the number: does a trigger-generated public comment stop the clock, or only a comment authored by an agent? Tools differ, and the setting is rarely where you would look for it.
The useful definition is the one the requester would recognise. If a human has not read the ticket, the requester has not been responded to, whatever the timestamp says.
What Counts as Resolved
The resolution clock has its own ambiguity, in two places.
Resolved is not closed. Most systems distinguish them: resolved means the engineer believes it is fixed, closed means the requester agreed or the timer ran out. Measuring to closure inflates every number by however long your auto-close window is — often several days of nothing happening.
Reopens. If a ticket is resolved, reopened two days later and resolved again, most reporting counts the original resolution. That is defensible for SLA compliance and misleading for anyone asking how long the user's problem actually lasted. A rising reopen rate alongside falling resolution times usually means the first one was optimistic.
Why They Move Independently — and What That Tells You
| Pattern | What it usually means | Where to look |
|---|---|---|
| Response bad, resolution fine | Nobody is watching the queue, or tickets land in the wrong one. Once someone picks it up, the work itself is straightforward. | Routing rules, queue ownership, shift coverage at specific hours |
| Response fine, resolution bad | Tickets are acknowledged promptly then stall. The team is attentive but blocked. | Escalation paths, vendor dependencies, skills gaps, target realism |
| Both bad | Capacity, not process. More work arriving than people to do it. | Volume trend, staffing, whether some categories should not be tickets at all |
| Both good, users unhappy | The targets are too loose to mean anything, or resolution is being called early. | Reopen rate, and whether resolved-to-closed gaps are being ignored |
The fourth row is the one teams miss. Metrics that are always green are not evidence of a healthy service desk; they are usually evidence of targets set where they could not be missed.
Business Hours Affect Them Differently
If your targets are counted in elapsed time rather than working time, the two clocks are distorted unequally.
A 30-minute response target is unreachable for anything raised at 18:00 on a Friday — it will breach overnight regardless of what anyone does. A three-day resolution target on the same ticket barely notices the weekend. So an elapsed-time configuration makes response metrics look catastrophic and resolution metrics look roughly fine, and the reports mislead in opposite directions.
This is the single most common reason a service desk's response numbers look worse than the team's actual behaviour.
Setting Targets That Survive a Rota
Two rules cover most of it.
Response targets should be set against coverage, not ambition. If nobody is rostered between 18:00 and 09:00, a 15-minute response target is a promise about hours you are not staffing. Either restrict the target to your operating schedule or extend the cover; a figure that depends on someone voluntarily checking their phone is not a service level.
Resolution targets should be set from your own history. Take last quarter's resolved tickets by priority, find the point where 80–90% were already closed, and start there. Targets invented in a workshop tend to describe what the room wished were true.
How the Major Tools Name These
| Tool | Response | Resolution |
|---|---|---|
| Zendesk | First reply time — creation to first public agent comment | Total resolution time, one of six SLA metrics |
| Jira Service Management | Time to first response, as an SLA goal matched by JQL | Time to resolution, same mechanism |
| Freshservice | First response due, set per priority | Resolution due, set per priority |
| ServiceNow | Both are task SLAs created from SLA definitions, with their own start, pause and stop conditions | |
The labels differ; the two questions do not. When either clock is missed, what counts as an SLA breach covers how that gets recorded and reported.
Where InfraCue Fits
InfraCue sets response and resolution targets separately, per priority and optionally per category and sub-category, and counts them in working time against a per-customer schedule — weekday windows, holidays including annually recurring ones, timezone-aware across a DST shift. That removes the distortion described above, where an elapsed-time clock makes response numbers look far worse than the team performed. Every ticket reports one state — on track, at risk, paused, breached or met — on the dashboard and the NOC wallboard, and the clock pauses genuinely while a ticket waits on a user, an approval or a vendor. Pricing starts at $39 per month (₹2,999), with a 30-day trial and no credit card.
This guide is maintained by InfraCue, an IT operations platform with ticketing, SLA tracking and device monitoring in one console.