How to Write Help Articles That Reduce Tickets
Direct answer: A help article that reduces tickets answers the question in its first 60 words, uses the user’s error text as its title, and places the next step at the end. Format matters more than length in Document360.
Here’s the pattern I keep seeing. A team writes 300 articles, sets up a help center, and ticket volume doesn’t move. The articles are accurate. They’re also written in the order the feature works, not the order the customer fails.
Why do accurate articles still fail to reduce tickets?
Because customers arrive with an error, not a topic. Someone who sees “Payment method declined – code 402” searches that string. They don’t search “Billing overview” and read down to section four.
An article titled “Billing” that explains your invoice cycle is fine documentation and useless support. The article that stops the ticket is titled with the error and answers it immediately.
How should the first 60 words be written?
Answer, then context. Never context first.
- Sentence one: the direct answer. “A 402 decline means the bank refused the charge, usually because of a card limit, not an expired card.”
- Sentence two: what to do now. “Ask the customer to retry with a different card or call the number on the back.”
- Sentence three: the exception. “If it repeats on the same card, the issue is on the bank side.”
Everything after that is reference material. The customer who needs sentence one gets it without scrolling, and the AI assistant gets a clean chunk to quote.
What structure works against search and AI answers?
GEO and SEO want the same thing here: extractable blocks.
| Element | Rule | Why |
|---|---|---|
| Title | Contains the literal error or question | Match rate on search |
| First paragraph | Answer in under 60 words | AI citation and featured snippet |
| H2s | Phrased as questions | Matches conversational queries |
| Steps | Numbered, one action each | Scanning on mobile |
| Ending | What to do if it didn’t work | Prevents the follow-up ticket |
That last row is the one most teams skip. An article that solves 80% of cases and offers no path for the other 20% generates a ticket from every failure. Even a line like “If the error persists after two attempts, send us the transaction ID from Settings → Billing” changes the outcome.
How do you decide which articles to write?
Not from a feature inventory. From tickets.
- Pull the last 90 days of closed tickets.
- Cluster by the customer’s own words in the subject line, not by the tag your team applied.
- Rank clusters by count × average handling time. That’s the real cost.
- Write the top 15 first. Not the top 100.
In a 900-ticket sample I worked through, 15 clusters accounted for 61% of all volume. The team had already written articles for nine of those 15, but titled them by feature name, so nobody found them.
How do you measure whether an article works?
Document360’s analytics give you article views, search terms, and (on higher plans) feedback votes. The metric that actually predicts less support is harder: tickets per solved search.
Approximate it with a simple loop. Tag each new ticket with the article the customer was sent. In four weeks you’ll see which articles generate follow-up and which close the loop. Anything generating more than three follow-ups per 100 views needs a rewrite, and it’s almost always the ending.
What about the AI assistant — does it change the writing?
Yes, in one specific way. When the assistant answers from your articles, it quotes paragraphs, not pages. A paragraph that depends on the paragraph above it produces a confusing answer.
Fix: make every paragraph self-sufficient. Repeat the noun instead of using “it”, and keep error codes inside the paragraph rather than in a table four sections up. This reads slightly redundant to humans and works far better for extraction.
Where does this approach cost you?
Writing this way takes longer per article. The first sentence is the whole job, and you’ll rewrite it four times. Budget 60-90 minutes per article rather than 20.
It also makes internal documentation awkward. Reference docs for your own engineers are a different genre and shouldn’t be forced into question-form titles. Keep them in a separate category in Document360 and don’t apply these rules there.
What should you stop doing?
Stop writing “overview” articles. Nobody searches for an overview of a feature they’re already trying to use. If an overview is genuinely needed, make it a hub page with links to the six error-specific articles — that’s a navigation aid, not a help article.
Stop putting screenshots above the answer. A 400px image pushes the sentence below the fold on mobile, and most of your traffic is mobile.
Key Takeaways
- Answer in the first 60 words; context comes after.
- Title articles with the customer’s error text or literal question.
- Pick the top 15 ticket clusters, not the top 100 topics.
- Always end with a next step for the cases the article didn’t fix.
- Keep paragraphs self-contained so the AI assistant quotes them accurately.
