SLA in support: response vs resolution

An SLA (service level agreement) in software support is a written commitment by the contractor: how quickly it responds to a request, and how quickly it resolves it, depending on the severity of the issue. Response time and resolution time are two different numbers, and most misunderstandings start when they are mixed up.

Response time versus resolution time

Response time runs from the moment a request is opened until a person on the contractor's side starts handling it: reads it, acknowledges it, asks a first question. An automatic reply usually does not count.

Resolution time runs until the issue is fixed, or a workaround restores the work. It is always longer, so many agreements phrase it as a target rather than an absolute commitment.

A contractor who commits to a very short response time and to no resolution time at all has, in effect, promised that someone will read the request.

Severity levels

Times are set by severity, and three or four levels are usually defined:

Critical: the system does not work, or a core business process has stopped;
High: an important part does not work, but there is a way around it;
Medium: an issue that gets in the way without stopping work;
Low: a question, a small request or a cosmetic defect.

Just as important is who decides the level and what happens in a disagreement. Without such a rule every request is opened as critical.

Where an SLA breaks

A clock that runs at night too. The agreement should say whether times count in business hours or around the clock, and what happens on weekends and holidays.
Waiting for the client. When the contractor waits for details, access or approval, the clock is usually paused. If that is not written, the time counts against the contractor.
Measurement in one side's tool. If only the contractor has access to the data, the client cannot check the report.
No consequence. A commitment where nothing happens when it is broken is mostly a good intention.

How to measure an SLA

Each request needs four points in time: when it was opened, when the first response came, when it went into waiting for the client and when it came back, and when it was closed. From these you calculate both times, separately for each severity level.

The monthly report should not be a single average. It is better to show how many requests met the target at each level, and to list those that did not, with the reason.

And both sides should see the same data. An SLA compliance report that only the contractor can check is a statement, not a measurement.

What SLAtech Vantage does here

SLAtech Vantage does not calculate response and resolution times and does not measure SLA compliance. What it does do:

every task has a priority and a due date. A task that comes from Freshservice takes the due date set on the ticket there, when one exists;
an open task past its due date is marked as overdue, and an open task that has not moved for a while goes onto a "needs attention" list (the default is 14 days);
the "awaiting client" status separates what is stuck with the contractor from what is stuck with the client;
errors coming from error monitoring get a severity level, from low to critical.

Frequently asked questions

What is the difference between response time and resolution time in an SLA?

Response time is the time from opening a request until a person on the contractor's side actually starts handling it, and an automatic reply usually does not count. Resolution time is the time until the issue is fixed or a workaround restores the work. Resolution time is always longer, which is why it is often phrased as a target rather than an absolute commitment.

How many severity levels does a software support SLA need?

Most agreements need three or four levels: critical when the system or a core process has stopped, high when an important part does not work but there is a workaround, medium when something gets in the way without stopping work, and low for questions and small requests. More levels are hard to apply in practice. It is just as important to write down who sets the level and what happens in a disagreement.

Does the SLA clock stop while the contractor waits for the client?

Usually yes, but only if the agreement says so. When the contractor waits for details, access or approval from the client, that time is outside its control, so in many agreements the clock pauses until the client answers. For this to work, the wait has to be recorded as a separate status on the request, with a start and an end time that can be checked.

How can a client check that the contractor meets the SLA?

You need access to the request data itself, not only a summary report: when each request was opened, when the first response came, when it was closed, and which severity level it was given. With that data you can check each level separately and ask about the requests that missed their target. A single monthly average hides exactly the requests that matter.