Most help centres have articles. Fewer have articles that resolve tickets. The difference shows in the inbox: the customer read the article on returns, could not tell whether it applied to a sale item, and wrote an email. Anyone who runs customer service for an online store or a service company writes or approves such articles every week, usually without a template. This article is the template, built on what the research on reading on screens and Swedish plain-language practice says works.
Why do help articles resolve so few tickets?
Because they are written from the company's side, about the product, while the customer is looking for an answer to their question. According to a Gartner survey from 2024 only 14 percent of customer service issues are fully resolved in self-service, and that includes many of the issues customers themselves describe as simple. The customer starts in the help centre, finds an article that almost answers, and makes contact anyway.
How people read on screens explains part of it. Nielsen Norman Group found in its classic study that 79 percent of test users always scanned a new page, and only 16 percent read word by word. The same study measured what helped: concise text improved usability by 58 percent, scannable layout by 47 percent and objective language by 27 percent, and all three together gave 124 percent. A help article that opens with two paragraphs of background before the answer is written for a reader who does not exist.
Which question does the article answer?
One, and it should be in the heading in the customer's words. "Can I exchange for another size instead of returning?" is an article. "Returns and exchanges" is a category, and an article with that heading forces the customer to read everything to find their part.
That has three consequences:
- The articles become more numerous and shorter. Ten questions about returns become ten articles, not one long one. That is good: the customer lands in the right place straight away, and a chatbot answering from the articles gets a clear answer to fetch instead of a paragraph from a long text.
- The heading is written the way the customer searches. Read the questions that actually arrive in the inbox and the chat, and use their words. How to find those questions systematically is covered in the article on knowledge gaps.
- The answer comes first. The first sentence after the heading is the answer, short and without caveats. The exceptions come afterwards.
How should the article be structured?
In a fixed order, so the customer and the chatbot find the same thing in the same place every time. The template has six parts, and not every article needs all six:
| Part | What it contains | Example for "Can I exchange for another size?" |
|---|---|---|
| Heading | The customer's question | Can I exchange for another size instead of returning? |
| Short answer | One or two sentences answering the question | Yes, within 30 days and free of charge. The exchange is done as a return plus a new order. |
| Steps | Numbered list of what the customer does, one step per line | 1. Register the return under My pages. 2. Place a new order for the right size. 3. Drop the parcel at the pickup point. |
| Exceptions | When the answer does not apply | Sale items cannot be exchanged. Underwear and swimwear cannot be returned if the packaging is opened. |
| Have at hand | What the customer needs to complete the steps | The order number and the email address from the order. |
| Contact us when | The situation where the article is not enough | If the item is damaged, or if more than 30 days have passed. |
The order is not random. Short answer first means the person who only scans gets the answer. Steps as a numbered list is the format that works when the customer is doing the thing with a phone in hand. Exceptions after the steps, not before, since they apply to a minority. And "contact us when" last, to steer the tickets that still need a person to the right channel with the right details. It is the same structure that makes an article easy to find for Google and AI assistants; what helps the customer helps the search engine.
What language should you write in?
Plain language: the most important thing first, short sentences, everyday words and addressing the reader as "you". That is not a matter of style but a proven method. The Institute for Language and Folklore, which is responsible for plain-language work in Sweden, sums up the advice like this: start with what matters most to the reader, write short and informative headings that summarise the content, avoid long and complicated sentences, and choose everyday words over technical terms.
For a help article that means in practice:
- Write "you" and "we". "You register the return under My pages" instead of "Returns are registered by the customer in the customer portal".
- One sentence, one thing. Two clauses joined by "and" are usually two sentences.
- Use the customer's words. The customer says "exchange", not "redelivery", and "cancel", not "withdraw from the contract". The technical term can go in brackets if it is needed.
- Be concrete. "Within 30 days of receiving the parcel" instead of "within the applicable return period".
- Remove the caveats. "Normally", "as a rule" and "usually" make the answer unusable. If something does not always apply, write the exception instead.
Google's guidance on helpful content points the same way: the text should give the reader enough to reach their goal, be written by someone who knows the subject and not exist to fill space. A help article written for the customer meets those requirements by itself.
What should you leave out of the article?
Everything that does not help the customer resolve that particular question: internal terms, sales copy, history and things only the agent needs to know. The most common mistake is to mix the customer's text with the team's. The agent needs to know that size exchanges are booked as "RB" in the order system and that exceptions are approved by the team lead; the customer does not. In a knowledge base with internal fields those notes sit on the same article but are shown only to the team, so the customer's text stays clean without splitting the knowledge.
Three more things that should go:
- Dates and campaigns that expire. "Free shipping in September" in an article about deliveries is wrong in October. Put time-limited terms in their own article with a best-before date, or write about the rule instead of the campaign.
- Apologies and explanations. "Due to high demand" belongs in a status notice, not in an article that should last a year.
- Several topics. When an article needs a subheading that is not a step, it is usually two articles.
How do you know the article works?
By having someone who does not know the answer resolve the ticket with only the article, and then following whether customers still get in touch about the same thing. The test is simple: ask a colleague outside customer service to exchange the size on a test order with the article as their only help. Where they stop, a step or a word is missing.
After publication there are three signals:
- Contacts after reading. Customers who read the article and still write in about the same question. Read what they ask; that is the missing sentence.
- Comments and ratings. Gartner recommends in its press release on AI in customer service that both customers and agents should be able to flag content that does not work, and that there should be an ongoing process to improve it. A "was this article helpful?" button with free text is enough to start.
- The chatbot's answers. Ask the bot the question and read what it answers from the article. If it gets it wrong, or adds something that is not there, the article is unclear on that point. The same text that is good for the customer is good for the bot, and an article with the answer first and the exceptions clearly stated is the one the bot can reproduce correctly.
What to do
- Choose five questions that arrive most often and have the same answer for every customer. Write them in the customer's words as headings.
- Fill in the template for each: short answer, steps, exceptions, have at hand, contact us when. Skip parts that are not needed.
- Read through against the plain-language rules: "you" address, short sentences, everyday words, no caveats, no internal terms.
- Have the subject owner review that the exceptions are correct, and a colleague outside the team test that the steps can be followed.
- Publish and connect: the article in the help centre, as source material for the chat and as a suggested reply in the inbox. In Supportifier it is one and the same article that is used in all three.
- Follow up after four weeks: contacts about the same question, flags and what the bot answers. Rewrite the sentence that is missing.
Common questions
How long should a help article be?
As short as the question allows. A question with one answer and three steps fits in under a hundred words, and that is usually the right length. If the article grows longer than one screen on a phone, check whether it answers more than one question. If it does, split it. Length should be driven by what the customer needs to complete the ticket, not by how thorough the article looks.
Do we need screenshots and images?
Only when a step is hard to describe in words, for example where a button sits in an app. A screenshot becomes wrong as soon as the interface changes, and a chatbot cannot reproduce it. Always write the steps in text first, so the article works without the image, and add the image as support where it is needed. Give the image descriptive alternative text.
How do we write for both the customer and the chatbot?
By writing for the customer. A chatbot answering from the help centre fetches the passage that best matches the question, so an article with the question in the heading, the answer in the first sentence and the exceptions clearly stated gives the bot the right material. What makes the bot uncertain is the same thing that confuses the customer: caveats, several topics in one text and answers that assume something not stated in the article.
Should we translate the articles into other languages?
Yes, if you have customers who write in another language, but translate the whole template and not just the short answer. The exceptions and "contact us when" are what most often gets lost in translation, and that is where the tickets arise. Have the subject owner review the translated version too, and keep the two versions linked so that a change in one shows up as a task for the other.
Sources
- Gartner Survey Finds Only 14% of Customer Service Issues Are Fully Resolved in Self-Service — Gartner, 2024
- How Users Read on the Web — Nielsen Norman Group, 1997
- Skriv klarspråk — Institute for Language and Folklore, read 2026
- Creating Helpful, Reliable, People-First Content — Google Search Central, read 2026
- Customer Service and Support Leaders Must Prioritize Blending Human Strengths with AI Intelligence in 2026 — Gartner, 2025
Rickard Collander
Martin Carlsson