8 JSM SLA mistakes we keep finding in audits

Atlassian documents how to configure an SLA. What the documentation cannot tell you is that your SLA is measuring the wrong thing, and that everyone has stopped believing the number on the dashboard.

These are the problems we keep finding in Jira Service Management audits, roughly in order of how often they appear.

1. The clock counts time you do not control

The default time to resolution runs continuously from creation. So a ticket waiting three days for the customer to send a screenshot burns three days of SLA, and the report says your team missed the target.

The fix is a pause condition on whatever status means "waiting for them". It sounds obvious, and it is the single most common omission we see — usually because the SLA was configured before those statuses existed and never revisited.

Time to resolution
  Start:  Status = Open
  Pause:  Status = Waiting for customer
          Status = Pending third party
  Stop:   Status = Resolved, Closed, Done

Check the pause condition against the workflow as it is today, not as it was when the SLA was written. Every status added since then is unaccounted for by default.

The other half: paused forever

The mirror image is just as common. A ticket parked in "Waiting for customer" while nobody follows up shows a healthy SLA indefinitely, because the clock is paused. The metric looks fine and the customer has been ignored for a month.

Pause conditions need a companion: automation that chases after a few days and escalates or closes after a defined period. Without it, pausing is a way of hiding tickets from the report.

2. Calendars that do not match reality

A 24/7 calendar on a team that works 9 to 5 means every ticket raised on Friday evening is already breaching by Monday morning. The reverse is worse: business hours on a service you actually promised round the clock, so genuine out-of-hours breaches never appear at all.

Holidays are the detail that gets forgotten, and it matters more than people expect for teams spread across countries — a calendar with only one country's public holidays quietly penalises everyone else.

3. One SLA for every request type

A password reset and a production outage on the same four-hour target means either the reset target is absurdly generous or the outage target is a fiction. Both make the dashboard meaningless.

Differentiate by priority, request type, or both. The goal is targets a team can hit on the routine work and genuinely has to fight for on the critical work — which is the only way the number carries information.

4. Time to first response measuring the wrong event

An automated "we have received your request" email counts as a first response under some configurations. The SLA then reports excellent responsiveness while customers wait days for a human.

Define first response as the first public comment by an agent. If an automated reply satisfies the condition, the metric is measuring your automation rather than your team.

5. Goals nobody agreed to

SLAs written by whoever configured Jira, never discussed with the business, and never shown to the customer. The result is a team measured against a number invented by someone who was not going to be held to it.

An SLA is a commitment with two sides. If it does not appear in an agreement, or at least in a document the requesting department has read, it is a private KPI wearing an SLA's clothing.

6. Breaches that trigger nothing

A breach that produces no notification is a number in a report nobody opens. By the time it is seen at the monthly review, the ticket is closed and the moment to act has passed.

Useful configuration alerts before the breach, not after: at 75% of the target, notify the assignee; at 90%, notify the team lead. After the breach, all you can do is explain it.

Automation rule
  When:  SLA threshold breached (Time to resolution: 75% elapsed)
  If:    Priority in (Highest, High)
  Then:  Comment (internal) + notify assignee

  When:  SLA threshold breached (90% elapsed)
  Then:  Notify service desk lead

7. Reopened tickets restarting the clock

A ticket resolved, reopened by a dissatisfied customer, then resolved again shows two comfortable SLA periods rather than one long unhappy experience. Teams under pressure learn this pattern quickly, and the metric stops describing reality.

Decide explicitly whether the clock continues or restarts on reopen, and make sure the report distinguishes tickets that were reopened at all. Repeated reopens are a signal in their own right, usually more useful than the SLA number.

8. Nobody has looked at it since go-live

The workflow gained statuses. The team changed hours. A new request type was added and inherited a default SLA nobody chose. The configuration was correct for a service that no longer exists.

Review the SLA configuration whenever the workflow changes, and at least twice a year regardless. It takes an hour and it is the difference between a metric people trust and one they route around.

A short audit you can run yourself

• •For each SLA: do the start, pause and stop conditions cover every status in the current workflow?
• •Does the calendar match when the team actually works, including holidays for every location?
• •Are targets differentiated by priority or request type, or is one number applied to everything?
• •Does first response require a human comment?
• •Is there an alert before the breach, not just a report after it?
• •What proportion of tickets sit paused for more than a week, and who is chasing them?
• •Has anyone outside the service desk seen and agreed these targets?

If more than two answers are uncomfortable, the dashboard is currently describing something other than your service.

Where this fits

We audit Jira and Jira Service Management configurations as fixed-scope work: workflows, permission schemes, automation, SLAs and licence usage, ending in a written report ranked by impact. €65/hour, and we are an independent provider rather than an Atlassian Solution Partner, which means no incentive to recommend more licences than you need.