Service Level Agreements
Service Level Agreements (SLAs) define how we respond to your issues and requests. They reflect our reliability, efficiency and confidence in the support that we provide.
Service Level Agreements (SLAs) essentially represent our promise to deal with your ICT issues and requests within a given time frame. They show that we have an efficient and mature process for providing IT support and that you can have confidence in us.
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 (24x7x365, weekends, public holidays), different speeds of response, priority, or cover for different types of equipment. Just ask!
Standard Hours of cover
While many clients have extended and out-of-hours of support, our standard cover runs from 9:00 am to 5:00 pm (GMT/BST), from Monday to Friday, but excluding public holidays for England.
Our monitoring service runs 24×7 and major issues are dealt with accordingly by our out-of-hours incident team.
Our SLA timers run only during your agreed hours of cover.
Our monitoring runs 24x7x365 regardless of your cover, so you can elect to increase cover for critical systems if you wish.
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.
Priority is based on two factors: severity and impact.
Roughly, 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
Again, roughly speaking, 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.
Overriding our priorities
We aim to be flexible and recognise that sometimes there are extenuating circumstances. Perhaps the issue affects your customers, or key staff are having issues with a critical project with an impending deadline.
Our technicians are able to override our standard priority assessment where there is a good reason, if you have made us aware of it.
Three clocks are ticking
We have three clocks (timers) running on every ticket you raise, though most of our clients are only interested in two of them (“respond within” and “resolve 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 who is dealing with your ticket – you get to speak to a trained technical expert straight away, rather than a recorded menu system or a call logger.
This is more for our own use, to ensure that we’re on target to get the issue resolved on time.
This is the one that everyone is really interested in: the maximum time it should take to get everything up and running.
These timers represent maximums – we generally come well within these time limits.
In certain circumstances we will put a clock on hold – for example when we are awaiting a response from you with further information or an approval for work that may have a temporary impact on you or your business.
The goal percentage
Sometimes, with the best will in the world, and in spite of our best efforts, there are extenuating circumstances that mean the time limit is breached. This is exceptionally rare, but just to cover this we set a target “goal %”.
This is how many of your tickets we promise to achieve within the time limits. To date, we are well above these targets for all our clients, of course.
|Priority Type||Respond Within…||Plan Within…||Resolve Within…||Goal %|
|Priority 1||1 Hour||4 Hours||8 Hours||95%|
|Priority 2||1 Hour||4 Hours||8 Hours||95%|
|Priority 3||1 Hour||8 Hours||16 Hours||95%|
|Priority 4||2 Hours||8 Hours||16 Hours||95%|
|Priority 5||8 Hours||16 Hours||40 Hours||95%|
|Low Priority Admin||2 Hours||8 Hours||40 Hours||95%|
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)
Other exceptions to our priorities
The following are exceptions to our priorities and timers in the above matrix:
Paid workshop repairs – very often we’re dependent on the supply of parts or arrangements with you for collections and returns, so we usually allocate a priority of 5 for these jobs.
Quotes – we have no timers on these requests, but we do our best to be prompt and keep you fully up to date.
Low priority admin requests – these have response times that match priority 4 but a resolve time of a priority 5. Generally, we get plenty of advance notice and these requests are not urgent.