Your product has a feature that lets users export data as CSV. The export button is in Settings > Data > Export, which is not where anyone would look. You haven't written a help article about it.

Every week, 8 customers submit tickets asking how to export their data. Your agent spends 3 minutes per ticket responding with the same instructions.

8 tickets × 3 minutes × $0.50/minute in agent cost = $12/week. That's $624/year.

Writing the help article takes 30 minutes. Updating the button location in the UI takes 2 hours.

The article alone would deflect 60% of those tickets (about 5 per week). Annual savings: $390. The UI fix would deflect the rest. Combined annual savings: $624.

The help article pays for itself in the first week. The UI fix pays for itself in the first month. And yet, neither has been done. Because nobody connected "8 tickets/week about CSV export" to a documentation and UX gap.

Documentation Debt Is Like Technical Debt

Technical debt compounds. You skip writing tests, and later bugs take 3x longer to fix because you can't catch regressions. You skip refactoring, and later features take 2x longer to build because the codebase is tangled.

Documentation debt works the same way. Every feature you ship without a help article generates support tickets that continue forever. They don't go away. Users don't suddenly figure it out. New users hit the same confusion every week, month after month, year after year.

A missing help article isn't a one-time oversight. It's a recurring cost. And like technical debt, it compounds: the more undocumented features you have, the harder it is to find anything in the documentation that does exist, and the more frustrated users become with your help center overall.

The Compounding Effect

Let's say you ship one feature per month without documentation. Each undocumented feature generates 5 tickets per week at $10/ticket.

Month 1: 1 undocumented feature × 5 tickets/week = $200/month Month 6: 6 features × 5 tickets/week = $1,200/month Month 12: 12 features × 5 tickets/week = $2,400/month

By the end of year one, you're spending $2,400/month ($28,800/year) on tickets that wouldn't exist if you'd written 12 help articles. Each article takes 30 to 60 minutes. Total documentation time: 6 to 12 hours. ROI: somewhere around 2,400x to 4,800x.

No marketing campaign, no product feature, no growth hack delivers a 2,400x return. Documentation does.

Why It Doesn't Get Done

Documentation isn't glamorous. Nobody gets promoted for writing help articles. Product teams ship features and move on. The support team deals with the fallout, but they're usually not the ones writing docs (they're too busy handling tickets).

The disconnect is organizational. The team that creates the documentation need (product/engineering) doesn't feel the pain. The team that feels the pain (support) doesn't control the documentation.

Fix this with ownership. Every feature launch should include a help article, written before launch, as part of the definition of "done." Not after launch. Not "when we get to it." Before the feature goes live.

Some teams assign this to a technical writer. Others have engineers write the first draft and support agents refine it for clarity. The method doesn't matter. What matters is that "shipped without documentation" is treated as a bug, not a trade-off.

What to Document First

If you have a documentation backlog (and you probably do), prioritize by ticket volume.

Export your last 90 days of tickets. Categorize by topic. Find the top 10 "how do I..." questions that don't have corresponding help articles.

Write those 10 articles. You'll eliminate 30 to 60% of those tickets within a month.

Then set up a system: every time a support agent answers the same question for the third time, it becomes a documentation request. Supp's classification makes this automatic. If the intent "how to export data" appears 15 times in a month and there's no help article linked to that intent, that's a documentation gap.

The Quality Problem

Bad documentation is worse than no documentation. If a user finds your help article, reads it, and still can't solve their problem, they're now more frustrated than if they'd just submitted a ticket immediately. They wasted 5 minutes reading something unhelpful.

Common documentation quality problems:

Outdated screenshots. The UI changed 6 months ago. The article still shows the old interface. The user can't find the button because it moved.

Missing steps. "Click Export in the Settings menu." But the user has to be on the Pro plan to see the Export option, and the article doesn't mention that. The user looks at their Settings menu, doesn't see Export, and submits a ticket: "Your article says there's an export button but I don't have one."

Jargon. "Configure your SMTP settings to enable transactional emails." Your user doesn't know what SMTP is. Now they have two questions instead of one.

The fix: have someone who isn't an engineer review every article. If they can follow the steps without prior knowledge, it's good. If they get stuck anywhere, revise.

The ROI of One Great Article

One well-written help article about a common support question (let's say "how to reset your password") that deflects 80% of related tickets:

Tickets per month: 40 Tickets deflected by article: 32 Cost per ticket: $10 Monthly savings: $320 Annual savings: $3,840 Time to write: 45 minutes Time to maintain: 15 minutes per quarter

Lifetime ROI (over 2 years, assuming nothing changes): $7,680 in savings from 45 minutes of work. That's $10,240 per hour of documentation time. Your most expensive engineer doesn't bill that rate.

And the article compounds. As your user base grows, ticket volume grows, but the article scales to any number of readers. The 45 minutes you spent writing it keeps paying off indefinitely.