Service Levels
We aim for all our systems to be available 24-7 (so nothing is deliberately switched off, apart from during occasional planned and communicated maintenance). However, when things do go wrong, the following targets are in place.
Service classifications
Each service is given a classification, which determines our service levels and targets for that service. To find a service’s classification, see the service catalogue.
- Critical services support the University’s core operations. Outages risk immediate and significant damage to the university. We aim to restore all major impact outages (affecting 80% of system functionality or users) within 2 hours, and target 99.9% availability across the month - this is equal to 1 outage lasting less than 43 minutes.
- Essential services support University processes and although short outages are not catastrophic, service availability is required to allow the University to operate effectively. We aim to restore all major impact outages (affecting 80% of system functionality or users) within 4 hours, and target 99.5% availability across the month - this is equal to 1 outage lasting less than 3 hours and 30 minutes.
- Supporting services contribute to efficient University operations, often by supporting underlying business processes. Outages are undesirable, but do not cause immediate damage to the University. We aim to restore all major impact outages (affecting 80% of system functionality or users) within 1 working day, and target 99.0% availability across the month - this is equal to 1 outage lasting less than 7 hours and 15 minutes.
Response and resolution
Incident response and resolution
An ‘incident’ is when something is not working, or not working properly, when it should be. Our incident response & resolution targets are based on both the incident’s impact and the service classification.
-
How we prioritise incidents
Incident prioritisation
Incident priority is determined by the IT Service Desk using the following prioritisation matrix. The targets for each priority are listed below, under ‘Targets’.
Critical service Essential service Supporting service Major impact*
P1
P2 P4 Medium impact**
P2 P3 P5 Low impact***
P4 P5 P5 * Major impact: affecting more than 80% of users of a service or 1,000 people, or more than 80% of system functionality
** Medium impact: affecting 20% - 80% users of a service or more than 10 people, or a critical piece of functionality
*** Low impact: affecting fewer than 10 people, or a non-critical functionality of a serviceTargets
Priority Incident response
(time to assign to a technician)Incident resolution
(time to resolve)P1 15 mins 2 hours P2 30 mins 4 hours P3 2 hours 1 day P4 1 day 3 days P5 2 days 5 days
Service request response and resolution
A ‘service request’ is a request for something new or amended, such as access to a system or software or a new piece of equipment. Our service request targets are based on the complexity of the request type.
-
How we prioritise service requests
SLA
Description
Response Times
Resolution Times
R0
A Service Request that is fully automated end to end that may require an approval*. The Service Desk may need to resend the approval if there is no response after 2 automated approval emails are sent.
4 hours
1 working day
R1
Simple Service Requests with defined workflow that are fulfilled by an individual team.
1 working day
3 working days
R2
Service Requests with a defined workflow and process, sometimes involving multiple steps or teams.
R2 is also the default SLA for undefined requests, equivalent to a P5 incident.
2 working days
5 working days
R3
More complex Service Requests, often involving approvals*, liaising between the customer and ITD, or a 3rd party supplier.
2 working days
2 weeks
R4
More complex Service Requests that include multiple ITD teams, and require elements of planning or analysis – including Software Proposals, Software Refresh, New Network Sockets or Relocation/Removal of Printers.
3 working days
4 weeks
R5
Demand Management Requests
5 working days
12 weeks
*Time spent waiting for an approval do not count towards the ITD SLA to fulfil the request