Not every support failure is a content problem

The answer was not there, so we should write another article. I keep coming back to how much that diagnosis leaves out.

My concern is that one remedy gets applied to several different problems. A growing content base tells us little about whether we fixed the cause.

My proposal is to sort failed attempts to get help into five causes. These are working labels for deciding what to do next, rather than a validated classification.

It did not exist. There was no answer, or the answer was wrong, stale or contradicted by something newer.

This is where creating or correcting content can help. Sometimes the right fix is to update or remove an article rather than add one.

It could not be found. The answer existed but was not retrieved, perhaps because the customer's words and the article's wording did not meet.

It could not be done. Something had to change, eg a permission, a refund or a record. Or the agent needed information it could not access.

It should not have been asked. The interface, pricing page or policy caused a question that a different design could have prevented.

It was handled badly. The required content and tools were available, but the person or agent did not use them well.

Each cause points to a different intervention. Some of the people who can make those changes will sit outside support.

The retrieval case is where I would question the default remedy first. If the answer exists, why are we writing it again?

A second article can introduce competing versions and another maintenance job. It may also help if the original needs a separate audience or scope.

Test which case you have. A count of new articles will not settle whether retrieval improved.

The action case needs a different owner. A guide that tells someone to contact support may be the best available route today.

It should still leave a question for the team that owns the action. Could we let the customer or agent complete it safely without that contact?

Product-caused questions need the same attention. Treating them as permanent support volume is a choice, even when they arrive one ticket at a time.

I do not have a validated estimate for the share of contacts in each cause. I would use an organisation's own records to find out whether this split helps it choose work.

Start with a sample from a defined period. Assign a single primary cause, meaning the intervention most likely to have prevented the contact, and record other contributors separately.

Use that pass to estimate three things:

1. The mix of causes. This describes why people needed help, alongside the topics they contacted you about.
2. The addressable share. Find recurring problems where an available intervention is likely to save more work than it costs.
3. The ownership split. Identify which changes support can make and which require another team to act.

For my mind, the ownership split is the part most likely to change the conversation. It turns a support target into a set of decisions with named owners.

A rare question can still deserve an answer. Risk, access needs or the consequence of getting it wrong may justify work that never pays through volume.

Treat that as an explicit reason to act. Do not make every useful intervention pretend to be a contact-saving exercise.

The first pass needs records and people who understand the work. How long it takes depends on record quality and how much they disagree.

The content base argument starts with the same condition: diagnose before choosing the next investment. Funding content is a call to maintain useful answers, not a target for publishing more pages.

The companion piece on proactive help asks whether the same fixes can serve questions we initiate. Keep those contacts separate when measuring the result.

Where I might be wrong is in asking for a single primary cause. A confusing screen can send someone to poor instructions for a permission they cannot change.

That contact has several plausible fixes. Asking which would have prevented it requires judgement, and different reviewers may make different calls.

Recording contributors preserves some of that disagreement. It does not make the primary label an established fact.

There is also an evidence problem. Judging retrieval at the time requires the content and search results as they stood then.

Without those records, we can assess what is answerable today. That is useful, but it is a weaker claim about why the original contact happened.

If historical evidence is usually missing, I would recommend a present-day answerability review instead of claiming a reliable account of past causes.

Try this

Pull a hundred contacts at random from last quarter. Treat them as an initial sample, with too few cases to describe every uncommon problem.

Label each with a primary cause, then ask two other people to label the same contacts independently. Compare where you agreed and discuss where you did not.

Check agreement within each cause as well as overall. A common label can produce a reassuring total while the rarer distinctions remain unreliable.

Which disagreements would send the work to a different team?