Response time and SLA: what should a support agreement say?

A support agreement often promises a response time, but that is rarely what matters most to you. What matters is how quickly the problem is solved. This article explains the difference between response time and resolution time, which priorities the agreement should have, what opening hours mean, and what you can ask so the agreement does not become a promise with no content. Remember that a promise is only worth something if it can be measured and followed up.

Response time and resolution time are two things

Response time is the time until someone has acknowledged the case and started looking at it. Resolution time is the time until the problem is solved or an acceptable workaround is in place. An agreement that mentions only response time says little about what you are actually buying.

Ask whether the agreement contains targets for resolution time and how they are measured. Also ask whether the clock stops when the partner is waiting for an answer from you.

An agreement can usefully also state what happens on reopening. If a case is closed but the error returns, it should not start again with a new response time and a new queue. Ask how this is handled and who decides whether a case is resolved.

Opening hours and what counts as working time

Check whether the response time is counted in working hours or calendar hours. A response time of four hours means something quite different if it applies during opening hours rather than at night and at weekends.

Find out which public holidays and holiday periods are excluded and what happens outside opening hours. Is there an emergency route for errors that stop operations, and how do you reach it?

Ask also how you reach support: phone, email or a case system. A fast response time on a channel you do not use does not help. Check that whoever creates the case gets a receipt with a case number.

Priorities that can be used

The agreement should define what is critical and who decides. A typical set of levels might look like this, but adapt it to your operations:

Critical: nobody can post or invoice, or the system is down
High: an important function does not work, but there is a temporary workaround
Normal: errors or questions that can wait a working day or two
Low: wishes and improvements

What a support partner cannot promise

Some problems sit with Microsoft: downtime in the service itself or an update that Microsoft controls. According to Microsoft Learn, the partner is the first level of support and escalates to Microsoft when necessary. Ask how escalation works and whether the partner's response time also applies when the case is with Microsoft.

Updates happen in an update window, which can be set per environment. Ask for the agreement to describe who tests your customisations before a new version.

Check that the agreement distinguishes between errors in your setup, errors in a customisation, errors in an app and errors in the Microsoft service itself. These have different owners and different response times. A good agreement describes who handles each type so that you are not sent around.

Checklist before you sign

Read the agreement with your own cases from the last quarter to hand. Would the priorities have fitted? How long would it have taken? That gives you a concrete picture of what the agreement means for you.

What are the response time and resolution time per priority
How are the measurements recorded and reported
What happens if the targets are not met
Who can create cases, and on which channels
What counts as hours used, and what is included
How long is the lock-in, and how is it terminated

Finally

We explain how we work with support on the page about services and prices. Ask us the same questions as you ask everyone else.