How SLA’s Carry the Payload of IT Service Delivery
If WFR’s are the Hemi, then SLA’s are a Jet Engine. Actually, SLA’s are more like the C-130J Super Hercules, carrying the volume of requests in its belly as it delivers its payload to the anticipated destination on time and on budget in military style. [su_note note_color="#fffe39" text_color="#0a0808"]Here is a link to Subscribe and Download a PDF of Recommended SLA Configurations based on expanded priorities[/su_note]After working intently on the Technician and Service Coordinator dashboards (see 9/6 & 9/13 articles), it occurred to me that it is the Service Level Management (SLA) that automates the dashboards and therefore, IT Service Delivery in general. The SLA module does all of this:
Drives the Ready to Be Resolved widgets for the Techs and the other widgets on their dashboard.
Propels the SLA due in X hours for Triage, Tech Engagement, and Completion.
Informs the Service Coordinator, out of all the open tickets, what is important and which ones they should pay attention to / help with.
It gives a heads up to everyone which Customers need a little more TLC.
Perhaps best of all, it is the easiest metric to track, understand and improve - both on an Operational and an Individual level.
In other words, it is the SLA that tells the Service Delivery Employees what to work on next, how to deliver a great Customer experience, what is important amongst all the noise, and most of all, who deserves a raise.
Techs: What to work on next…
Using the Next SLA Event Due prioritizes the Tech’s worklist so they know what to work on next. It does require a Non-Contract SLA so Tickets with Contracts and those without (unmanaged Customers and Out-of-Contract work for managed Customers) play nicely. It also takes setting an SLA for Incidents and Service Requests, so they can be mixed together into one widget. Projects and Recurring visits do not fit in the Ready to Be Resolved widget, mostly due to the lack of an SLA.
For projects, it is all negotiable - when to engage and when to have it completed by is totally controlled by the MSP and is different for every project. This then prevents using the SLA Super Hercules.
For Recurring Visits, the SLA module depends on the create date as the base of SLA clock calculations. The create date is months in advance and has nothing to do with when the Customer is expecting the engagement; therefore, it does not work to apply an SLA to recurring visits.
Also worth noting, the “Waiting …” status pauses the SLA clocks and the Next SLA Event Due Date goes blank because it is unknown. For these three types of Customer requests (Waiting, Project, and Recurring) another widget is needed. The two widgets needed are: Waiting, Sorted By Last Activity Date, and Service Calls Scheduled - which is where all project work and Recurring visits appear along with the scheduled Service Requests.
How to Deliver a GREAT Customer Experience:
The answer, my friend, is not blowing in the wind. Instead, it is right there in front of you - the SLA widgets. They show what is coming up on SLA Due (Triage < 1 hour, Tech Engagement < 2 hours, and Completion < 4 hours). If they’re monitored between task engagements (Periscope Up habit), they provide awareness of either meeting expectations or disappointing the Customer – the choice is yours. Most of what the SLA configurations do is in the background and off everyone’s radar - except the Service Coordinator, Service Manager, and Account Manager.
What Service Coordinators Should Focus on:
After the Triage widget/queue is empty, the most important set of tickets for the Service Coordinator to focus on are those coming up on the SLA due date. If the Tech Engagement SLA is due in less than two hours, the action steps are:
See who is assigned the ticket.
See what they are working on in front of the ticket in question.
Determine (without interrupting the assigned Tech) if they have a high probability of fully engaging on and staying with the request.
If not, identify who else may be in a better position to take on the request.
If no one is accessible, alert the Service Manager.
If no other options are available to the Company, update the Customer on the status and let them know when to expect Tech engagement.
Keep in mind, the Tech engagement SLA is a Customer-Facing metric and should be spelled out in the Managed Service Agreements. Even if it is for a non-Contract Customer, there is an unsigned “Best Effort” lack of understanding. If the Completion SLA is due in less than four hours, there is no need to see if the request can be reassigned. By then, (most likely) the Tech is deep in the engagement and needs to stay with it. These are the action steps you should use:
See who is assigned the ticket.
See what they are working on in front of the ticket in question.
Determine (without interrupting the assigned Tech) if they have a high probability of fully engaging on and staying with the request.
Alert the Service Manager.
If no other options are available to the Company, update the Customer on the status and let them know when to expect Completion.
Remember that Completion SLA is a non-Customer-Facing SLA. It is used as an internal metric and a KPI in the Continuous Improvement program.
Speaking of the “Best Effort” misunderstanding…
I say lack of understanding because to us, “Best Effort” means we will get to it when we get to it. But to the Customer, it means shortly after Contract SLA. That’s a big difference, and it’s easy to see how misunderstandings can happen. Using a non-Contract SLA at 4X Contract SLA is the best way to upsell a T&M Customer. If you inform a T&M Customer “Best Effort” means waiting up to 4 hours when a server is down before Tech engagement, then there is a high probability they will see the value of having a Managed Service Agreement.
The Service Manager’s Eye is on Performance:
While the Service Coordinator is focused on Ticket flow, the Service Manager is focused on performance. This involves both the operational performance of the Company and individual performance of the Techs. The SLA performance report is a key metric in making performance evaluations. The SLA performance report is an essential component in Journey Mapping the Customer Experience. For example, if you are missing the Triage SLA, the assigned Tech has less of a chance to meet the Tech Engagement and Completion SLA. If the Tech does not engage in time, it is hard to complete promptly. The action items here are:
Run the report and look at it on a monthly basis, at least.
Examine the details of the tickets that missed SLA and see if there is a common thread holding up the cradle to grave ticket-workflow process.
Inform the Support Team of the operational performance. Ask them what is going on, and what needs to be done to improve, especially in the areas missing SLA
Keep in mind “What is Measured is Improved” (while this quote is often attributed to Peter Drucker, research shows it was most likely started by William Thomson, Lord Kelvin, in case you were curious).
When looking at the details, you may discover that one Tech is missing SLA’s, or maybe one specific type of request is being missed. While this is an individual issue, it may not be performance - it could be management. This means the Tech needs some training, was maybe over scheduled or was disrupted so much that they couldn’t get their work done.
[su_note note_color="#923f39" text_color="#ffffff"]"Eighty-five percent of the reasons for failure are deficiencies in the systems and process rather than the employee. The role of management is to change the process rather than badgering individuals to do better." ~ W. Edwards Deming [/su_note]
What Good Account Managers Do:
A good Account Manager will meet with the Customer on a quarterly basis. The purpose of the meeting is threefold:
To ask the burning question, “Would you refer us? Why or why not?”
- Net Promoter Score.
To report on the Service Delivery performance and crosscheck with the Customer’s experience.
To map out IT improvements over the next 1-3 years.
As you can see, #2 relies heavily on the SLA performance. If it were me, I would also come knowing the MTTR** performance, just in case there is a delta in the perceived Customer experience.
** A Word of Caution:
Watch out for all those Wait Statuses! An SLA performance >95% across the board may hide the fact that the Mean Time To Resolve (MTTR), “the only metric the Customer cares about” Jeff Rumburg (Cite in Metric, Metric who has the Metric) can still be unreasonably long. However, the SLA performance is an easier report to run and understand. So, most MSP’s start using this report before developing the data for the MTTR report. The takeaway here: Don’t just stop on the accomplishment of a >95% SLA! Keep going and see what the Service Delivery performance is from the Customer’s perspective – MTTR. [su_note note_color="#fffe39" text_color="#0a0808"]Here is a link to Subscribe and Download a PDF of Recommended SLA Configurations based on expanded priorities. [/su_note]