You are not as good at Incident Management as you think you are! Forget about all those glamorous ITSM processes like Service Level Management and Configuration Management, just focus on the basics of good old fashioned Incident (and Request) Management and you’ll see your IT customer satisfaction scores increase dramatically. Read on to find out why.
We’ve been talking to end-user customers of IT departments for eight years now and we keep finding the same things satisfy and frustrate them. The feedback is largely consistent across organisations big and small, private and public, for-profit and not-for-profit. And the frustrations largely come down to poor or inconsistent incident management.
Typically, we find about 25% of end-user customers complain about one or more of these three things:
- IT are slow to respond to a request for help.
- Requests seem to disappear into black holes (no updates or ETAs).
- Tickets are closed without asking (without verifying the incident/request has been resolved/fulfilled).
How is it that these complaints are so common? As far back as 1989, ITIL v1 had guidelines on the Help Desk (including Incident Management) so surely we should have nailed this process by now. The answer seems to lie not in bad process design but in inconsistent execution. There’s just not enough consistency in the way incident management is executed over time and across individuals and teams.
For example, the Desktop team always acknowledges receipt of a ticket within 4 hours; the SAP team only acknowledges receipt when they’re about to start work on it. The Exchange team always lets customers know how long it will be before their issue will be resolved; the Network team only talk to customers if they need more information. Mary from the CRM team always calls a customer before closing the ticket; her colleague Bob only does it sometimes. Sound familiar?
To address the most common customer frustrations, you must get all your service delivery teams to become obsessive about doing three things consistently:
1. Always respond quickly
Once a ticket is in their queue, resolvers (whoever is assigned to help the customer with their incident or request) must contact the customer and tell them when they can expect their issue to be resolved or, at least, when the next contact will be. This must always be done within the target response times defined in your SLAs (e.g. Within 1 hour for Priority 2s, within 4 hours for Priority 3s). In the absence of priority-based targets, just pick a single target response time (e.g. within 4 hours) and stick to it.
2. Always meet your commitments
Having responded to a customer to set their expectations on when their issue will be resolved (or when they can expect to be contacted again), the resolver must always meet that commitment. If, for whatever reason, that commitment can’t be met, the resolver must contact the customer before the ‘deadline’ and make a new commitment. By ensuring that customers always know when the next step will occur, you will virtually eliminate the ‘black hole’ as a major source of frustration.
3. Always confirm resolution
Customers tell us that there is nothing more annoying than being told their issue is resolved when it isn’t. Resolvers must always verify with the customer before setting their ticket to a resolved status. Ideally this should be done via a telephone call. By speaking to the customer, the customer has a chance to ask if there’s something they can do to avoid a recurrence of the incident, the resolver gets to bask in a little gratitude and, most importantly, the resolver gets to immediately find out if the issue still exists.
So, if you’re serious about improving IT customer satisfaction, look no further than the execution of your incident and request processes. There’s a good chance that your processes are sound, but that people and teams are just not following them consistently.