Most service teams already record tickets. The problem is that the numbers are often averaged across all priorities, measured in calendar hours, or paused whenever an agent likes, so the report says 95% while customers feel let down.
This guide covers which metrics to track, how to set priorities and targets, how to run the clocks fairly, and a worked month of SLA reporting for a Dubai service company, including a service credit. It ends with a set-up checklist and an FAQ.
What is the difference between response time and resolution time?
Response time runs from when the ticket is logged to the first meaningful reply from a person. An automatic "we have received your request" email does not count. The reply should show that someone has read the ticket, for example by confirming the issue, asking for a missing detail or giving a next step.
Resolution time runs from when the ticket is logged to when the issue is fixed and the ticket is marked resolved. If the customer reopens the ticket because the fix did not work, the original ticket was not resolved, and the clock should continue from where it stopped rather than restart.
The two clocks measure different things. Response time tells customers they have been heard, so it drives how they feel about the service. Resolution time tells them the problem is gone, so it drives whether they renew. A team can hit every response target and still fail on resolution, because quick replies with no fix behind them only delay the complaint.
Track both, by priority, and report them separately. A single "SLA met" figure that mixes the two hides which one is failing.
Which help desk metrics should you track?
Start with the two SLA clocks, then add a small set of measures that explain them. Seven are enough for most teams:
| Metric | How to calculate it | What it tells you |
|---|---|---|
| First response SLA compliance | Tickets answered within target ÷ tickets due in the period | Whether customers are acknowledged on time |
| Resolution SLA compliance | Tickets resolved within target ÷ tickets due in the period | Whether problems are fixed on time |
| Average and 90th percentile resolution time | Business hours from logged to resolved | How long most customers wait, and how long the slow ones wait |
| Backlog and ageing | Open tickets, grouped by age band | Whether work is piling up |
| Reopen rate | Tickets reopened ÷ tickets resolved | Whether "resolved" really means fixed |
| First contact resolution | Tickets resolved on first reply ÷ tickets resolved | How much the first line can fix alone |
| Customer satisfaction (CSAT) | Satisfied survey replies ÷ survey replies | How the service felt to the customer |
Report each by priority, by customer for contract customers, and by team. The 90th percentile matters more than the average: an average of six hours can hide a tenth of customers waiting three days.
How do you set priorities and SLA targets?
Priority should come from impact and urgency, not from how loudly the customer asks. Define three or four levels in plain words, with examples from your own business, so agents and customers classify tickets the same way.
| Priority | Definition | First response | Resolution | Compliance target |
|---|---|---|---|---|
| P1 Critical | Service down or a business process stopped, no workaround | 1 business hour | 8 business hours | 95% |
| P2 High | Major function impaired, workaround exists | 4 business hours | 2 business days | 90% |
| P3 Normal | Single user issue or minor fault | 1 business day | 5 business days | 90% |
| P4 Request | How-to question, change request, information | 1 business day | Agreed with customer | Not measured |
The figures above are an example, not a standard. Set yours from what your team can achieve today, then tighten them once the process is stable.
Three rules keep priorities honest. First, the agent sets priority against the written definition, and only a supervisor can change it after the ticket is logged. Second, record the reason for any change. Third, check a sample of tickets each month: if P1 is growing faster than real outages, the definitions are being stretched to jump the queue.
How should the SLA clock run?
Most disputes about SLAs are disputes about the clock. Agree these points in the contract and set them in the system, so the report and the customer's experience match.
Business hours, not calendar hours. Set working hours for each team and country. Many UAE businesses work Monday to Friday, while the weekend in Saudi Arabia is Friday and Saturday. Load public holidays for each country, and set separate hours for any team that offers 24-hour cover for P1.
Pause only for agreed reasons. Typical reasons are "waiting for customer" (a reply, access or approval) and "scheduled for an agreed date". Waiting for your own supplier or another internal team is not a pause reason; it is part of your resolution time.
Measure against the priority at the time. If a ticket is raised to P1 after four hours, measure the P1 targets from the moment of the change, and keep the earlier time on record.
Stop the resolution clock on "resolved", not "closed". Many teams auto-close resolved tickets after a few days with no reply. The SLA should stop when the fix is delivered.
An example of a business-hours clock: a P2 ticket is logged on Thursday at 16:30, with working hours of 08:00 to 17:00, Monday to Friday. The 2-business-day resolution target is 18 business hours. Half an hour runs on Thursday and nine hours on Friday, leaving 8.5 hours, so the ticket is due on Monday at 16:30.
What does a month of SLA reporting look like? A worked example
A Dubai IT services company supports 60 business customers on annual maintenance contracts. In September it logged 640 tickets that fell due in the month. Here is the SLA report against the targets above:
| Priority | Tickets | Response met | Response % | Resolution met | Resolution % | Resolution target | Result |
|---|---|---|---|---|---|---|---|
| P1 | 20 | 19 | 95.0% | 17 | 85.0% | 95% | Missed |
| P2 | 180 | 171 | 95.0% | 158 | 87.8% | 90% | Missed |
| P3 | 440 | 427 | 97.0% | 409 | 93.0% | 90% | Met |
| Total | 640 | 617 | 96.4% | 584 | 91.2% |
Here is how to read it.
The blended figure misleads. A resolution rate of 91.2% across all tickets looks like a pass against a 90% target. It is carried by P3 volume. The tickets that matter most, P1 and P2, both missed.
Response is not the problem. Response compliance is 95% or better at every level. The team acknowledges tickets quickly; it is the fix that is slow.
Look at the breaches, not just the rate. The three P1 breaches were reviewed. Two waited for a replacement part from a supplier, and one was assigned to an engineer on leave and sat unnoticed for three hours. The first is a stock and supplier question; the second is an assignment rule. Neither would show up in an average.
One contract customer has a service credit clause: if its P1 resolution compliance falls below 95% in a month, it receives a credit of 5% of the monthly fee. The customer pays AED 10,000 a month and had four P1 tickets, of which three were resolved on time (75%). The credit is AED 500. The company issues a credit note for AED 500 plus 5% VAT of AED 25, a total of AED 525, against the October invoice.
These figures are illustrative.
How do you set up SLA tracking? A checklist
What does HYP see at service teams?
HYP's implementation team sees the same gaps at service and support teams across the Gulf. Tickets arrive by phone and WhatsApp and are logged later, if at all, so the clock starts late and the report looks better than the service. SLA reports are built in a spreadsheet at month end, averaging all priorities together. And the "waiting for customer" status is used for anything that is stuck, including tickets waiting on the company's own suppliers.
The best-run teams log every request at the moment it arrives, let the system run the business-hours clock, and allow only agreed pause reasons. Their team leads look at tickets about to breach each morning, not at last month's percentage. They also link each ticket to the customer's contract, so service credits are calculated from the same data the customer sees.
HYP Help Desk logs tickets from every channel, applies priorities and SLA clocks by customer, assigns and escalates tickets, and reports response and resolution compliance by priority, customer and team. See how it works on our Help Desk page.
Related reading: for field service against contract SLAs, see Facility Management Contracts: Tracking SLAs, Work Orders and Monthly Billing.