Your support tickets are a list of missing docs
People who open a ticket usually tried your docs first. Read those tickets like an editor and they tell you which pages to write, retitle or fix.
Somewhere in your support inbox right now is a question your team has answered a dozen times before. Someone will answer it again today. They'll dig up last week's reply, change a line or two, and hit send. The customer gets unblocked, the ticket closes, and the answer goes back into an archive nobody else will ever read.
That ticket is worth more than it looks. It's a customer telling you, in their own words, which page they went looking for and couldn't find. Read enough of them and you stop guessing what to document next, because the list already exists. It's sitting in your helpdesk.
In brief
- Most people who open a ticket tried your website first. The ticket is a record of where your docs let them down.
- Ignore your ticket tags. Read the customer's first message and rewrite it as the question they were really asking.
- Every ticket fits one of four buckets: missing, unfindable, unclear, or not a docs problem at all.
- Your support team's best replies are first drafts. The repeated ones should become pages.
- Judge the result by counting tickets on a topic before and after, not by trusting a deflection dashboard.
People who write in have usually read the docs already
There's a comfortable story that tickets come from customers who couldn't be bothered to look. The research doesn't back it up.
When the Corporate Executive Board surveyed more than 75,000 customers for Harvard Business Review, they found that 57% of inbound calls came from people who had gone to the company's website first. More than a decade later, things haven't improved much. A Gartner survey of 5,728 customers found that only 14% of service issues were fully resolved through self-service. For issues the customers themselves described as "very simple", it was still only 36%. And 43% said they couldn't find content relevant to their problem.
So when a ticket lands, the safer assumption is that the customer searched, read something, and gave up. Their message is what's left of a failed search. That makes it the most honest feedback your documentation will ever get. Nobody writes a support ticket to be polite.
Every private answer gets paid for again
A good support reply is accurate, specific and written for exactly the right person. It's also invisible. The next customer with the same problem can't find it. Neither can Google, and neither can the AI assistant someone asks before they ever reach your site.
So you pay for that answer again, and then again. Gartner's 2019 poll of service leaders put live channels at an average of $8.01 per contact, against about 10 cents for self-service. Your own figures will differ, and if engineers are the ones answering your tickets, they'll be a lot higher. The gap is the point. An answer written once on a page costs almost nothing to serve. The same answer typed out by hand every week adds up fast.
We touched on this in why documentation matters more in 2026. This post is the practical half: how to turn a pile of tickets into a list of pages.
How to read your tickets like an editor
You don't need special software for this. A spreadsheet and an afternoon will do.
- Pull a real sample. Take the last month of tickets, or the last 150, whichever is larger. Include everywhere people ask for help, not just the helpdesk. For a developer product that usually means GitHub issues, your community Discord or Slack, and the questions your sales engineers field on calls.
- Ignore the tags. A busy agent picks a tag in the two seconds before closing a ticket. Tags tell you the product area ("Billing", "API", "Integrations"), and that's no help here. You want the customer's first message, before anyone replied.
- Rewrite each ticket as the real question. "Webhooks broken!!" becomes "Why does my webhook endpoint return a 401 after I turn on signature verification?" This step is slow, and it's the one that matters. The question you write down is often the heading of the page you need.
- Put each one in a bucket. There are only four, and they're covered below.
- Count, then rank. Start with frequency, then weight by pain. A question that takes an engineer forty minutes to answer matters more than one a canned reply handles in ten seconds.
Here's what a few rows might look like for an API product:
| What the customer wrote | The real question | Bucket |
|---|---|---|
| "Getting 429s since this morning??" | What are the rate limits on my plan, and how do I tell which one I hit? | Missing |
| "where do I find my secret key" | Where is the API keys page in the dashboard? | Unfindable |
| "Copied your Node example, it throws" | Why does the quickstart sample fail on the current SDK? | Unclear |
| "You charged us twice" | Why was I billed twice this month? | Not docs |
The four buckets, and what each one asks of you
Missing. Nothing on your site answers the question. The fix is to write the page. Use the customer's wording in the title and first heading rather than your internal name for the feature. People search with their own words, and so do the models answering on your behalf.
Unfindable. The page exists, but the customer never reached it. Maybe it's named after internal jargon, filed under a section nobody would think to open, or it doesn't match anything people actually type into search. Don't be surprised if this bucket is bigger than you expected. The fix is rarely a new page. It's a clearer title, a link from wherever people actually look, and the customer's phrasing worked into the page so search can match it.
This bucket deserves attention because it's cheap to fix. In the same HBR study, Travelocity cut calls by 5% just by improving the help section of its website: less jargon, a simpler layout, easier reading. The answers were already there. People just couldn't get to them.
Unclear. The customer found the right page, followed it, and it still didn't work. Maybe the code sample is stale, or a prerequisite is assumed and never stated, or the steps skip the one screen where everyone gets stuck. These tickets are valuable because the customer usually tells you exactly where they got lost. Fix the page, and run any code sample against the live product before you republish it.
Not a docs problem. Bugs, outages, billing disputes, one-off account issues. Be honest about these and pass them to whoever can fix them. Documentation can't cover for a broken feature. Still, a short known-issues page or a clear status page can head off the second and third ticket about the same incident.
Your support team already wrote the first draft
When a question comes up for the fifth time, someone on your support team has probably written a very good answer to it. It's clear, it's been tested on a real customer, and it's sitting in a closed ticket.
That reply is your first draft. It won't work as a page straight away. It'll have a greeting, some context that only applied to one account, and maybe a workaround you'd rather not publish. But the hard part, working out what the customer actually needed to hear, is already done.
There's a name for this approach. Knowledge-Centered Service, a method maintained by the Consortium for Service Innovation, is built around capturing knowledge while support work is happening instead of in a documentation push months later. Its guiding line is "just in time, not just in case." You write for the questions people are asking and stop polishing pages nobody reads.
A few habits make it stick:
- Give agents a one-click way to flag a ticket as "this should be a page". A tag or a saved reply is enough.
- If the same question gets answered twice in a month, it goes on the docs backlog. No meeting needed.
- Once the page is live, the reply becomes a link to it. The next customer gets the full answer, and your agent gets their time back.
- Every so often, look at which flagged topics still don't have a page. That list tells you whether the habit is actually working.
Your search box is a second inbox
Tickets are the loud signal. There's a quieter one in your docs analytics.
Searches that return zero results are questions someone asked and got nothing back for. Pages with lots of "No" votes on "Was this helpful?" are pages people found and didn't trust. Run the same sorting exercise on both. Zero-result searches mostly fall into missing or unfindable. Unhelpful votes are nearly always unclear.
More and more people also ask ChatGPT or Claude before they ever reach your site. Putting the questions from your tickets to an assistant is a quick way to see which answers are out there and which ones are being guessed at. We covered how to structure docs so assistants quote them correctly in an earlier post.
Count tickets instead of trusting the dashboard
"Deflection rate" is a slippery number. Plenty of helpdesk tools count a deflection whenever someone views an article and doesn't file a ticket in that session. That doesn't tell you the problem got solved. The person might have given up, sent an email instead, or asked a colleague.
The plain approach works better. For each topic you fixed, count the tickets about it before the page went live and after. If the rate limit questions drop sharply, the page is doing its job. If they don't, it's either still hard to find or still not answering the question, and you've found your next rewrite.
If you're growing quickly, compare tickets per thousand active customers rather than raw counts. A growing product generates more tickets even while its docs are getting better, and raw numbers will hide that.
Start with thirty tickets
None of this needs a strategy offsite. Open your helpdesk, export the last thirty tickets, and make a spreadsheet with three columns: what they wrote, what they meant, and which bucket it goes in. By the end of the afternoon you'll have a ranked list of pages to write, pages to retitle and pages to fix. And it'll be based on what customers actually asked, not on what anyone guessed they would.
If you'd rather hand the reading to someone else, turning real tickets into articles is exactly how we build a help centre. Or run your docs through the Docs Score first to see where the structural gaps are.
Want this done for your product?
One call to see what you have and what it is costing you. Or join the beta and let the agents keep your docs current.
