Not every support failure is a content problem

A customer couldn't get help. Better write another article.

I reckon that reflex creates a fair bit of unnecessary work. It treats every failure as a missing answer, then sends it to the content team.

There are five causes I'd look for:

• The answer didn't exist, or it was wrong. Write it, correct it or retire the rubbish.
• The answer existed but couldn't be found. Fix the route to it.
• Something needed doing. The customer needed a changed record, a refund or access the agent didn't have.
• The question shouldn't have been necessary. The product or policy caused the contact.
• The help was handled badly. The answer and tools were there, but the person or agent didn't use them properly.

Only the first calls for creating or correcting an answer. The others need different work, often from someone outside support.

If the answer exists but search misses it, writing it again gives you another page to maintain. It also gives the next search another version to choose from. I'd find out why the first one failed before adding a second.

A guide that ends with "contact support" is sometimes the only available answer. Fine. But keep the missing action on somebody's list, or today's workaround becomes a permanent job.

The same goes for a confusing screen. Support can keep explaining it forever. That doesn't make it a support problem.

This is why I want contacts counted by cause as well as topic. "Billing" tells us what the customer asked about. It doesn't tell us whether to fix the answer, the permissions or the bill.

The useful result is knowing what we can prevent and who has to do the work. A rare but serious failure still deserves fixing. Not everything has to pay for itself through fewer tickets.

There's a snag with the five causes: a contact can fit several. A bad screen sends someone to poor instructions for a setting they can't change.

For counting, I'd assign the primary cause to the change most likely to have prevented the contact. Record the others too. That is a working judgement, and reviewers will disagree.

There's another snag with old contacts. Without the content and search results from that time, we can't know what was findable then. We can only test what works today.

Keep that distinction. A present-day review is useful; pretending it explains the past isn't.

Start with a hundred contacts and get a few people to label them independently. Look at the disagreements, especially the ones that send the work to different teams.

Before commissioning more content, find out how much of the problem the content team can actually fix.