Incidents. Service Requests. In the world of IT support, what’s the difference?
Well, since you asked…ITIL promotes dividing all IT work into two groups and differentiates by calling them Incidents (Break/Fix, Reactive, etc.) and Service Requests (everything else).
ITIL defines an Incident as a network, system, or device that is not working as designed. In contrast, a Service Request is a network, system, or device that is working as designed.
Priorities Further Define IT Service Request Characteristics
While the PSA/IMS** software is capable of dividing the work into either Incidents or Service Requests, we use a single data field to further define the characteristics of the requests.
You guessed it – Priorities. Since the work is divided at the top level between Incidents and Service Requests, it makes sense to discuss priorities for the two groups separately.
Last article, we discussed Incidents at length. In this article, we will take an in-depth look at Service Requests.
What Types of IT Service Requests are There?
Service Requests are further defined by the Priority field into:
- Scheduled Events (Sch Event)
- Change Requests
- Net Admin Other Recurring services (NA/Recurring)
- Projects (Project)
All Service Requests use the priority level of Scheduled Events (Sch Event) except the following, outlined in greater detail below.
IT Change Requests
A Change Request is a scheduled event by definition, because the network is working as designed, but the Customer or someone else wants a change to the network. This type of Scheduled Event usually requires a technical impact review and some level of authority approval.
In the world of enterprise IT Support, a global Change Request approval process may be enough. In the world of Managed Service Providers (MSPs), Customer dependent configurations for the Change Request approval process is required.
NA / Regularly Recurring Service Requests
Service Requests are scheduled on a regularly recurring basis using a Recurring Master ticket to schedule, such as:
- Network Administration visits
- Staff Augmentation
- Back-up checks
- Internal Support (i.e. Sales Engineering, Standard Build Documentation, Training windows, etc.)
IT Projects: 1 Word, 2 Meanings
Before we jump into talking about Projects as a type of Customer Request, let’s talk about how the jargon trips us up. Project is a single word with two distinct meanings.
First – Project is a mechanism for capturing time and tracking the work versus a Ticket. Here we are talking about modules or areas of the software in use.
When to use the project module depends on the complexity of the work:
- If the request has a single phase and a single Resource, then a Ticket is the more efficient time capturing vehicle to use.
- If the Project Request has multiple phases or multiple Resources, using the Project module is the best way to go.
- Note that the estimated hours is not a determining factor.
Rolling out 32 PC’s probably takes as much time as a Physical to Virtual migration. Rolling out 32 PC’s using the same image is not complicated enough to merit using the Project module.
Second – Project is how we are using it in this context – it is a type of Customer Request versus an Install. An Install looks like a project in that it has been sold, but has less hours.
Estimated Labor Hours Help Define What an IT Project Is
The deciding factor of what is a Project vs. what is an Install is the estimated number of hours.
The estimated hours threshold has several key characteristics:
1) Is a specific labor hour number established for the Company
2) Will be different for each company, depending on:
- Their project management capabilities
- Types of projects they are managing
- Is usually established somewhere in the range of 8 to 32 hours
3) Triggers a different sales process and one that includes:
- Management approvals before submitting proposals to the Customer
- Some level of Engineering or Technical review
*Note: this does not include incidents with estimated labor hours over the threshold; they are still incidents and should be addressed as such.
What’s your take on this?
Let me know if you disagree in the reply box, as I am always happy to discuss the confusion further.
Example Based on ITIL’s Urgency and Impact Matrix
|Based on ITIL’s Urgency and Impact matrix|
|Critical||Network, Server, Core Application is down|
|High||Latency, or other network degradation, key personnel/device|
|High – Back Up||Any and All backups|
|Medium||Single User with workaround|
|Low||Aux equipment with backup|
|Sch Event||Non-Incident (Non-Reactive, Non-Break/fix)|
|NA/Recurring||Network Administration or other Recurring visit scheduling|
|Projects||Uses the Sales Pipeline process|
For more about Stephen Buyze
For more information about MSP-Ignite Service Manager Peer Groups