Is 87% SLA compliance good? How to read your number before the board does

The monthly report says 87%. Someone at the leadership table will ask whether that is good. "It depends" is the honest answer, and a useless one unless you can say exactly what it depends on.

Five checks, in this order, before the report leaves your desk: the target, whether the 87% is availability at all, the clock, what was counted, and the shape of the misses. Every figure below is arithmetic on a worked example, except my own published record near the end, and none of them is a benchmark.

1. The target: 87% of what promise?

Take a month with 1,200 resolved tickets. 87% within target means 1,044 met it and 156 breached. What that means depends on the target:

The last row is the one people misread. It is a pass with 24 breaches to spare: had 25 more of those tickets been late, a little over one each working day, it would be a fail. I call a pass that uses more than half the allowance "Watch", not "Good"; the SLA calculator draws the same line for downtime.

Against a 95% target, the number to quote is not "eight points short" but "96 breaches more than the target allows". A board can picture that.

2. If the 87% is availability, stop

Ticket compliance counts records. Availability counts time. Both print as percentages; they are not the same kind of number.

On the SLA calculator's convention, a month is one-twelfth of a 365-day year: 730 hours. 87% availability on a 24 × 7 service means 13% of that was downtime: 94 hours 54 minutes, almost four days. A 99.9% target allows 43 minutes 48 seconds in the same month, so 87% means 130 times the downtime the target allows.

Measured over business hours only, on a 45-hour week (08:00 to 17:00, five days), the month holds about 195.5 counted hours. 13% of that is 25 hours 25 minutes: close to three working days down while people were at their desks.

An 87% ticket figure is a management conversation. An 87% availability figure is an outage review that should already have happened. Calculator 2 on the SLA calculator, "What availability did we actually deliver?", turns your own downtime and target into a sentence for the board.

3. The clock: 24 × 7, business hours and the GCC calendar

A business-hours target counts only the hours on the schedule, and across the GCC there is more than one schedule.

Take one P3 with an 8-hour target, logged at 15:30 on Thursday 15 October 2026, on the GCC business hours calendar presets:

• On a 24 × 7 clock it is due Thursday 23:30.
• On the UAE private-sector preset (Monday to Friday, 08:00 to 17:00) it is due Friday 14:30.
• On the Saudi Arabia preset (Sunday to Thursday, same hours) it is due Sunday 14:30.

Resolve it at 10:00 on Sunday and it has met its target in Riyadh, breached it in Dubai, and missed a 24 × 7 clock by 58 hours 30 minutes. A group running one ITSM schedule for both countries reports a number that is wrong for one of them before anyone has done any work.

Ramadan does this for a whole month. As the Ramadan 2027 service desk playbook shows on the Saudi preset with Ramadan hours of 09:00 to 15:00, an 8-hour P3 logged Monday 15:30 is due Tuesday 14:30 on normal hours and Wednesday 11:00 on Ramadan hours. If the tool's schedule still runs normal hours, a P3 resolved Wednesday at 10:00 keeps your promise to the business and shows as a breach. An 87% in a Ramadan month is a calendar question before it is a performance question.

Public holidays too. If Eid is not dated in the tool's schedule, the clock runs through it: on 9-hour days, every business-hours ticket open across Eid is charged 9 hours for each holiday that falls on a working day, hours nobody was meant to work. The calendar flags undated Islamic holidays until you date them; its Eid rows start at one day, so set the length your country announces as well as the date.

4. What was counted

• Resolved or still open? The service desk dashboard measures compliance on resolved tickets and lists open tickets already past target separately. Read both: a breach still open at month end is not in the 87%.
• Which priorities, and how many? In a month with 15 P1s, each one is worth 6.7 points. 13 of 15 is 86.7%, which a rounded report shows as 87%; one more on time and it reads 93%. Put the count next to the percentage.
• Paused clocks. A ticket that met its target only because on-hold time stopped the clock is a "Watch" on the SLA clock, not a "Good". Make sure every pause has a reason on the record.

5. The shape of the misses: priority, overrun and the watermelon

The same 87%, split by priority. The split is illustrative; the arithmetic is exact.

P3 and P4 are 1,100 of the 1,200 tickets, so they set the total. What the business felt is P2, 25 of 85 late, and the two P1s that missed: each of those should already have had its own review. Read priority before the total.

Then ask how late. The 156 breaches could be requests that missed by minutes or incidents left open for days; the count cannot tell you which. Report the median overrun and the single longest, not the average: one P4 forgotten for three weeks drags the average for the whole month, and the longest is the one the business remembers.

And watch for the watermelon: green outside, red inside. A 96% that hides a P1 at 70% is more dangerous than an honest 87%. If your 87% is red and nobody in the business has complained, the target or the clock may be wrong. If the report is green and stores, plants or vessels are complaining, the measure is wrong.

So, is 87% good?

My verdict:

1. If it is availability, no. Almost four days of downtime in a 24 × 7 month is a major incident review, not a KPI.
2. If it is ticket compliance below target, no. Quote the breaches over the allowance, and the priority that caused them.
3. If it is above target with more than half the allowance used, Watch. With 87%, that is any target above 74%, up to 87%. Say so before next month says it for you. At 74% or lower it is Good on the arithmetic, so ask whether the business agreed a target that low.
4. In every case, fix the clock and the counting first. A number measured on the wrong calendar can be wrong in either direction.

My own delivery record across five regulated sectors is 98–99% SLA compliance. That is my record, not a benchmark for yours. What made those figures worth reporting was agreeing the targets, the calendar and the counting rules with the business before the first report went out.

The sentence for the board

Fill in the brackets with your own figures:

In [September 2026], [1,044] of [1,200] resolved tickets ([87%]) met their resolution target against a [95%] goal (below goal): [96] breaches more than the goal allows, with [P2] weakest at [70.6%]. Of [N] still open, [N] are already past target. SLA time is measured on [the Saudi Arabia calendar (Friday–Saturday weekend)], with [Ramadan hours and public holidays dated]. [Most of the P2 breaches waited on one supplier]; [the Service Owner] will [agree a P2 resolution time in that supplier's underpinning contract] by [date], and we will report P2 separately from next month.

The service desk dashboard writes its own version of the first three sentences from your ticket export: compliance against your goal, the weakest priority, the open tickets past target and, when it times tickets on business hours, the GCC calendar you choose. Add the breaches over the allowance yourself: the allowance is resolved tickets × (100% − goal), here 1,200 × 5% = 60, so 156 breaches are 96 over. Calculator 2 on the SLA calculator writes the availability version. Both run in your browser: your ticket export and figures are never sent to ITSM Compass or anyone else.

Before the report goes out

1. Say which kind of 87% it is: ticket compliance or availability.
2. Put the target next to it, and the breaches over or under the allowance.
3. Name the clock: 24 × 7, or which country's working week, with Ramadan hours and public holidays dated in the tool.
4. State what was counted: resolved or open, which priorities, incidents or requests.
5. Show compliance by priority, with counts, before the total.
6. Count the tickets that met target only because of on-hold time.
7. Report the median overrun of the breaches, and the longest.
8. End with one action, the Service Owner who answers for it and a date.