Posted by: Matt Heusser
call center, Helpdesk, IT, Service Desk
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.
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.
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.