By Dan Stark
Comparing IT support response times looks simple: pick the shortest one. That only works if every provider measures the same thing.
Here’s a hypothetical. An employee reports a problem. An acknowledgment arrives right away. They still can’t work, and nobody has told them what happens next.
The provider may have already met its response commitment. It depends on what the agreement counts as a response.
So before you compare targets, get three answers: what action meets the target, when the clock runs and who owns progress afterward. Your service level agreement (SLA) should make all three clear.
The worksheet below turns those answers into questions for each provider, with the wording and evidence to request. Use it when you’re comparing IT help desk services or reviewing the support arrangement you already have.
What do IT support response times measure?
“Response” isn’t a single event, and a metric’s name won’t tell you which one you’re getting. Take Zendesk’s standard first reply metric. It generally measures time to an agent’s first public reply. Zendesk’s SLA behavior has exceptions and can differ. So a report labeled “first response” doesn’t establish what happened technically.
When reviewing an agreement, distinguish these three events:
- Acknowledgment: The request arrived. A receipt alone doesn’t show that anyone has assessed the problem.
- Qualified response: For this guide, a person able to assess the issue reviews it and identifies the next step. It’s a useful buying distinction, not a standard industry definition.
- Technical action: Someone performs or directs a documented step, such as diagnosis, troubleshooting or escalation to the right specialist.
Ask which event meets the target. If an acknowledgment is enough, ask whether a separate commitment covers technical engagement.
Define restored, resolved and closed
The words that end a ticket need the same care. Getting someone working again may involve a workaround. That can be a good outcome while a permanent fix is pending.
But don’t read a “resolved” ticket as proof that the underlying cause is fixed. ServiceNow’s incident workflow, for example, allows resolution through a workaround or a permanent solution. Closure is a separate step. The user can close the ticket, or the system can close it automatically if it’s configured to. And depending on the provider’s process, a returning issue may need a new ticket instead of reopening the old one.
Ask your provider to define:
- What usable service must be restored, and who confirms it.
- What qualifies as resolution.
- When a ticket can close, and how you report an issue that remains or returns.
- Who owns any remaining investigation or permanent fix.
These milestones aren’t a fixed sequence, and they don’t each need a separate clock. They can share a timestamp or happen apart. What matters is knowing which event satisfies each commitment and where unfinished work goes.
How hours and priority affect IT support response times
Another hypothetical: a routine request arrives at 7:30 p.m., and its target counts only business hours. The overnight wait may not count against the target at all.
The agreement should name the covered days, hours, time zone and holidays. It should also explain the route for urgent issues outside those hours. Accepting tickets at any hour isn’t the same as round-the-clock technical coverage.
Atlassian’s SLA calendars show the mechanics. A team sets each calendar’s time zone, working days and hours, and holidays. That’s a product capability, not a schedule every provider follows.
The calendar decides when a clock runs. Priority can decide which target applies. A label such as P1 or “critical” doesn’t mean the same thing everywhere, so test each provider’s definitions against your operation: a whole department unable to work, one person blocked before a deadline, a system running on a usable workaround.
Confirm who assigns priority, who can change it and what happens to elapsed time after a change. A response target only helps if the priority reflects the real business impact.
Assign ownership when work depends on someone else
Suppose your IT provider investigates an application failure and finds that the software vendor has to make a change. The ticket moves to “waiting on vendor.”
That status leaves two questions open. Does an SLA clock pause? And who keeps coordinating the issue?
The status answers neither. Atlassian’s SLA conditions show that a clock’s start and stop conditions are configured and that pausing is optional, so a waiting label doesn’t tell you what your agreement permits. It doesn’t tell you who’s chasing the vendor either.
The vendor’s repair schedule may be out of your hands. Coordination responsibilities can still be defined. Within the agreed support scope, settle who opens the vendor case, supplies technical details, follows up and updates your team. Name any approvals or access your business has to provide. Define when a stalled issue goes to a specialist or a manager.
Use this SLA review worksheet
Work through this table with each provider. Ask for the agreement wording behind each answer and a sample report with client information removed. If you’re reviewing an existing arrangement, use your own ticket records.
The worksheet is a buying tool. It doesn’t set CTMS service targets or describe an industry standard.
| What to define | What to ask | Evidence or wording to request |
|---|---|---|
| Priority and changes | What determines urgency and impact? Who can change priority, and what happens to elapsed time? | Definitions with business examples, change authority and a record of each change. |
| Intake | Which channels are covered? Is there a different route for urgent or after-hours issues? | Named channels and instructions employees can follow. |
| Clock start | Does the clock start at submission, ticket creation, queue arrival or assignment? | The exact event and timestamp for each commitment. |
| Covered hours | Which days, hours, time zone and holidays count? | A service calendar and separate after-hours terms. |
| Response | Does an acknowledgment, a qualified response (assessment plus the next step), or a technical action meet the target? | The qualifying action, plus any required role or reply content. |
| Restoration | What level of usable service must return? Does a workaround qualify? | Restoration criteria and how restored service gets confirmed. |
| Resolution and closure | What does each status mean? Can closure be automatic? Does a returning issue reopen the ticket or start a new one? | Resolution and closure rules, the route for returning issues and ownership of unfinished work. |
| Pauses | When can a clock pause, and what restarts it? | Permitted reasons, timestamps and resume conditions. |
| Updates and escalation | Who communicates, how often, and what triggers specialist or management involvement? | An update schedule, escalation triggers and named roles. |
| Outside vendors | Who manages the vendor case? Does waiting on a vendor change the clock or the update duties? | Separate rules for the clock, coordination, approvals and any additional charges. |
| Exclusions | Which systems, people, locations, incidents or project work fall outside the commitment? | An exclusion list and how to get help with excluded work. |
| Reporting | Which tickets count, which targets were met and how are unfinished tickets handled? | Results by priority and commitment, ticket counts, exclusions and supporting records. |
Treat any blank as something to settle before you compare targets. Where two providers define a row differently, their headline times aren’t directly comparable.
Check performance against the actual commitment
The worksheet pins down what’s promised. Reports show what was delivered, so read them just as closely.
Start with averages. An average describes a set of tickets. On its own, it can’t tell you whether individual tickets met their targets or whether the issues that stopped work got the right attention.
For each commitment and priority, ask for the number of eligible tickets, the number that met the target and the period covered. Confirm whether the agreement sets its target for every eligible ticket or for a stated percentage. If it defines an average-based target, assess that measure as written, then look at slow and business-critical cases separately.
Also ask how the report treats open, paused, reopened and excluded tickets. Atlassian’s reporting guidance for Jira Service Management Data Center shows why. One of its SLA reports can count tickets whose clocks are still running. Another counts only tickets whose clocks have stopped. Don’t assume two dashboards calculate a similarly named percentage the same way.
Then read a few tickets that missed their targets. Follow the timestamps from intake through assessment, action, updates and outcome. Look for repeated delays, unclear handoffs or work left unfinished after closure.
Finally, agree what happens after a miss: escalation, corrective action and any remedy the agreement provides. Tracking a number is only useful if the review improves the support process.
Keep support commitments separate from uptime and recovery
A cloud service’s availability commitment doesn’t tell you how quickly a help desk will assess your ticket. It measures something else. Microsoft explains that availability SLAs depend on their measurement definitions and conditions.
Recovery objectives answer another question: how the business plans to restore systems and data after a disruption. Handle those through backup and recovery planning. Neither an availability percentage nor a recovery objective replaces a defined support response.
Match the agreement to the work your business needs
Choose commitments around the operations you need to protect. Then spell out the actions, hours, responsibilities and evidence.
CTMS provides Help Desk support through Ohio-based engineers, with a defined path for troubleshooting, escalation and follow-through. When an issue calls for it, that means bringing in the appropriate specialist or coordinating with an outside vendor. Broader responsibility for the environment belongs in a managed IT services conversation. Either way, confirm the work and service commitments included in your agreement.
If your current arrangement leaves the response clock, the escalation path or ownership unclear, talk with CTMS about your support needs.
