Negative Maintenance: Why Support Should Grow Slower Than the Company

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

We handled that request thousands of times over several years. The work was easy. We could resolve the ticket quickly and the customer got what they needed. Then the setting became self-service. After that release, those tickets stopped.

Until the release, we had treated each request as an individual ticket. The product change removed the request entirely.

Serval calls this negative maintenance. Their principle is that a system should need less attention after you work on it. For support, I use the term for work that lowers future contact volume.

Contacts per customer

A growing company adds customers every quarter. If contacts per customer stay flat, support headcount has to follow customer growth. Lower the contact rate and the team can serve more customers without adding people at the same pace.

In a flat or mature business, fewer repeat contacts frees up time for other support work.

CSAT and time to resolution won’t show 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 the demand changed.

Three different outcomes

A macro or runbook makes the ticket faster for the support engineer. The customer still has to contact support.

A help article, clearer empty state, or in-product hint may keep the customer out of the queue. The task may still be confusing, but the customer can finish it without waiting for support.

A bug fix or product change removes the reason for the contact. The customer never needs the workaround or help article.

I would track these separately. They change handle time, contact volume, and the underlying product in different ways.

Bug fixes and product changes

A small bug can sometimes be fixed in the same pull request that closes the ticket. Giving technical support a path to submit those fixes makes this practical for issues that won’t win roadmap time.

When support can’t make the change, it can still send engineering a clean reproduction, the relevant data, and the likely cause. Engineering gets a specific problem to evaluate. A proposed fix makes it even easier.

Some categories need a product change. Support sees the same confusing workflow or manual request come back across customers, then has to get that pattern and its volume in front of somebody who can change the product.

The volume of beta-setting tickets was the useful signal. We could show that customers had needed the same manual action thousands of times.

Workarounds can hide the bug

Some support contacts are legitimate. A customer may need help with an account-specific decision or a configuration that can’t be made generic. A good help article may be the long-term answer.

For a known defect, I want the workaround linked to the bug and the tickets tagged in the same category. That keeps the volume visible even if a macro makes the reply faster or a help article keeps some customers out of the queue.

Otherwise product and engineering may stop seeing the problem while support keeps working around it.

Who has time to do this?

Preventive work is slower on the ticket in front of you. On a small team, it gets done between contacts. When the queue fills those gaps, it stops.

A manager has to assign the time. As a team grows, that may mean clear owners for documentation, support systems, escalations, or recurring product feedback.

None of those functions will lower contact volume if product never prioritizes the change or engineering never reviews the fix. The receiving team has to participate.

Adding another front-line support engineer helps with the current queue. Removing a recurring ticket category changes the future queue.

How I would measure it

I wouldn’t estimate an imaginary number of tickets “avoided.” I would tag the category, mark the date the fix shipped, and compare contact volume before and after. I would also watch contacts per customer while the customer count grew.

If a category went from a steady weekly pattern to zero after a release, the result would be clear. If it didn’t move, the change didn’t remove the cause.