This article explains the IT Service Level Agreement (SLA) priority levels 1-4 and response times for tickets submitted by the Mines community.
The Standard/Public SLAs for tickets can be found in the tables below. As a preface to the SLA details, key terms and components are defined prior.
Key Definitions
- Service Level Agreement (SLA) - measurable and reportable terms between a service provider and clients and/or end users for providing an expected outcome for IT service. In TeamDynamix, SLAs reflect ticket response time and resolution times the customer can expect to receive.
- Priority - Based on impact and urgency, can be used to identify an order in addressing tickets. Specific to our Mines IT environment, priority determines the SLA to apply.
- Urgency - The time it takes for an incident to have a significant impact on business. Used in determining the priority of a ticket. Distinguished in High, Medium, and Low levels.
- Impact - The measure of the effect of an incident on business processes. Criteria to calculate impact include the number of affected users. Distinguished in affecting a user, multiple users, Group (such as a whole building or department), or Widespread (such as campus-wide).
- Incident - Tickets related to an unplanned interruption to a service. Due to the nature of a service not working as expected with incident tickets, these will come in with a higher priority level than a service request ticket of the same impact.
- Service Request – Ticket related to a solicitation from a user for assistance, access, or authorized change or access to an IT service. For example, a software installation request. Service requests should be a predefined offering for customers, as to be completed without a Request for Change (RFC).
SLA Components
The following items contribute towards SLAs functioning properly and have dedicated sections below with additional details pertinent to our Mines configuration:
Operational Hours
This time dictates when SLAs will be in place and active. There can be many sets of operational hours within an org but for simplicity, Mines IT will start with one set consisting of the following:
- 1 day = 9 business hours
- 1 week = 5 business days (45 Hours)
- 1 month = 4 business weeks (180 Hours)
SLA Clock + Ticket Statuses
Each ticket contains a built-in SLA clock, which starts upon submission of a ticket and tracks time (based on the operational hours listed above), to compare against the SLA “deadline”. The time does not run on weekends, holidays, or holiday breaks. In addition, it also does not run when the ticket is placed in “On Hold” status.
Triggers for satisfying the Response component of a ticket SLA:
- Status changed to "Assigned" or "In Process"
Triggers for satisfying the Resolve component of a ticket SLA:
- Status changed to "Closed"
Escalations
Basic paths for escalations can be defined per service, on granular levels to provide actions based on a time elapsed against a given SLA. For example, a default escalation behavior is to notify the group or individual responsible when an SLA has reached 100% of the response or resolve deadline.
The image below shares a sample SLA escalation step to help visualize the options associated with a “Respond By” SLA:
Priority Levels
To deem which priority can be assigned to tickets (and subsequently which SLAs are applied), the following guidelines have been established for determining ticket priority:
- Major IT or Major Security incident - Priority 1
- Mines Emergency Alert issue - Priority 1
- Access issue (someone can't log in or can't do their job) - Priority 2
- New device deployment (need it to do their job) - Priority 2
- Generic issue - Priority 3
- Generic request - Priority 4
Standard/Public SLAs
The following table describes which SLAs will be applied to IT tickets based on priority. Detailed descriptions of the priority levels can be found in the section below the chart.
|
Priority Levels
|
Urgency
|
SLA Deadline
(in Operational Time)
|
Follow-up with Customers
|
|
Priority 1
Impact: Widespread
|
High
|
Response:
30 minutes
Resolve:
1 business day (9 Hours)
|
Hourly
|
|
Priority 2
Impact: Whole building or department
|
High
|
Response:
1 business day (9 Hours)
Resolve:
2 business days (36 Hours)
|
Daily
|
|
Priority 3
Impact: One group or small number of users impacted
|
Medium
|
Response:
2 business days (18 Hours)
Resolve:
7 business days (63 Hours)
|
2 days
|
|
Priority 4
Impact: One user or a limited amount of users impacted
|
Low
|
Response:
3 business days (27 Hours)
Resolve:
10 business days (90 Hours)
|
4 days
|
Priority Level Details
Priority 1 SLA
- Building outage with critical urgency
- Urgent need that impacts campus or will have a high level of visibility
Priority 1 incidents are considered an emergency priority. The outage has a major impact on facility operations, administration, or instruction that causes a complete loss of service. Workarounds to provide the same functionality are not possible or cannot be found in time to minimize the impact on classroom instruction. All necessary personnel within IT are expected to work continuously on the issue or coordinate with the service provider responsible for a resolution.
The outage has one or more of the following characteristics:
- Entire building, school, or many classrooms impacted
- Critical functionality is unavailable
- Example: Complete network and/or phone system outage
Priority 1 service requests should be rare but should be handled with high priority and given the likelihood of high visibility or widespread impact. For that reason, the response times need to be high, with only a priority 1 incident being higher. Communication needs for Priority 1 service requests will go beyond that of the ticket but should include ticket communication for details and documentation.
Priority 2 SLA
- Classroom/Dept./Lab Outage with high urgency
- Important requirement impacting a large amount of customers, or preventing someone from doing their job
Incidents are considered a high priority. Outage has a significant impact on classroom, lab, or department and happens when instruction can proceed but performance is significantly reduced. No workaround is available, however, operation can continue in a restricted fashion. IT staff will discuss possible solutions and assign the incident to the appropriate technical staff.
The outage has one or more of the following characteristics:
- One entire classroom, department, or lab impacted
- Important functionality is unavailable
- Example: Many computers, a projector, or wireless outage
Priority 2 service requests should be handled with high priority, yet the urgency will be diminished against that of the same level of incident. These are planned as an output to a project or corresponding approved RFC. However, these service requests will likely have broader communication needs beyond the ticket. For that reason, the response times need to be fast, and the correspondence regular.
Priority 3 SLA
- Individual disruption with medium urgency
- Future need impacting group or small amount of users
Incidents are considered a medium priority. It has an impact on one user or a small number of users and causes some loss of service. IT staff will discuss possible solutions and assign the incident to the appropriate technical staff.
The outage has one or more of the following characteristics:
- One user or small number of users impacted
- Some functionality is unavailable
- Examples: Computer, printer, internet, or email outage
Priority 3 service requests will be common and regular, with response times often dictated by volume at peak times. For that reason, they can and should be planned for in advance to minimize impact on customers with slow response times. Target response and resolve deadlines should be set up to accommodate the extreme circumstances, with the more regular SLA response and resolve times ideally much lower on average.
Priority 4 SLA
- An issue with low urgency
- Enhancement or suggestion with low-impact
Incidents are considered a low priority, causing some loss of service or inconvenience. It somewhat impedes the use of a system and/or a workaround is available. IT staff will assign the request to the appropriate technical staff.
The request has one or more of the following characteristics:
- Hardware or software not working as expected but a workaround has been identified or is a mere inconvenience.
- Examples: Computers, printers, projectors, software programs, and intermittent network issues
Priority 4 service requests will have a low impact and could be irregular based on customer needs with regular service offerings. Like priority 3 requests, SLA response and resolve times will be established around extreme times, with the goal of regular SLA response and resolve times averaging much lower.