How do I write a help article from support tickets?

If you have answered the same question five times, you have a help article waiting to be written. The raw material is already there, in the replies your team sent. The problem is that those replies do not agree. One suggests clearing the cache, another a reinstall, a third a setting that only exists in the new version.

Writing the article means choosing among them, and you should not do that by guessing. The prompt below builds the article from the tickets and labels every step by where it came from, so conflicts show up before a customer finds them.

What you need

• Three to ten tickets about the same problem, with your replies. Remove names, emails and order numbers first.
• The product name and version, if the fix depends on it.
• Anything your team has confirmed is the official answer.

The prompt

Paste this into a new chat, then paste the tickets.

You write one help article from the support tickets pasted below. Work only from the tickets. Never invent a step, a menu name, a setting or a version. Do not include any customer's name or personal data.

1. State the one problem the tickets share, in the words a customer would search for.
2. Say how much evidence there is: how many tickets, and how many different fixes were tried.
3. Write the article: a title, a short explanation of the symptom, numbered steps, and what to do if the steps do not work. Label each step with the tickets it came from (for example T1, T3).
4. List conflicts: steps that contradict each other, or steps that only one customer tried. Mark each as [DECIDE: ...] for me.
5. List what I must confirm before publishing.

TICKETS:
[paste here]

How to check the result

Read the statement of evidence first. If it says one ticket supports a fix, that is a thin basis for an article. Ask an engineer, or test the steps yourself.

Then walk the steps on a real account. Each menu name and button label must match your product. Assistants sometimes use the common name for a setting, not yours.

Resolve every conflict. Pick the step you can prove and remove the other, or write both with the condition that decides between them. Do not leave a [DECIDE: ...] in a published article.

Check the article for personal data. Search it for names, email addresses and order numbers.

Finally, give it to someone who has never seen the ticket and ask them to follow it. Where they hesitate, the article needs another line.

What good output looks like

This is an invented illustration of the shape. Problem: "My emails are not sending." Evidence: "Five tickets, two different fixes tried, one confirmed by the customer." Steps: "1. Open the sending settings (T1, T2). 2. Check the sender address matches the verified one (T2, T4)." Conflicts: "T3 suggests reinstalling. Only one customer tried it. [DECIDE: keep or drop]."

The title should be what a customer would type into a search box, not the name of your internal fix. "Why are my emails not sending?" beats "Sender verification troubleshooting".

After publishing, link the article in your replies to the next few tickets on the topic. If the same customers still write in, the article is missing something, and the new tickets tell you what. Put a date on the article and review it when the product changes.

Limits

• One customer's fix is not the official answer. The article is only as good as the tickets.
• It does not know your product. It cannot spot a step that changed in the latest release.
• It cannot test the steps.
• It does not publish anything.

Browse all skills in the catalog