I was setting up a support agreement with a client the other day and had an epiphany. I realized I want to set up a help desk about as much as I want to withdraw my RRSP money in 50-dollar bills and set it on fire inside my house.
In a very unscientific survey, I learned that help desks are hopeless in two ways. The two major complaints customers have of help desks are the long waits and the lack of ability of the analyst at the other end. The help desk workers don’t make a career of the job because, by the time the customers reach them on the phone, they are psychotic wrecks who don’t want help; they want revenge. Consequently, help desk workers quickly fall into a funk, become astonishingly cynical – who wouldn’t with some of the dumb questions they get – and decide that mucking out chicken coops is a better vocation.
When I worked with DOS-based software packages, we had an expression: “If all else fails, read the manual.” Now, if the manual fails, call the help desk but, in preparation, make sure you have your twenty-seven-digit customer number and have banged a three-inch nail through your hand.
As IT professionals, we have created products that require a help desk, which in many cases is the last in a long line of insults to the customer. Remember these people who paid money for your product likely started out with a manual, then turned to on-line help, Web-based help, and finally, the human at the help desk – all to be told that they need to upgrade their version of software.
So, what’s the alternative?
One big change is to hook the ongoing use of your product into your revenue stream. If the customer isn’t using it, you shouldn’t get paid. This is a tough one when you consider shrink-wrapped software where once the licence is sold and the intro service period is over, the financial motivation is gone. A pay-per-use system would mean that if the customer didn’t use the product, you wouldn’t get paid. If the customer liked the product and used it a lot, they would pay for it. If you only were paid on a usage basis, you might consider paying more attention to the customer.
The other change is to institute a proactive service module, where the help desk analysts are required to make a certain number of client follow-up calls to deliberately look for problems. It is astonishing how many customers, who have been given a contact number for a specific rep, don’t call. However, if the reps call the client and check in, they will suddenly hear, “By the way, I meant to ask you about something.” Most of the issues start out as knowledge problems, where the customer simply didn’t retain the fact that certain functions are accessed certain ways. Thus calling the customer before the problem becomes a crisis will prevent future long calls and encourage the customer to keep buying your product.
Proactive customer support doesn’t seem too improbable or left-of-centre. I suspect, if you could measure it accurately, you would find customer satisfaction higher and support costs less if you were proactive. Is it that we’re afraid to admit that we made a mistake? To admit that collectively we don’t know what we’re doing? A friend of mine said that, with the exception of Vancouver’s Lion’s Gate Bridge upgrade, engineers have been building bridges on time and for a reasonable cost for a long time. Why can’t we do the same with IT projects and products? Perhaps the answer is that people have been building bridges, cathedrals and other massive objects for millennia. Major software projects are only fifty years old. Perhaps we just need more practice. In the meantime, let’s assume the customer needs help and not a help desk.
Robert Ford is a Vancouver-based consultant who is glad he doesn’t commute over a bridge and is experimenting with proactive sales and technical support for a Web-based system. He can be reached at RobertFord@quokkasystems.com.
