SLA Ticket Management & Scheduling Objectives
Service Level Agreements and Scheduling Objectives, the third fundamental area of our series on the 9 essential areas of IT Service Support and Delivery, is the focus of this article. As previously mentioned, ITIL divides Priorities into two work groups: Incidents and Service Requests. SLA’s are to Incidents what Scheduling Objectives are to Service Requests.
The #1 Question Every IT MSP Should Ask
When it comes to scheduling Service Requests at your IT MSP, the key is to ask this question: “What is a reasonable expectation for the Customer to wait for engagement on Service Requests?”
Short Duration Scheduled Event:
Think about this: if the engagement time is short, say less than 4 hours, how long would a Customer be willing to wait for engagement? I mean, if it is a 15-minute quick hit to apply a Digi-Cert, are you willing to wait a week? Probably not. On the other side, if it is less than 4 hours of work, do you want to reserve a full 8-hour day? Well, maybe…it depends on how many service requests you expect the reserved resource to engage in during that time period.
Medium Duration Scheduled Event:
If the engagement is more than 4 hours but less than 8 hours, will a reserve of fewer than 4 hours in duration work? Probably not. It is not enough time to complete the service request. Moreover, how long is a reasonable wait for engagement? Would you expect someone to engage tomorrow if it is a full 8-hour engagement? Hopefully not, because most likely, parts won’t even be available.
Installs:
How about more than 8 hours, but not a project? Would you expect someone to engage and stay with it inside a week? That would be sweeeeeet; 2 weeks - that seems reasonable; 3 weeks is okay, but no more. Reaching 4 and 5 weeks out is just unacceptable.
Why Scheduling & Remediation are Like Doctor’s Visits
The process of scheduling Service Requests is very different from the process of remediation for Incidents. While both require getting the Customer request into the right skill level hands ASAP, the Customer’s expectation of time to engagement is completely different. In the case of Incidents, the Customer is in pain and would like an Emergency room type of experience. In the case of Service Requests, there is a reasonable unwritten time to engagement expectation. With Service Requests, there is also the expectation that they will be seeing their “family doctor” (AKA: their favorite Technician). Enabling the Customer to see the family doctor (scheduling their favorite Technician) during an Emergency room visit (Incident remediation) is a huge mistake, which will prevent the service provider from engaging on Cardiac Arrest patients (other Customers in priority level Critical pain). In other words - at the point of intake, separating Incidents from Service Requests is more than just setting the priority level. It also funnels the Customer request into different processes. Queues should be in place for Incidents where they can be sorted by Next SLA Event Due Date. Calendars are used for Service Requests where they can be scheduled based on the Scheduling Objective grid presented below.
Communication = Feeling the Love
Before moving on to the next fundamental area, a word about Customer communication is merited. According to HDI research, a whopping 80% of Customers leave an IT Managed Service Provider because they do not feel the love. Customer communication is key in having the Customer “feel the love.” The process is the same for Incidents and Service Requests. Here is a layout of how the communication process should typically go:
Acknowledge that the request has been received
Update the Customer once it has been assigned to a queue (Incidents or scheduled Service Requests)
Contact the Customer
before engagement
during the engagement
before disengagement, including next steps or completion status
4. Follow up to verify that the Customer’s request was completed satisfactorily and the Customer is happy with the experience As mentioned, when discussing priorities, SLA’s and Scheduling Objectives are guidelines, not rules. There may be many reasons when it’s in the best interest of the Service Provider, Customer, or all Customers to expedite service. Doing a favor occasionally is in the best interest of all stakeholders - but enabling any one Customer or Account Manager to continuously jump the line is definitely not in anyone’s best interest. Do you agree? Share your thoughts in the response section below!