How to Fix SLA Management in Your ITSM — Once and For All

If your ITSM has more than five active services, SLA management is probably already causing problems — even if nobody has said it out loud yet.

The most common pattern I see in the field: rules created one by one, for each combination of service, priority, and issue type. Over time, the environment becomes a collection of exceptions. Some services have SLA coverage, others don't. The rules are hard to audit. And every time a new service is added, someone has to remember to create a new rule — which doesn't always happen.

This isn't a configuration problem. It's a design problem.

The real problem

The most common approach I see in practice is service-specific: one rule for SAP incidents, another for Active Directory access requests, another for hardware requests. It works at the beginning. It stops working when the catalog grows.

Every new service requires a new rule. Every priority change has to be replicated across all existing rules. When the catalog reaches 30, 50, or 100 items, maintenance becomes unmanageable — and what should be a clean matrix turns into a patchwork.

The right question

How do I make any new service automatically inherit the correct SLA, without manual configuration?

That question changes the entire design. And the answer starts with a concept Atlassian officially documents: service tiers.

Service tiers — the official standard

Atlassian formally defines four tiers for service criticality in JSM:

• Tier 1: Mission-critical. Failure has a direct impact on customers or company revenue.
• Tier 2: Important service. Failure causes noticeable degradation but doesn't fully stop operations.
• Tier 3: Small impact. Users may not even notice the failure.
• Tier 4: Failure with no significant effect on experience or finances.

This structure isn't invented by each company. It's a standard documented by Atlassian and aligned with the broader ITSM market. And it's the foundation of an SLA architecture that actually scales.

The matrix

With a Tier assigned to each service, the SLA structure becomes straightforward:

Service Request

Incident

The same logic applies to other issue types — Change, Problem, Access Management — adjusting the times according to the nature of each process.

Worth noting: JSM Cloud supports up to 90 SLA goals per project. Combined with priority-based sub-goals — which group priorities within a single goal — this architecture fits comfortably within that limit for the vast majority of environments.

When a new service is added

You add the service, assign its Tier — and that's it. The correct SLA is applied automatically. No new rule. No additional configuration.

How to handle exceptions

No matrix covers 100% of cases. The goal is to cover 99% with a clean structure and leave the remaining 1% for explicit, documented exceptions.

Example: a P1 SAP incident has a 2-hour SLA due to a contractual requirement. That case becomes an exception rule in JSM, with higher priority than the standard rule. The exception exists — it's just visible and intentional, not a workaround disguised as a solution.

A note on implementation

There are different ways to implement this architecture — some available on the Standard plan, others that require Premium or Enterprise. The right choice depends on what you already have and how your instance is structured.

What doesn't change across approaches is the principle: Tier lives at the service level, not inside the SLA rule.

The result

A JSM instance built on this architecture has consistent SLA coverage for all services — including ones that haven't been created yet — auditable rules, and a service catalog that controls criticality without depending on manual configuration every time something new is added.

SLA isn't a rules problem. It's a design problem.

If your SLA structure doesn't look like this yet — what's the main thing stopping you from getting there?