Knowledge article draft from solved cases

Use a small, consistent set of resolved cases to produce a help-centre article your customers can follow without contacting support. This workflow is for support content owners who need a reviewable draft, not an unverified rewrite of ticket replies.

The result is one article draft with prerequisites, numbered customer steps, expected results, and a separate list of points that need product confirmation.

1. Select cases for one customer task

Choose a single, narrow job, such as changing an account email address or finding an invoice. Do not combine related but distinct jobs, such as resetting a password and restoring account access.

Collect five to ten resolved cases that meet all of these conditions:

• They describe the same customer goal.
• The final resolution is clear from the conversation or internal notes.
• The cases are recent enough to reflect the current product behaviour.
• At least two cases show the same successful route.
• You can remove personal data, account identifiers, payment details, and private staff notes before using the case text.

Create a working document with these fields for each case:

Field	Record
Customer goal	The task they were trying to complete
Starting state	What had to be true before they began
Actions taken	Each customer action, in order
Successful result	What confirmed completion
Exception	Anything that made the case unusual
Source reference	The internal case ID or link for your team

Do not treat the support agent's wording as product documentation. An agent may have offered a workaround, skipped a step, or used tools unavailable to customers.

2. Find the repeatable resolution path

Read the selected cases and mark the actions that occur in most successful resolutions. Separate them into three groups:

• Required steps, which every customer must take.
• Conditional steps, which apply only when a named condition is true.
• Agent-only actions, which customers cannot perform and which may need an escalation route instead.

Write one sentence that states the article's scope. For example: Use this article when you can sign in and need to update the email address on your account. This sentence prevents the draft from absorbing cases that only look similar.

List the failure conditions found in the cases. Examples include an unavailable setting, an error message, a pending status, or an account type with different permissions. These will become either troubleshooting guidance or product questions.

3. Prepare the drafting brief

Give the model a structured brief rather than a pasted bundle of case conversations. Use anonymised notes from your working document.

Include:

• The article title or customer task.
• The intended reader and their starting state.
• The supported product area or platform, if known.
• Required steps and conditional steps.
• Expected result after the final step.
• Known exceptions and error states.
• Statements that need product confirmation.
• Your preferred support tone and existing article conventions.

If your team uses the xAI API, check the current input and product guidance in the xAI documentation overview. Available behaviour and limits are version-dependent.

Use a prompt such as this:

Draft a customer-facing help-centre article from the brief below.

Use this structure:
1. Title
2. Short introduction stating when to use the article
3. Before you start, with prerequisites
4. Numbered steps, one customer action per step
5. Expected result
6. Troubleshooting, only for confirmed customer-visible conditions
7. Product confirmation needed, as a separate internal list

Do not invent menu names, timings, permissions, error messages, links, or policies. Where evidence is missing or cases disagree, write [Confirm with product] and explain what needs confirmation. Use plain British English.

Brief:
[paste anonymised structured notes]

Keep the requested product confirmation needed list in the draft while it is under review. Remove it only from the published customer-facing version.

4. Check the draft against the cases

Review every numbered step against the source notes. You are checking for evidence, not whether the prose sounds plausible.

A draft is wrong when it introduces a screen, button, prerequisite, result, or exception that the selected cases do not support. It is also wrong when it hides a condition that caused repeated contacts. For example, Select Save is unsafe if the cases only show that a support agent made the change, or if the button label was never confirmed.

Use this check table before sending the draft for product review:

If you see this	Treat it as	What to do
A step appears in most successful cases	Candidate customer instruction	Check the current interface or ask the product owner to confirm it
Cases use different routes	Possible conditional path	State the condition, or split into separate articles
An agent changed something internally	Escalation boundary	Do not present it as a customer step
A case has no clear resolution	Evidence gap	Exclude it from the main route and record the question

Check tone separately. Replace internal terms such as ticket, backend, entitlement, or manual adjustment unless the customer sees them in the product. Keep instructions direct: tell the reader what to select, enter, or check.

5. Hand over the review pack

Send the product reviewer and support owner four items:

1. The article draft.
2. The list of product confirmation questions.
3. The anonymised case pattern summary, including exceptions.
4. A proposed owner and review date for the published article.

Ask the product reviewer to confirm each marked gap in writing. Then update the article, remove internal references and the confirmation list, and run the final copy through your normal publishing checks. Test the steps in the customer environment where your team has permission to do so.

When the workflow does not work

Stop drafting if the cases do not show one repeatable route. Split the job into narrower customer tasks, collect clearer resolved cases, or route the question to the product owner. If the resolution depends on an internal action, publish a short article that explains the customer-visible check and the correct support contact route, rather than exposing an agent workaround.