Slide 8 of 25 -- Scroll down for more text

They constantly say, and believe, that almost all calls involve the customer's equipment, the customer's inability to understand the product, or the special needs that the customer wants a custom solution for.

Rationalizations like this are cute. I learned a powerful lesson on the other side when I did an experiment with David Pels, then a software support manager at a time when I was a project manager of a product that yielded a lot of support calls.

I had a year to do maintenance updates and internationalization of a mass-market product that was already selling well. We looked over its support history - read every letter, every magazine review, looked over the tech support staff's "answer books" and various types of call classification data, the bug reports, a lot of data.

Rather than talking about dumb customers or blaming third party manufacturers, we asked whether a call could have been prevented by a cheap fix. A cheap fix was one that could be rolled into an ongoing engineering effort for less than 4 additional hours. It might be a simple code fix, or a change to the user manual, or adding a third party driver to the disk or changing the wording on the package.

We concluded that we could have prevented half of our calls with cheap fixes alone.

Over the year, we made a lot of these fixes, a few expensive ones, and added a few new bugs to go along with some new features. So we aren't fully comparing apples to apples. But the call costs did go down, per new buyer, by about half.

Making the cheap fixes had a big impact. Making the cheap fixes can save a company more in call costs than the entire cost of testing the product. But the paradigm of the moment is "internet time" - ship it now, broken, and let customers pick up the pieces later.