Negative Maintenance

A product I supported had a setting that never graduated from beta. Customers couldn’t turn it on themselves, so they had to ask support.

We handled that request thousands of times over several years. Each ticket was quick to resolve, and none of them made the next one less likely. Then the setting became self-service, and the tickets stopped. One product change ended the whole category.

Serval calls this negative maintenance: a system should need less attention after you work on it. For support, I use it to mean work that makes future tickets less likely, not just faster to close.

Contacts per customer

A growing company adds customers every quarter. If every hundred customers send ten tickets a month, doubling the customers doubles the tickets, and roughly doubles the team. Lower the contact rate and the team can grow slower than the company. In a flat or mature business, the time you win back goes to other work.

CSAT and time to resolution won’t show any of this. A fast reply to the beta-setting request didn’t stop the next customer from filing the same ticket. Contacts per customer shows whether demand actually changed.

Absorb or subtract

There are two things you can do about the cause of a ticket, and from inside the queue they look almost the same.

You can absorb it: make the ticket cheaper to handle. A macro or runbook makes the support engineer faster. A help article, a clearer empty state, or an in-product hint makes the customer faster, and keeps some of them out of the queue.

Or you can subtract it: remove the reason the ticket exists, with a bug fix or a product change.

Both close the ticket. Only subtraction makes the next one less likely. I’d track them separately, because they move different numbers: absorption moves handle time and deflection, subtraction moves contact volume.

How support subtracts

A small bug can sometimes be fixed in the same pull request that closes the ticket. Giving technical support a path to ship those fixes makes that practical for bugs that will never win roadmap time.

When support can’t make the change, it can still hand engineering a clean reproduction, the relevant data, and the likely cause. That turns a complaint into a decision, and a cheap one.

Some categories need a product change. Support is the only function that sees every customer hit the same problem, and can say exactly which problem and how often. For the beta setting, that count was the argument: customers had needed the same manual action thousands of times.

Absorption can hide the bug

Some tickets are legitimate. An account-specific decision will always need a person, and sometimes a good help article really is the long-term answer.

The trap is absorbing a defect as if it were one of those. A macro hides the problem from your teammates. A help article hides it from the next customer. A workaround hides it from everyone, including the engineer who could have fixed it. The queue gets quieter, and upstream, the product looks finished.

So for a known defect, I want the workaround linked to the bug and every ticket tagged in the same category. Make the customer whole, but keep the cause visible.

Someone has to own it

Preventive work is slower on the ticket in front of you. On a small team it happens between tickets, and when the queue fills those gaps, it stops. A manager has to assign the time, and as the team grows, name owners for documentation, tooling, escalations, and product feedback.

It also takes a partner. If product never prioritizes the change or engineering never reviews the fix, support goes back to absorbing.

Adding another front-line engineer helps with today’s queue. Removing a recurring ticket category changes every queue after it.

Measure the absence

Don’t estimate tickets “avoided.” Tag the category, note the date the fix shipped, and compare volume before and after. Watch contacts per customer while the customer count grows.

The best support work shows up as absence: the question that used to arrive every week and then stopped. You can’t point at a ticket that was never filed, but you can chart a category going to zero. That chart is how the next hour of preventive work gets funded.