Service Level Agreement
Service Level Agreements (SLAs) essentially represent our promise to deal with your IT 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.Have any questions or concerns? Get in touch with our friendly team by giving us a call or sending us an email!
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 (24x7x365, weekends, public holidays), different speeds of response, priority, or cover for different types of equipment.
Standard Hours of cover
While many clients have extended and out-of-hours of support, our standard cover runs from 8:30am to 5:30pm from Monday to Friday but excluding public holidays for England. Our monitoring services run 24x7x365 and major issues are dealt with by our out-of-hours on-call team. Our SLA timers run only during your agreed hours of cover.
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 adjust this to fit with your priorities e.g. key user issues requiring higher priority.
Priority is based on two factors: urgency and impact.
Urgency
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.
Impact
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 – Ooperational 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:
| All users or full site affected | A VIP is affected | A department or group of users are affected | A single user is affected | |
|---|---|---|---|---|
| A service running a critical function is fully down | P1 | P2 | P2 | P2 |
| A service running a critical function is working partially | P2 | P2 | P3 | P3 |
| A service running a non-critical function is fully down | P3 | P2 | P4 | P4 |
| A service running a non-critical function is working partially | P3 | P2 | P4 | P5 |
| The ticket is a change request or small non-urgent item | P5 | P3 | P5 | P5 |
In our experience most issues fall into priority 3, 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 are 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 team are able to override our standard priority assessment if you have made us aware of it. These timers represent maximums – we generally resolve 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.
“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 who is initially 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.
“Resolve within…”
This is the one that everyone is really interested in: the maximum time it should take to get everything up and running.
| Respond within | Resolve within | |
|---|---|---|
| Priority 1 | 30 minutes | 4 working hours |
| Priority 2 | 30 minutes | 8 working hours |
| Priority 3 | 30 minutes | 2 working days |
| Priority 4 | 30 minutes | 2 working days |
| Priority 5 | 30 minutes | 5 working days |
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 a software upgrade for the company some of the desktop 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 supply of parts or arrangements with you for collections and returns, so we usually allocate a priority of 5 for these jobs however depending on situation the time to repair/replace an item can be weeks. The P5 gives us a target of 5 working days not including any time the ticket is “With User” or “With Supplier” or similar statuses where Cloud10 are not working on the ticket.
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.