Ah, yes, the good ol’ days. A customer calls into the Service Desk, opens a ticket, the ticket gets classified and worked, potentially being resolved on the same call. When it couldn’t, it was worked within an agreed upon time-frame known as the dreaded SLA. Then came the ugly “convenience” methods: email and portal submissions. With them came questions that were not easily answered by some companies. How do we trust the customer to classify a ticket correctly? How do we identify the service from an email message?
Many companies choose not to address this concern and instead just auto-classify incoming emails and assume the customer is going to pick the correct portal classifications and accept any tickets that do not get classified as “abnormal”. But is this the best method? Do we willingly accept that these problems will occur? Sure, we can report on these and attempt to change our service catalog to meet the user’s needs (as should be the case with Continual Service Improvement), but why should we stop there?
Even now, companies are upgrading their Service Management procedures to include a triage process to ensure the ticket gets routed to the correct team for handling. Does this fit with ITIL compliance? Management is concerned that changes like these will lower their compliance level in a time where best practices, efficiency, and effectiveness are a business focus. However, that is not the case. ITIL Compliance and Triage processes are not at odds and can still lead to efficiency, effectiveness, and cost savings.
ITIL does not state that an SLA must be measured from the ticket opening to when it is resolved, it is inferred from the idea that the moment of submission starts the time in the customer’s mind. ITIL also does not state (or make any distinguishable difference for that matter) between SLA’s dependent on ticket source. It is from this that our triage process can be developed. Automatic routing of a ticket based on the classification has become a seemingly standard procedure, but this can be modified to be conditional on the source of the ticket. While the SLA should still start when the ticket is identified, a triage process can be included for tickets that may need it, whilst automatically routing those that do not.
The Service Desk can triage and assign tickets that need it and move on to other tickets quickly, and still stay within given SLA times. Given proper configuration, the amount of time from creation to proper triaging can also be reported on and reviewed with normal processes to determine a proper timeframe to allow triaging. If changes to SLA timeframes are needed, these can be classified as different SLA’s due to call source and negotiated with customers as normal.
Now, nobody wants to increase an SLA just to add triage time, because it might drive customers to call instead of using the portal or email. However, in the new culture, companies are also pushing to lower the priority of email tickets and raise the priority of portal tickets to encourage self-help. SLAs are already measured differently for some conditions, after all. Customer type, Service, and even Asset are being used to differentiate between SLAs, so why not use the source as well?
By taking advantage of a versatile combination of these in conjunction with Priority, we can accomplish all our goals and adapt to a triaging system. In addition, the time added to this process may very well reduce the errors in assignment which delay the resolution and actually bring your company closer to its SLA fulfillment goals. All while maintaining ITIL compliance (which isn’t “required” anyways). So please, get the best of both worlds. Don’t assume that you have to pick between ITIL compliance and a proper triage methodology.
Author: Tom Scheel