How to Start the Race to Optimization?
By Segmenting IT Service Delivery Requests!!!
Do you want to optimize your MSP’s Service Delivery, but don’t know where to begin?
The best place to start a Service Delivery Optimization program is by segmenting Customer requests into four workflows:
Incidents
Service Requests
Projects
Recurring Visits
The segmentation of these four key workflows will enable you to develop a more efficient system, which is the first step in your race to optimization.[su_box title="IT Service Delivery Roadmap " style="glass" box_color="#8e1721"]From our perspective, the most important IT Service Delivery metrics are always:- Resource Utilization- Service Level Agreements (SLA’s)- Mean Time to Resolve (MTTR)- Reactive Hours per Endpoint per Month (RHEM)For a glimpse at how you can leverage these four metrics, subscribe and download our IT Service Delivery Optimization Roadmap right here. [/su_box]
Ready, Set, GO! Start With Segmentation.
We start with segmentation for many different reasons, however, the ones listed below are the most important ones to know about…1. Not all requests are created equal. By segmenting them into separate workflows and sub-workflows, the best way to engage can be done without confusion and chaos (C&C). In turn, this helps to drive C&C out of the Service Delivery environment.A. Once all stakeholders internalize the segmented workflows, they are empowered to focus forward.B. A focus forward environment allows the Techs to move from one request to the other without lost time/profits between work orders.2. Service Level Agreement (SLA) expectations are different for each segment of Customer requests.A. Critical requests need immediate engagement.B. Incidentrequests (Break/Fix, reactive) have a contractual obligation for engagement.C. Service Requests normally do not have a contractual obligation, but still carry an unwritten, strong expectation within the Customer’s mind - based on the estimated work effort.D. Project Expectationsare controllable by the MSP. But without segmenting, knowing Project availability is impossible and therefore the ability to set expectations is unfeasible.E. Recurring Visits revolve around setting a promised schedule - and then not disrupting it.3. Automation can now be implemented.A. Once requests are segmented, and the SLA body assembled, Workflow rules become the engine driving IT Service Delivery optimization4. Efficiency can also be gained by a common language and understanding.A. What is being discussed at the moment, and more importantly, what is not being discussed. Ex: Are we talking about a Project or an Incident?B. Once the request segment is known, the SOP and SLA in play are understood
It’s All About Those Priorities...
When it comes to Request Segmentation, what are we talking about? What changes are there in the PSA software or Service Delivery processes?We are talking primarily about priorities. This is due to ITIL’s Urgency and Impact matrixes which define how Incidents are to be prioritized. It makes sense then that non-Incidents would be prioritized differently to segment them from Incidents. Another reason to use Priorities is because the PSA software recognizes this field in all configuration areas (i.e. WFRs, Reporting, Notification Fields, SLA configs, etc.).
In a Perfect World, There Would Be 4 Segments...
Incidents
Service Requests
Projects
Recurring Visits
Alas, it’s not a perfect world out there. ITIL has already introduced four Incident sub-priorities:
Critical
High
Medium
Low (We recommend Standard, as I would never want to tell a paying Customer they are a Low Priority)
Here’s the thing to know - not all Service Requests are created equal either. Here are the sub-segments of Service Requests:
Change Request and other Quick Hits
Minor Service Requests
Major Service Requests
Installations
Projects and Recurring visits seem to have enough commonality and other ways of sub-segmenting them that a sub-priority for Projects or Recurring Visits doesn’t seem necessary. The best way to set up the triggers needed to drive Employee understanding and Automation using the SLA engine is Priorities.
A Request Priority Schema That Works
In summary, here is a request priority schema that has worked well in my experience:
Critical
- Network, Server, Core Application is down
High
-Latency, or another network degradation, key personnel/device
High – Backup**
-Any and All backups – as they have a totally different remediation schedule, therefore, a different automation schema, driven by SLA, triggered by Priority
Medium
-Single User with workaround
Normal (or Standard)– I would never tell a Customer their request was a low priority
-Aux equipment with backup
Quick Hits
-Change Requests and other Service Requests that provide a great Customer experience if handled like Incidents
Minor Service Requests (less than 4 hours of engagement)
-Half-Day engagements for Simple Hardware Installs, License Renewals, Simple Application Download/Installs, Other Service Requests
Major Service Requests(less than 8 hours of engagement)
-Full-Day engagements for two PC’s, VM provisioning, etc.
Installations(8 hours - Project Threshold of engagement)
-Large installs, Several PC's, Larger Applications
Projects(any non-incident request with estimated labor over the established Project Threshold – typically 8-32 hours depending on the size of the operation)
-Customer requests are moved to the Sales pipeline for Statement of Work, Engineering Review, and Project Management
Recurring Visits
-Network Administration or other regularly scheduled Recurring Visits** Stay tuned: More info on this request priority schema will be discussed and defined when we talk about process improvement in our upcoming articles. If your IT MSP is serious about optimization, you don’t want to miss these...What do you think? This discussion is open to everybody, so feel free to disagree with what I’ve stated and share your own insights and examples with us. [su_box title="IT Service Delivery Roadmap " style="glass" box_color="#8e1721"]From our perspective, the most important IT Service Delivery metrics are always:- Resource Utilization- Service Level Agreements (SLA’s)- Mean Time to Resolve (MTTR)- Reactive Hours per Endpoint per Month (RHEM)