3 Powerful SLA Performance Reports to Amp Up Service Delivery
It’s great that MSPs are validating that Request Segmentations and SLA Automations are improving their Service Delivery Operations to the tune of $30K per year per Tech, and more. Also, they’re saying that Customers and Employees are enjoying the changes you’re implementing.
But…how long before you can actually quantify the results? That’s what you really want to know, right?
Consistency is Your Key to Achieving Results
The short answer is - you will see results in 30 days. It takes about 30 days of a good habit or process to generate enough data to move the meter. Or better stated, it takes 30 days to get beyond the bad habits, so they are no longer negatively impacting the reported trend.
While implementing the changes, a weekly view will show if things are heading in the right direction. That’s too short of a view to base strategic decisions on; after all, anyone can have one bad (or very good) week. As any good workout program will say, it is the consistency that brings appreciable results.
It has been about a month since we doubled down on dividing requests into 11 different workflows, followed by configuring the SLA Automation to manage the workflows.
So how are you doing? How would you know?
There are three key reports we recommend at this stage of the game:
Priority Distribution
Service Delivery Forecast
SLA Performance
Get Those Priorities In Order With Priority Distribution:
A Priority Distribution report will show if tickets are being triaged, or just passively flowing through the Service Delivery Operation. The bad habit of passively passing the ticket on to the queues and telling the Techs to deal with it is the reason Service Delivery is:
Holding back the company from growing
Causing chaos in the workplace
Disappointing Customers
Causing the Operation to underperform
When looking at the Priority Distribution report, there should be a double hump (as opposed to a single hump bell curve) around the Medium and Quick Hits priority.
This is caused by a majority of the Incidents being Medium priority and the majority of Service Requests being Quick Hits. Remember that the main focus is on 11 Workflows, and we use Priorities to represent them.
At the two ends of the curve, less than 10% of the requests should be Critical, and less than 10% should be projects. If more than 10% of the requests are Critical, either the networks are not as stable as they should be (reach out to us for a preventive maintenance program to shore up the networks) - or your criteria of Urgent and Impactful may be too low.
As far as projects are concerned, if there are more than 10% project tickets, then you are most likely overloading the Team. Keep in mind, 1 project ticket represents 32 times more work than the average incident ticket. This alone should indicate there are very few project tickets, but how do you know without dividing them into their own workflow and then tracking the Priority Distribution?
Service Delivery Forecast: (My Favorite Report)
When I was first asked to move the MSP I was working for from a Reactive house to a Proactive Service Delivery Operation (later characterized as a Zen environment), this was the first report written to get the job done. In our situation, Critical Tickets were disrupting every workflow, but especially the Projects.
I know MRR is the economic engine, but Projects remain king to an MSP - and anything that disrupts the ability of an MSP to deliver projects on-time and on-budget has got to go. Except of course the Critical request from our most important Managed Service Customers. Are you starting to get the picture here?
Normally when there is conflict, the lowly Tech gets the short end of the stick. They get called on the carpet for disappointing the Customer, knowing tomorrow will be no different; yet when it comes to the Level III Engineers, that’s a different story.
Everyone treats them with kid gloves - after all, they are the highest billable resource, right? Well, not really – a good Level II Engineer can run rings around them. Don’t believe me? Just ask, I am happy to share the data – even your own data if you’d like.
So here was my situation: When a Critical Request came in, we needed a Level III to engage and engage quickly, but they were fully scheduled on projects. To reduce the conflict, we wanted to pre-position a Project Engineer (yes this almost got me fired, and it would have if Profits didn’t save my butt; after all, there is still something more important to an MSP owner than a lowly resource planner).
We ran the Service Delivery Forecast report, figured out how many hours we needed a Sr. Engineer available for Break/Fix each day, pre-position scheduled them to be available, and the money rolled in.
Even better…there was far less noise, chaos, and disruptions. We had much happier Customers, Engineers, Technicians, Customer Service Representatives, Account Managers, chief cook and bottle washers (our President was a chef on the side with his own cooker on a 10’ trailer for Summer Picnics.)…you get the idea.
This started us on the road to developing the 11 Workflows and driving the Chaos out of the workplace. It all started with the Service Delivery Forecast report. The report provides how many hours each week (divide by 5 to get the daily workload demand) are needed to meet the expectations (demand) of each workflow.
Besides knowing the hours needed each day/week for specific workflows, the report also speaks to Skill Set staffing decisions.
For example,
Critical and Projects are normally staffed by Level III Engineers
High and Installations by Level II
Level I handles Medium through Major Service Requests
These are very general statements, but they match the Service Leadership Inc. staffing model recommendations.
sla performance by priority
SLA Performance Report: Insight into Missed Expectations
The Advanced SLA Performance report (see pic) provides markers where the Support Team has missed expectations. The Triage (First Response) column is an indication of the Customer request intake process. Our recommendation is to fix this area of the Service Delivery operation first.
This should make sense because if the Intake Process is not meeting SLA expectations, it makes it much harder for the Techs to engage on time. Once the Triage SLA is being met 95+% of the time, the Techs should be engaging as expected. This is the next column to focus on.
Work with the Techs to find out, after Triage is meeting their expectations, why the Techs are lagging behind. According to Demming, 90% of the time it is the process, not the Employees. From our experience, once the Triage and Tech Engagement SLAs are being met, the Complete (Resolve) SLA is also being met 95+% of the time.
Markers are great, but where is the information that is triggering them? That is in an SLA detail report, which is a supplemental report to the SLA performance report. When running the detail report, you will be prompted to select an SLA, Date Range, Column (Triage, Tech Engagement, Completed Note: delete the ones not applicable), and Workflow (Priority).
This will provide a list of Tickets that comprises of the missed SLA causing the marker to be displayed. By reviewing the list of tickets with the Team, you can collaborate on why the SLA was missed and what adjustments can be made to set the Team up for success.
Sometimes the solution is awareness of the importance of this group of tickets. Sometimes it is a process adjustment/improvement. And sometimes it is an unrealistic expectation and the SLA, or the Coding of Tickets into the Workflow needs to be adjusted. When this happens, be sure to explain to the Customer why the SLA or coding of tickets is being adjusted.
There are four mockups discussed in this article...
Click here to download our Ticket Distribution by Priority document
Click here to download our Service Delivery Forecast spreadsheet
Of course, this assumes the SLA Automation is configured. If it is not, but you would like it to be, for a little bit of "moola" you will be on the road to recovery from Service Delivery Issues. Enjoy the read…