Take responsibility

EDITOR’S NOTE: This month the name of this newsletter changes to “Security Strategies,” reflecting its strategic approach. Please note that the “from” address changes accordingly; we apologize for any inconvenience this may cause.

I’ve been teaching in universities since 1970. With that much practice, practically everything gets turned into an opportunity for helping students learn. Since I’ve been teaching technical support methodology since 1986, even wretched customer service can be useful for my students as an example of what not to do.

Today he I’d like to share one of these horrible customer-service experiences with you readers in the hope that it will (a) amuse you and (b) serve you in your own efforts to improve network support and security response team performance.

For the last month or so, as I drive to Norwich along the country roads near my home in Vermont, I’ve noticed an unusual collection of wires and electrical junction boxes hanging down several feet from a telephone pole at a nearby intersection in the middle of nowhere. I keep expecting to see a repair crew come back to finish what seems to be an interrupted job, but the wires just keep dangling alarmingly and looking ever more precarious.

Last week, I decided to try calling the local phone company using my cell phone. When I pressed 411 I heard a cheery message announcing, “Welcome to LocalCellCo Directory Assistance.” The robot on the other end said, “What listing are you looking for?” I said, “BigTelco.” The robot said, “That number is 456-7890 and will be dialed automatically; there will be a charge for this service.”

The phone rang and a lady answered. I began to explain the problem but she interrupted. “I’m sorry, sir; this is the BigDeliCo food store, not the BigTelco phone company.”

I called 611 on my cell phone and reached a charming child to whom I suggested that having a voice recognition system that fails to confirm the listing it intends to dial for the customer is not a good design for a directory lookup service. The child informed me that the directory assistance was run by – guess what? – BigTelco on a contract to LocalCellCo and that I would have to call BigTelco myself for any complaints.

After confirming this preposterous policy with her manager, I listened in astonishment as he informed me aggressively that it was not LocalCellCo’s problem if the directory service was poorly designed. Furthermore, he had no way of providing me with contact information for the right people at BigTelco. I suggested mildly that this policy didn’t make any business sense because the directory service clearly announced itself as a LocalCellCo service, not as a BigTelco service; customers would see all problems as LocalCellCo’s fault.

It all made no difference. I was the first person to complain. If I felt strongly about it I should call BigTelco. Other companies had similar policies. If it happened to him it wouldn’t bother him. Basically, in many ways, he explained politely that he didn’t care.

Pontius Pilate himself couldn’t have done a better job of washing his hands of a problem.

I just gave up and decided to turn the experience into a lesson.

The lesson for my students (and for your staff) is that when a customer has a technical problem or a security issue that looks _to them_ like it’s your fault, you have to take charge of getting that customer to the right person to fix the problem. It’s no good protesting and claiming that somebody else should be helping them; get on the phone, find the right person, and then make sure that the customer is in direct contact with someone who will take responsibility for following up on the problem.

So if the security team dispatcher gets the call about a tech support problem that should have been reported to the help desk, the security dispatcher should link the caller to the help desk dispatcher, not just blow the caller off with, “It’s not my problem – this is the wrong number to call.”

If it happens a lot, perhaps a better user-awareness program would be warranted. But keep serving those clients (and yes, I always refer to fellow employees as “clients”).

Only then can you get the soap and water out for your hands.

If you would like to look at my lecture notes on managing support functions, go here.