IT Support Fixes Should Take Minutes, Not Days

ITIL® has its strengths, of course, but if there’s one thing it really, really sucks at, it is IT User Support. ITIL tells us we need a Servicedesk and lots and lots of queues and backlogs; and then pretty much stops dead right there with its so-called “best practice” guidance.

This has frequently led to slow support and rising costs, with IT support fixes taking days, when they should take minutes. Under ITIL’s paradoxical abandonment of the most important of all IT support services, second line productivity fell by 35% since 2006. Go ahead, Axelos and its army of licensed consultants – say “best practice” one more time. ITIL routinely and repeatedly preaches and fosters support service mediocrity.

There is a far better way. You can do this alongside ITIL, or in sites that make no use of that doctrine. Let me offer some elements of my alternative to ITIL’s inadequate guidance on IT Support.

1. Redirect non-urgent requests

Keep your first line free where possible to take enquiries where user productivity has been impeded. Anything non-urgent can come in by some store-and-forward channel such as Email or a forms-based customer request portal. But do not use these channels for genuine help requests, because that way they add to user downtime and thus corporate costs.

2. Maximise first-line on-the-spot fixes

Study your incoming help requests. Work out which of these could be fixed in no more than five minutes over the phone or by Instant Messaging; then ensure the skills to do this are as universal as possible across the first line heads. Note I said ‘skills’ not ‘knowledge’ – it’s all about speed at this stage, so forget ‘knowledge bases’. Teach your first liners using scripted steps, prompted by identified gaps in a Skills Matrix. Aim for a ‘Spot Rate’ of at least 65%.

3. ‘Hotdesk’ the longer first-line fixes

We need to keep the front line free to be able to take help requests, so we limit them to five minutes per encounter. But some fixes could be made remotely if they had the time. A limited portion of these longer fixes can be passed during the call (i.e. ‘hot’) to a Hotdesk that is not interrupted by phone calls, but can conduct remote fixes.

4. Manage the Second Line

Good grief, enough with this putting technicians ‘in charge’ of technicians, already. Any second line resolving department needs better than that, because it is the essence of IT support. It has a mission to restore user productivity and thus contribute to corporate fiscal success. A second line workgroup is a production line, a solutions factory, and it needs to be run as such. Anticipate the workload and allocate manpower to deal with it. Develop skillsets, to get rid of Single Points of Failure and maintain service continuity. Recognise the importance of productivity and use it as a measure of your throughput. And do not allow backlogs to build.

These are complex managerial functions. Don’t just leave all this to a lead technician and expect him to conceive of it independently; there are accredited qualifications for this stuff.

5. Ring-fence Resolver Resource

I’ve been measuring IT Support delivery for decades. I’m pretty certain that it takes on average between 23 and 37 minutes of actual technician activity to fix a typical user support enquiry, including everything from a three-minute reboot to a two-day esoteric reimaging. If your resolutions are taking longer than that, then you’re probably doing something else instead.

Anticipate how many user support enquiries are going to land with your group. Rotate your staff into a subgroup just to deal with that reactive workload. Give the subgroup members a target to resolve 10 enquiries per man per day and watch them achieve it.

6. Don’t keep other people’s backlogs

In IT Support, backlogs are always bad. They are demotivating mountains that will never be climbed. They are a universal licence to cherry-pick. They are a place where the lazy and under-trained can hide. They allow ineffective managers to claim they are overworked rather than look for a solution. Don’t have a support backlog. Instead, have a quick service, and when your staff complete their work as a result, reward them with projects, learning time, whatever floats their business-motivational boat. IT Support is an emergency service – there has to be slack resource.

Once an enquiry is resolved, get it off the resolver queue. “Can you just leave this one open in case it happens again?” NO – only have in your queue what you can actually move toward closure. “Leave it open until the Servicedesk has checked the user’s happy.” NO – you do a quality job, and the Servicedesk is not your policeman. “Leave it open until the user gets back to us.” NO – tell the user unilaterally you’ve resolved it and allow the ITSM system to automate closure.

Minutes, Not Days

IT support fixes should take minutes, not days. We’ve been taught to believe otherwise by committee-designed frameworks, by an obsession with queues and backlogs, by a reliance on service targets based on those for 1980s mainframes, and by our industry unwillingness to expect productivity. It has been time to change all that for way too long. Let’s get on with it for the sake of our users, for our staff’s work satisfaction, and perhaps to stave off the cloud and MSP companies who are steadily coming after our jobs.

Implementing this doesn’t take long. A few months, perhaps. If you need help with developing your IT Support beyond the mediocrity that ITIL seems to settle for, give me a call.

“ITIL® is a (registered) Trade Mark of AXELOS Limited. All rights reserved.” So that’s me told, then.