Although it might sound counterintuitive, providing customers with a better service actually costs less than providing them with a poor one.
One of the most effective ways to do both is to reduce the number of times your customer actually needs to contact your Service Desk in the first place. They’re happy because everything’s working perfectly. You’re happy because you need less staff manning the phones.
So, what can you do to reduce call volumes and reduce customer care costs? Read on for six ideas…
Improve the quality of your changes and releases
There’s a statistic out in the wild that 80% of incidents are caused by changes. I doubt it’s accurate (and the original source remains elusive) but it’s not completely out of wack with common experience. Stopping change-related incidents, and preventing new problems from being introduced into the environment, makes a lot of sense. ITIL provides guidance in the form of Change & Release Management. And in the software world, practices such as continuous integration, automated test and automated deployment are becoming mainstream.
Even in the absence of good tools and processes, IT staff who have the right attitude to quality can make a massive difference here. Conversely, cowboys will always cause incidents in spite of your controls!
Address the causes of recurring incidents
Periodically reviewing your ticket history will help you identify the source of recurring incidents (“problems” in ITIL’s language). This should be justification enough for your team to make sure they are recording all incidents and requests and categorising them correctly!
If your tool or case history isn’t up to scratch, an alternative approach is to simply ask domain experts, “What can we do to reduce the number of incidents that come to your team?”. They know what recurring incidents their teams keep having to deal with. And they often have a good idea of what can be done to eliminate them.
And don’t forget that not all incidents have technical root causes. Sometimes they can be eliminated by improving a business process, providing customer training or sharing a knowledge article.
Prevent the recurrence of major incidents
After a major incident, always conduct a root cause analysis to understand what caused the incident and how it can be prevented from happening again. But don’t stop there – the important part is making sure that whatever actions were identified to stop the major incident from reoccurring are actually carried out. This sounds blindingly obvious. I’ve included it anyway because it seems that many IT teams stop at minuting their findings rather than actioning them (just like Post Implementation Reviews!).
Monitor for events
Monitoring tools are used to proactively monitor the environment and generate alerts that warn of looming problems, e.g. when disks start filling up or servers become overloaded. Ideally, these tools should be configured to generate an incident record when thresholds are breached and steps taken before service is impacted. The automatic creation of incident records means that there is a record of events that have required intervention. These records can be analysed as part of your proactive analysis to identify root causes. Just be careful that your monitoring system doesn’t create hundreds of tickets for the same warning (disk is nearly full, disk is nearly full, disk is nearly full…).
Proactively communicate with customers
A good Service Desk will proactively notify customers when there is an incident that might affect them, e.g. by a recorded message on the phone system, SMS notifications, messages on the self-service portal, or a handwritten notice on the broken printer. Proactively notifying customers of an incident will prevent multiple customers from reporting the same incident. While technically this does not reduce the number of incidents, it does reduce the overhead associated with managing all those extra calls.
Encouraging your customers to log their incidents via an online portal (rather than by telephone or email), provides you with an opportunity to ‘intercept’ the customer before a new ticket is created. Not only can you let the customer know if there’s a major incident underway that you’re already aware of, but you can also point them to knowledge articles that may enable them to help themselves without needing to wait for IT.
Automating the fulfilment of routine requests can also have a compelling cost-benefit. One university I was talking to found that almost 50% of their tickets were for password resets! A quick warning – make sure everyone is aligned here. I’ve come across more than one Service Desk Manager who was against automating routine requests because removing these quick and easy tickets from their queue made it harder for them to achieve their SLA targets.
Have I missed anything from the list? What has your experience been with reducing incident volumes?