ManagementSpeak: We’re transferring you to the help desk. We’d like you to mentor them in your free time between calls, so that they can solve problems better.
Translation: Is your resume up to date?
Thanks to this week’s anonymous contributor for mentoring us in the subtleties of problem-solving.
Month: December 2007
Another helpless desk
In the beginning was Deming.
Deming introduced measurement to industry in the 1950s. A statistician, he relied on sophisticated multivariate techniques. He encouraged those who didn’t understand sampling theory, analysis of variance and multiple regression to stay away and let the experts handle the data collection and math.
American industry ignored Deming and his theories — I can’t help but suspect America’s enduring cultural distrust of the intellectual — but Japan did not, turning itself from a defeated military power to a fierce economic superpower in the process.
As a culture we are nothing if not adaptable, and so “metrics” happened in (to?) America. Sadly, we aren’t so adaptable that we were willing to actually learn, for example, statistics.
Which might explain why most of the metrics stories I hear are horror stories, not successes.
I’ll be the first to admit to flaws in my sample. I’m sure it is non-stationary, biased, suffers from heteroskedasticity and perhaps the heartbreak of psoriasis as well. I’m nonetheless confident in this conclusion: Call centers are the most mis-measured function in business, and IT Service Desks are the most mis-measured type of call center. Which brings us to this week’s anonymously provided tale of woe:
At the Help Desk where I currently work, they like to measure First Call Resolve (FCR).
What I am finding out from longtime tech support people is they like to game the metrics. Here’s how it works:
First, the system defaults every call to Resolved whether it really is or not.
If a user never calls back to say “That didn’t fix it”, you get a freebie. If, on the other hand, the user does call back to say, “Yep, that fixed it,” and the tech on the line documents the call in the system notes, you just lost an FCR. Why? Because you weren’t the LAST person to talk to the user. Yep, the last person to talk to the user on a call gets the FCR. It’s as if the relief pitcher who comes in with two outs in the ninth, a five-run lead and the bases empty gets credit for the win.
So potentially someone else could make you look bad, just by creating the last entry in a call log. And after five days, a ticket goes from Resolved to Closed and there’s nothing you can do about it.
You always open a ticket on a new call, find out what the issue is, then decide if it’s your queue or not. If not, you transfer it. However, the queue you transfer to will never get an FCR on that call even if they solve it immediately. Why? Two people have talked to the user, that’s why.
Some tech guys get around that by opening up their own ticket and documenting it for an FCR, leaving your ticket out to hang. And that can ding YOU just as badly since it’s been presumed you abandoned it. If you get a call where no one handles it but they actually need to call outside of tech support to, say, Financial Ops, you document it but those calls are not counted as FCR. They are deducted from your score.
Strangely enough, some of us were talking about this the other day — about how to increase FCR legitimately. Some of them had researched suspicious FCR standings (which are posted for individuals) and found that some of the lumps were posting gratuitous FCR calls (in other words, fake calls). You could tell by the shortness of the ticket and the vague incorrect answers that were in the notes.
The best way to find the lumps? Not the FCR metrics — they’re worthless. Instead, just ask the other techs. Most tech people are fairly honest in appraising their fellow co-workers. It’s not that we don’t like them. It’s idiotic management playing games with our stats.
So, like the plaque says, “Be careful what you measure. You’ll get it.”
The culprit here is clear: Simplemindedness.
A Help Desk is neither simple nor solitary. It’s one part of a system that should: Work on what’s most important first; resolve incidents quickly; and prevent recurrences.
Assessing the system’s outputs isn’t all that challenging. Assessing the engineers and technicians who create the outputs is tougher.
They have to resolve what they can, properly refer what they can’t, accurately document their work, and escalate underlying systemic defects. That requires: Intelligence, judgment, technical skill, diligence, and collaboration. It’s a multivariate situation.
Just ask Deming.