So, we talked you into expanding the list of priorities to account for the 11 different types of Customer requests we deal with, claiming that each needs a separate SOP or SLA.
The least we can do now is to discuss exactly what those 11 different workflows are that every Service Coordinator manages.
As it happens – NOT – every workflow has the same title as the Priority naming convention that we recommended.
The Workflow list is:
- Quick Hits
- Minor Service Req
- Major Service Req
- Recurring Schedules
Critical SOP and SLA
All hands-on deck for Critical requests is very disruptive. How disruptive? It depends…
It is 24 minutes per Tech per Incident, minus 24 minutes, Times the Standard Role Rate.
Want to find your number?
Simply calculate (# of Critical tickets over the last 12 months) X (# of Techs – 1) X (24/60) X (Standard Role Rate)
So, for a 6-person shop, with a Critical Incident per week across all Customers (yeah right, who has that kind of network stability) and a Standard Role rate of $150, the annual wasted profit is:
52 X 5 (6 Techs – 1 Tech) x .4 (24/60) x $150 = $15,600.00.
Trust me, this is a huge number and worth the time it takes to implement a Critical SOP.
SLA: Triage = 1 hour, Tech Engagement = 1-2 Hours, Resolve = 8 Business Hours
1. As soon as a critical request comes in, Instant Message the Pre-Positioned** Tech assigned to cover critical requests for the day (or half–day, as the case may be) with the following information:
- Customers name
- Brief description of the issue
- Customer contact person
2. Create a ticket in Autotask
From our experience, by the time the ticket is created, the Tech will already be engaging, and when the Critical Request notification goes out to the 360 Stakeholders, it will also inform them of who is already engaging.
No noise, no pushback, no disruption, no loss in profits. Life is good and the Customers are happy!
High, Medium, Standard, Quick Hits and Minor Service Requests:
These all have the same SOP, but different SLAs:
|High – Inc||1||4||12|
|Medium – Inc||1||8||16|
|Standard – Inc||1||12||24|
|Quick Hit – SR||1||4||8|
Dump it in the Support Queue and let the Techs worry about it. Not really, but this is the one SOP that changes very little.
Today we use widgets rather than queues because they work better and are more efficient. We also use the Status “Ready to Engage,” which communicates to the Techs that they can engage on the Customers Request at will. Well, not really. The Ready to Engage widget, which replaced the Support Queue, is sorted by “Next SLA Event Due Date.”
So, the SOP for these Priority Tickets is to review and assign the tickets in Triage and place them in the Support Queue. From there, the dashboard will sort them into the order they are to be Engaged on, Waiting…, Escalated, or Resolved.
It’s a pretty simple SOP when you think about it, and very similar to the one workflow we have been using since Fred and Barney worked the desk.
SLA: Triage = 1 hour, Tech Engagement = by 3 pm today, Completed = by Noon Tomorrow
SOP: This is a little-known workflow, but for the MSP providing daily or weekly backups, it is very handy.
This workflow is necessary because Backups are a high priority & there is a significant level of liability around not having a backup. However, the SLA is a totally different model than other workflows. If the backup fails, we are notified in the morning, but they are not scheduled to run until that night or next weekend.
So, while they have a high liability, we do not need to engage within 4 hours. But we do need them up and running before we go home that night.
Based on historical data, it takes less than 2 hours to adjust the schedules and fix the problem. This means we need to engage by 2 hours – before the end of the day, and it will be tomorrow morning before we know if they are fixed.
We’re Not Done Yet…Here’s What Comes Next
Major Service Requests, Installations, Projects, and Recurring Scheduled tickets all need to be scheduled. The aforementioned Workflows (Critical, High, Medium, Quick Hits, etc.) will all fit in the Ready to Engage widget or Queue.
However, the rest of the Workflows (Major Service Requests, Installations, Projects, etc.) have too many estimated Hours to just fit them in. Therefore, they need to be scheduled in the calendars and not just dumped into a queue.
Major Service Requests:
SLA: Triage = 1 hour, Tech Engagement = 1 week, Completion = 2 weeks
SOP: Not much to this one… Review the calendars for the Techs with the right skillset and/or relationship with the Customer. Find a time where they are available and there is aggregate availability across the whole team for the aforementioned Workflows (Priorities).
Pick up the phone and call the Customer to make sure the available time is OK with them and schedule the work. Almost always, this type of work has some sort of Customer engagement required. If not, schedule away without calling them, but in all cases, follow up with a Scheduling notification. A reminder would not be necessary as it should be scheduled within 5 business days.
Installations are unique in that it is a good idea to schedule planning time in advance of the engagement. They do not need a heavy project workflow lift, just some planning time. There is, however, some key information needed from Sales in order to schedule, including:
- Estimated Hours
- Estimated Parts Delivery
The scheduling pattern and skillset information is also needed before scheduling but in most cases, this is known by or available from within the Service Delivery Team.
SLA: Triage = 1 hour, Tech Engagement = 2 weeks**, Completion = 3 weeks
** Planning time = 1 week
SOP: Schedule the required hours minus the 1-2 hours of planning time which is scheduled a week in advance. Look over the calendars for the Techs with the right skillset and/or relationship with the Customer.
Find a time where they are available and there is aggregate availability across the whole team for the aforementioned Workflows (Priorities).
Pick up the phone and call the Customer to make sure the available time is OK with them and schedule the work. Almost always, this type of work has some sort of Customer engagement required.
If not, schedule away without calling them, but in all cases follow up with a Scheduling notification. A reminder will be necessary as it should be scheduled more than 5 business days out.
Now we just stepped into a whole different ballgame, and one that will take 5-6 articles or an eBook to explain.
SLA: Suffice it to say, the SLA is negotiable. This is the one type of Customer request where we control the start and completion of the requested work. The others have either a contractual promise or non-contract expectation.
Recurring Schedules are used in proactive maintenance programs, which may include:
- Network Administration visits
- Technology Audits
- QBR prep
- Daily RMM checks
- Backup Checks, etc.
SLA: It depends. If the Recurring Instances (Child Tickets) are scheduled, then no SLA applies. The calendars determine when the Tech is to engage.
If, however, the Recurring Instances are placed in a Recurring Tickets queue and then a Workflow Rule moves them to the Ready to Engage widget when the due date nears, then creating them with an On-Hold status may pause the SLA Clock (this is a theory that we have not yet tested) and they will play nicely with the rest of the tickets in the widget when released.
SOP: This is more complicated than it appears at first glance. It seems you could just pick up the phone, ask the Customer when they would like the recurring scheduling to be, and schedule away.
However, in our experience it is impossible to get two Customers to coordinate their recurring schedules for the benefit of them both (think about splitting portal to portal travel costs) let alone getting all the Managed Service Customers to cooperate. The solution is Recurring Schedules mapping, and that merits an article onto itself – stay tuned.
How do we know all this? We have been there. With 22+ years of Autotask Service Coordinator and Service Manager experience, we are the best in the business.
Enjoy the read…