Choose a repeated task, gather its approved answer and edge cases, then prepare an article with prerequisites, steps, expected result, and recovery advice. Link it where readers encounter that task and assign an update owner.
In this guide
What could the finished tracking answer say?
The sample demonstrates answer structure and does not establish a dispatch promise. Review the original tickets for different customer states: waiting for dispatch, missing an email, or holding a link that has not updated. Split those into separate answers only when their next steps differ. Avoid putting account-specific information into a public help page.
| Help article part | Practice copy |
|---|---|
| Question | Where is my tracking link? |
| Direct answer | Check your dispatch message for the tracking link. Your order confirmation records the purchase; it is not the dispatch message. |
| If there is no dispatch message | Check your account's order status and contact support using the order reference if you need an update. |
| Policy check | Confirm the actual status names and contact route with the store before publishing. |
Build the page from a checked task
- Collect representative question variants, approved policy, and the product state needed to perform the task.
- Write a direct answer explaining whether the task can be completed and what the reader needs first.
- List the steps in the order a reader performs them, retaining meaningful labels and conditions from the current interface or process.
- Describe the expected result and a specific recovery path for common exceptions.
- Have an owner follow the draft in the relevant environment and record corrections before publication.
- Link the page from related support answers and product guides, then assign a review trigger such as a changed policy or interface.
Review whether someone can finish the task
Read the draft as a person who has the problem now. Every step should name what to look for, what to do, and how to know it worked when that is necessary. Replace vague directions to check settings with the actual verified context or a clear route to current product help.
Keep the internal test record outside the public prose. The article can present verified instructions and their scope without narrating your review machinery. Save the source pack and owner decision so the page can be updated when the underlying process changes.
Choose the question the page should own
A pile of tickets can contain several tasks under one label. Separate changing a delivery address from finding an order's tracking link, even if both are tagged shipping. Group the permitted questions by what the reader is trying to do and what stops them.
Check existing articles before creating a new URL. A missing example may belong in the current guide, while a separate task with different prerequisites can deserve its own page. Keep the article's intended audience and product/version scope explicit so a later editor can recognize overlap.
Draft a help article from these APPROVED MATERIALS: [sources + versions]. READER TASK AND PRODUCT SCOPE: [state] QUESTION VARIANTS: [permitted examples] PREREQUISITES AND EXCEPTIONS: [state] Return a direct answer, prerequisites, ordered steps, expected outcome, troubleshooting, and related links from the supplied list. Preserve conditions and identify any missing instruction that an owner must verify. Do not invent interface labels or claim to have tested the procedure. Include a separate owner verification checklist.
Close the loop with support and content planning
Give support staff the relevant page link and monitor the questions that still require clarification. Add a focused update when evidence reveals a missing step; do not create a new near-duplicate article for each wording variation.