At the very beginning of my career I worked at a software company that provided full support to it’s offerings. We had a helpdesk. The helpdesk was a physical desk where, if customers paid enough, they were guaranteed to get an actual human being to talk to about their problems with our software.
On the weekends, no one had to come into the office; we had a rotating pager. (For you young ‘uns, it was sort of like a text-messaging device that only did text, and only about twenty characters at a time, or a call back number. No, that is not a typo.)
About six months into the job, I was asked to take the pager for the weekend.
“Wait a minute!” I protested. “None of the 24/7 customers are my customers. I won’t know how to support them!”
“No problem!” said Sally, the helpdesk staffer who would be away at a Wedding that weekend. “I don’t expect anyone will call.”
But what if they do?
“No problem!” said Sally. “You just tell them that we are looking into the problem. Our contract doesn’t require twenty-four hour call resolution — just that we will respond immediately.”
What is going on here?
For those of you listening carefully, the helpdesk I described above might sound like no help at all.
It did, however, provide one tangible benefit: It allowed the customer to pass the onus, or burden of responsibility, for solving the problem to us, the solution provider.
Yes, I just wrote “solution provider” without a giggle. I know. It’s strange.
Anyway, picture yourself as a sysadmin, or, better yet, the director of IT Services at a small liberal arts college in new england. You don’t have a huge staff, most of your staff disappear for the weekend, and suddenly you get a call that a server is down. Well, technically, the server is up, but it isn’t serving; people can’t use the service.
Say it is a voice over IP server, and no one on campus can make a phone call. What are you going to do?
Yes, you could rustle up the operations staff, maybe the programmers, reboot the boxes, play with configuration settings, maybe try to troubleshoot the issue.
Or for a few dollars a day, you could make it someone else’s problem. Call the service provider, get an answer, send out an email (unless email is down), then go back to sleep.
The alternative is to hold the onus yourself until Monday morning at 8AM Eastern. Sounds pretty appealing, doesn’t it? Except that it creates an extra layer of bureaucracy without real benefit.
Oh yeah, there’s that.
Over the next couple of weeks, I’d like to talk about the help desk, or service desk, or whatever we call it, how it starts out with such noble intentions, why it so often seems to go wrong, and what to do about it.
I would like it if you’d join me. For that matter, leave a comment, or send me an email firstname.lastname@example.org, or send me a message on twitter @mheusser with your ideas.
The column doesn’t have a great number of opportunities to impact the world, but there are a few readers who are decision makers, and a few more who are policy makers. The way most service desks are implemented leaves plenty of room for improvement; let’s talk about it!