Service Level Agreements

The Service level agreement (SLAs) define how we will respond to your issues and requests. They show you our reliability, efficiency and confidence in the support that we provide.

The basics:

Our SLAs depend on the agreed hours cover and the priority of your issue or request.

We can provide bespoke SLAs to suit your needs – extended hours of cover, different speeds of response or priority

Standard Hours of cover

  • Our standard cover runs from 8:30 am to 5:30 pm, from Monday to Friday, but excluding public holidays for England.
  • Our monitoring service 24×7
  • Our SLA timers run only during the agreed hours of cover.

Two clocks ticking

We have to timers running on every support ticket raised. These times represent maximums – we very rarely exceed these time limits. The timers will be put on hold, for example when we are awaiting a response from you with further information or approval.

‘Respond within’

  • This is the maximum amount of time (within your hours of cover) that it should take us to get back to you and confirm that we have received your ticket and its being handled.

“Resolve within…”

  • This is the one that everyone is really interested in: the maximum time it should take to get everything up and running.

How we work out priorities

  • Our SLA timers also depend on the priority of your issue or request. When you raise a ticket with us, we make an assessment based on the information you have given us.
  • We let you know the priority we have assigned, but are happy to take extenuating circumstances into account, if you think we’ve got it wrong.


This is how many people are affected by the incident, e.g.

  • LOW– one person or small group of people affected
  • MEDIUM– department or large group of people affected
  • HIGH– whole organisation is affected


This relates to how disruptive the incident is, e.g.

  • LOW– there’s an easy and effective workaround, so this is more an irritation than a stoppage
  • MEDIUM– operational efficiency is degraded, but there is either a reasonable workaround or other members of the team are unimpeded
  • HIGH– the issue is critical and one or more major business processes are stopped

We then apply our priority matrix as follows:

HIGH Severity MEDIUM Severity LOW Severity
HIGH Impact Priority 1 Priority 2 Priority 3
MEDIUM Impact Priority 2 Priority 3 Priority 4
LOW Impact Priority 3 Priority 4 Priority 5

In our experience most issues fall into priority 4, so that tends to be a default. The priority assigned dictates the amount of time we give ourselves to deal with your incident or request.

Some examples of priorities

  • Priority 1– nobody can send or receive emails (everyone is affected, and a major business process is stopped)
  • Priority 2– Internet access for the whole company seems slower than usual (everyone is affected, and efficiency is degraded)
  • Priority 3– After the web browser has been upgraded for the company some of the shortcuts have disappeared (everyone is affected but there is an easy workaround)
  • Priority 4– Your computer is slow starting up in the morning, but everybody else is fine (your efficiency is lower but you’re the only person affected)
  • Priority 5– Someone is missing the shortcut everyone has to a shared folder, though they can save files to it by manually navigating to the folder (there’s a straightforward workaround, and only one person is affected)

Our Goal Percentage

Priority Type Respond Within… Resolve Within… Goal %
Priority 1 1 hour 8 hours 95%
Priority 2 1 hour 8 hours 95%
Priority 3 1 hour 16 hours 95%
Priority 4 2 hours 16 hours 95%
Priority 5 8 hours 40 hours 95%