Negative maintenance

Nobody wants to contact support just to do the thing they came to do. For one camera image setting we supported, customers had to contact us to turn it on or off. Even when the request was straightforward, it still needed a support ticket.

I put it on a list of settings customers should be able to change themselves and kept pushing for it. This toggle alone resulted in dozens of support cases every week.

Each request was manageable on its own. Collectively, we had made support part of the configuration process. A customer couldn’t finish changing a setting until someone on our team did their part.

The cost went beyond answering the ticket. Bulk changes involved scripts, checking which cameras would be affected, and making sure the intended change had happened. We could get better at that work and still leave the same dependency in place.

Engineering eventually built and shipped the customer-facing control.

Customers could now change the setting themselves on supported cameras. They no longer needed us to operate that control for them.

What I want to make less work

For support, I use negative maintenance to mean work that makes future tickets less likely, rather than only making them faster to close.

A macro can save time on a recurring request. A runbook can make a complicated change safer. Those are useful improvements, especially while customers still need help. But I also want to ask why the customer has to contact us in the first place.

For this setting, better instructions for support would have made us faster at being the middleman. Giving customers the control changed the workflow.

Other problems need a bug fix, clearer behavior in the product, or documentation that answers a question properly. A help article can be a good long-term answer. If it describes a workaround for a defect, though, I want the defect to stay visible.

I try to keep the workaround linked to the bug and the tickets in a consistent category. Otherwise we can become very efficient at handling something and lose track of how much work it still creates.

Making the case

Support sees a recurring problem one customer at a time. To get it changed, someone has to put those cases together and explain the common cause.

The volume helps, but so does describing what the customer is trying to do and why they can’t do it without us. For the camera setting, the request was understandable without a technical deep dive: customers needed a support ticket to change a configuration option.

Sometimes support can prepare a fix. Sometimes the work needs a product decision and an engineering team. Either way, someone has to keep following it after the customer in front of us has been helped.

That takes time a busy queue will happily consume. As a leader, I want to make room for it rather than assume it will happen between tickets.

Checking what changed

I’d measure the result by tagging the request category, noting when the change reached customers, and comparing what happens afterward. If the customer base is growing, contacts per customer is useful alongside the raw count.

Handle time tells me whether we made the request easier to resolve. Contact volume helps tell me whether fewer people needed help.

For that camera setting, the useful change was giving customers a control they could use next time. I want to make room for more work like that.