Uncharted Waters

May 10 2012   1:00PM GMT

Rethinking the service desk – III

Matt Heusser Matt Heusser Profile: Matt Heusser

After Part one and two in a series on the service desk, we’ve acknowledged that having a single source of coordination and responsibility is good, that having a group take responsibility is good, and that you can examine long-standing tickets for insight about what processes are not working.

Today I would like to talk about the elephant in the room.  To do that, we need to differentiate the helpdesk from the service desk

The helpdesk was about centralizing and routing communications, and that’s fine, as far as it goes.  The service desk idea involves taking the routine work, the repeatable work, and trying to fix it on the first call, eliminating the need to route.  This makes service desk theory is very similar to call center theory, which attempted to move repeatable work from high-skill, high-wage areas to low-skill, low-wage areas in order to reduce cost.

There was only one problem:  When companies did this, price went up.

And now we have something to talk about.

Failure Demand

Most call center workers know about traditional demand; it is that initial call when the customer has a problem.  Failure demand is a little different; it is the demand that only exists because the initial call failed to solve the problem — thus the customer has to call back.  First coined by British Professor John Seddon, you’ve probably experienced Failure Demand when you have to talk to a second, third, fourth or fifth person, after the first four call centers workers could not solve the problem and had to transfer you.  Or perhaps they promised the problem would be fixed and would show up in your monthly bill, and it did not, so you had to call back.

Seddon’s research is in public call centers in the United Kingdom, where they separated the front office from the back office, then moved the front office to Ireland to decrease cost.

Of course, the decreases were in transactional cost – the cost per call.  If you move the cost per call to twenty-five cents on the dollar, but failure demand generates five additional calls — well, costs go up.

Seddon’s research indicated that was exactly what was happening; that cost per transaction went up, but the volume of transactions rose so drastically that costs went up.  By separating the front office from the back office, the organization also increased the communication cost (and latency) to escalate a problem.

So let’s get this straight: Costs go up, quality of service goes down (the % of successful call resolution), and, in many cases, time-to-solution does up.

It’s lose-lose-lose.

Doing It Better

I’m not suggesting you boil the ocean here, but I have seen companies make some modest tweaks to their operations to create large improvements in performance.  One company I worked with created a production application support team that were high-skill, multi-disciplinary team.  Instead of taking someone off the street, they actually rotated someone from the windows server team, the unix server team, a windows programmer, a database progeammer, a promoted person from the helpdesk, etc. These folks staffed a team that was capable of digging in and debugging issues — with the expectation that you might transfer back after six months to do years, now capable of building solutions that require less phone calls, support or escalations.

They put the prod app team right next to the helpdesk, and designed the workspace so that anyone could swivel a chair and help each other.  Instead of trying to make a repeatable list of common problems that anyone could solve, management assumed that each person would have some deep expertise.  For now, they could solve problems as a team and, over time, cross-train by doing.

Another company I work with has the operational teams do their own support, with customers direct-dialing into the right team.  Every team has a rotating support role called the “batman.”  By keeping support in-house, the technical staff feels the pain of hard to support applications – and is rewarded for designing systems that are easier to support.  (This is not just my idea; teams at Amazon have been doing their own support for years.)

If you do have a repeatable list of common problems, one that is truly repeatable, why hire script-followers at all; instead, automate the task with tools.  One company I met this week, IPSoft, uses Artificial Intelligence to monitor and correct common server problems.  I’m not talking about magic here, but if you commonly experience database locks, where detecting the lock is, in theory, something you could write a monitor to find, and fixing the lock is repeatable, sure, the classic “front office” service desk might be able to resolve that on the first try — but that’s not what humans are for.  Humans are smart; they figure out the vague and undefined and narrow it down.

Leave the repeatable stuff to the machines.

 Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: