Get the basics right
The road to slashing your user complaints is to understand what those complaints are. The world is presently banging on about “data driven enterprises”, and IT problems are a dead easy area in which you can record the queries that come in and analyse the data over time. Yet there are so many IT teams who don’t keep data on the work they do to fix problems or improve systems. Show me three IT teams and I’ll put a fiver that at least one of them logs less than half of what they do – because many of their tasks are so trivial and quick that it’d take longer to log them than to fix the problem.
The problem here is that the quick tasks are often the common ones. “I can’t log in”. “My account is locked out”. “The internet is slow”. “I raised a ticket last week for X, can you give me an update?”.
Yes, you’ll occasionally have difficult things to answer, or a major system that keels over in an entertainingly unusual way. But most of the time, the users’ gripes will be basic. Make sure you record every query you get: it’ll enable you to examine the facts and react deterministically to what you know are the core problems.
First off, there’s no reason for the internet to be slow. Internet connectivity is ridiculously cheap, so buy more than enough to go around. I’ll sometimes put in a dedicated Internet connection just for web browsing, and leave the other apps (email, file transfer, web servers and the like) to fight over a separate link. Architecturally it’s trivial to achieve (just whack a proxy at the edge of the network and give it a different default route from the rest) and it makes performance more predictable.
Second, login problems generally come from people not being able to remember their passwords. And the cause for this is often that they need different passwords for different systems – unless they religiously keep them in unison (of course they don’t). In these days of convenient directory service integration, there really shouldn’t be a need to have loads of different passwords – and if you’re feeling adventurous you could consider doing away with them completely.
We think of two-factor authentication (which you should use if you’re putting all your authentication eggs in one Active Directory basket) as a password plus a one-time token of some kind, but it could equally be a token plus, say, a fingerprint or an iris scan. The technology’s getting better and better with regard to the security of these biometric mechanisms, and they’re somewhat harder than a password for the users to get wrong.
Keep them happy (but keep control)
Self-service is also a brilliant way to keep the users happy. If they can fix stuff themselves, not only does it mean they don’t have to hang on the phone to the service desk but it also means they can fix stuff outside normal hours. I’ve done my time in IT support, sitting in a restaurant on a Saturday evening with the Citrix client open on my phone while I reset the company lawyer’s password so he can get a contract finished.
My two favourite items to enable for self-service are password resets (and the associated account lockouts) and restorations from backups. For the latter you have to be mindful of how you control the users’ permissions (you can’t just let everyone have access to every file on the archive, for obvious confidentiality reasons), but again with today’s technology that’s a straightforward thing to achieve. Backup restorations are always up there in the league table of service desk calls, so why not give the users the ability to undo their inadvertent deletion cock-ups?
And remember, self-service isn’t just for fixing stuff: it’s for looking stuff up too. If you’re diligent about recording what your IT team does in response to user requests, you can let them check for themselves how you’re getting on with fixing the problems. Update tickets as you work on them and the users can see what’s going on without having to disturb you – and whenever they want, too.
Which brings us onto the final point of getting the basics right: communication. Providing users with mechanisms for finding stuff out for themselves, as with the ticket lookup idea I just mentioned, is the first step. But more important is the wider area of proactive communication, and there are three key areas that you must do if you’re to do communication properly.
First is proactive communication regarding maintenance and the like. If you’re planning work that will cause system interruption it’s crucial that you communicate with the business, and that when you do so you don’t portray the work as a done deal. Approach the key business areas and ask them whether they have any problem with you doing the work you’re proposing: while they won’t have a complete veto that lets them stop it entirely, you can at least work with them to avoid any dates and times that don’t work well for the business because of their priorities. And then communicate copiously in the run-up to the work – and also when it’s complete, as you must always close the loop. If it’s a complex exercise you may also communicate with a subset of the business during the work, to update them with how things are going.
Second is reactive communication when something’s broken. The only thing that hacks users off more than a big problem with a system is a big problem with a system that nobody’s telling them about. Keep the users informed and they can work around the problem – perhaps shift their focus to tasks that they don’t need that system for. Informing users is usually very simple (unless it’s the email server that’s fallen in a heap, of course) and the benefit is huge – not least because if you communicate actively and regularly they won’t be phoning you for updates.
Finally, don’t be frightened to communicate when you do something cool or exciting. You’ve upgraded the internet connection? Great, tell the users that you have, because it’ll show them that you’re constantly working to improve their experience and they’ll feel good. Self-congratulation is something we’re generally rubbish at because it doesn’t seem the right thing to do, but in fact it’s a crucial part of keeping your users happy.
Sitting there thinking you’ve just read a thousand words describing the blindingly obvious? Yes, you may well be right.
So why don’t more companies do it all?