Last time we took a stroll down memory lane at my first professional job. Along the way we discovered a reality of the service desk; that one of it’s most valuable functions can to change the responsibility for the fix.
In other words, while you may not be able to put a price on being able to sleep at night, because the software issue is being handled, any responsible attempt at financial modeling would – and that price would be substantial.
Adding value by breathing? The sure sounds like a job for the helpdesk, right?
We can do better.
…time passess …
The classic response to a immature helpdesk is to, well, “mature” it up. Add some process. Require customers to clearly articulate what it is they want. More than than that, but to create a single point of contact for any issue — if you want the status, call the helpdesk.
This isn’t a bad idea, and I don’t mean to make too light of it. Once companies implement a strategy like this, if the website goes down, or the ERP system goes down, or email, the database – if any mission critical system stops functioning, you have one number to call – and the incident manager only needs to keep on person in the loop. (More about incident managers later.)
Then I noticed something happening.
In the classic helpdesk scenario, the helpdesk simply acts as a router of calls. If the organization is large enough, this saves time — nobody is calling the sysadmins asking them to create a report in Crystal Reports.
On larger, more mature organizations, the helpdesk even handles routine operations — assignment of laptops, perhaps, or allow someone to reset their own password. The best techs get good at these sort of rare but routine questions, especially if you have a single source of hardware. Two months ago at a client site, my screen didn’t come on. One of the tech’s knew the magic bios upgrade trick, because it was a common problem on that model.
All these things are helpful, and they are useful. There is one common problem, though.
Say you have a problem; perhaps the printer says “paper jam.”
You call the helpdesk, and get a ticket number. You would like to lean back, secure that this is someone else’s problem, but you have deadlines to meet, and those deadlines won’t go away because the printer is jammed.
Meanwhile, something is happening to your ticket.
The helpdesk routed the ticket to 2nd tier IT support; the guys that actually walk around the buildings. But they don’t do printer support — that is outsourced to the printer vendor. So they call the printer vendor, who calls the manufacturer, who points out that the device is past it’s warrantee date, and needs to be supported by the company. Tech support doesn’t know what to do with it, so they bounce it to ops management, who puts the ticket at the sysAdmin desk, who reply “we aren’t tech support.”
To make management go away, the lead sysadmin moves the ticket to the Windows Server team. After all, it’s a windows printer issue, right?
You can see where this is going.
If you have a helpdesk of any kind, here’s an idea: Take a look at your tickets, no just for % calls outstanding after X days, but for calls that bounce between teams.
Stop looking at averages, and start looking at outliers – the crazy call that just can’t get resolved.
Do root cause analysis and corrective action on that, and your team can handle the middling stuff in it’s sleep.
Sadly, it will often be the political things, the things where no one wants to take responsibility, the issues that are thorny and painful. There’s probably more to talk about there.
At the same time, we still haven’t talked about the history of the call center — how it came about, and it’s implications on service.
More to come.