Share via

Support is not Manufacturing: Part 2

  • Article

Ok, my arm is warm now. Time to start tossing some theory bombs out there, and hope none get picked off. They said Italians couldn’t quarterback, but look at Vinny Testaverde! (Err…no, don’t.)

The reason treating support processes like a manufacturing endeavor fails is because it doesn’t take into account the sheer mass of uncontrolled variables that go into fixing software, IMO. In an ideal world, you could have an unlimited number of truly gifted people performing every job function. In the real world, you have to balance the needs for customer service with technical savvy, troubleshooting with good communication, prompt response with cost, etc. People aren’t machines.

Taking a deterministic approach to creating your workflows means “sticking your head in the sand” to the variables out of your control, and overloading the system should a bottleneck occur. Example: If you require all cases go to your next tier of support at N days, but you neglect to factor that all of Europe takes August off, your small, specialized upper tier will be overloaded with issues from people who aren’t answering phones, (and when they do it will all be on the same day.)

Going in the opposite direction is fraught with peril as well. As anyone who has worked in a helpdesk or support environment knows (at least from the armchair quarterback standpoint), the only consistently effective way to improve the quality of support is to have more people available to handle your volume, many of whom are aces at what they do. As anyone who has been involved in managing a project like that knows, doing so is so expensive that you’d trash any profit your product might make. So the question is how to strike the right balance.

The problem is, I don’t think there’s a good answer, at least not in terms of traditional support. The real answer lies with software. I’ll go into that next.

Comments