Skip to main content

Zero support policy (the right way) 💬

I like to treat every support issue as bug. As an indication that there is something in my product, documentation, or process that is broken. Otherwise there wouldn’t have been a support issue in the first place.

I want to strive for the ideal product. A product that always works correctly. A product that is not possible to misunderstand or use incorrectly. A product that is completely intuitive, even to first-time users.

Is it an impossible goal? Sure. But aiming for it drives real improvement.

For every issue that come up, you dig for the root cause and address it.1 You fix the bug. You adjust the UI to be more intuitive. You make the documentation clearer. Whatever it takes, you do it. The only thing you do not, is blaming the error on the user or external circumstances.

It is not easy. It will require ingenuity, to recreate the scenario which caused the bug. It will require tenacity, to keep digging when it would be easier to give up. It will require empathy, to see the product from the user’s perspective. (Especially when the user is “obviously stupid” and “uses your product wrong”!) It will require humility, to accept that the product you designed is not actually perfect.

If you follow the idea that every support issue is a bug to be fixed, the product will become better. And as it becomes better, it will generate less new support. That means both happier users and more time for you to improve the product even further. And it means a happier you. Because isn’t finding the root cause of a problem and fixing it for good better than just doing the least you can to get rid of the support case?

What do you think?


  1. A related idea is that a bug should only be found by a human once↩︎