An article based on a resolved ticket should describe one symptom, verified environment, tested fix and confirmation result. Remove customer data and limit the instructions to cases where they demonstrably apply.
Choose a resolved, reproducible case
Start with a ticket whose cause, fix and outcome were verified. Closure alone does not establish success. If no customer confirmation or test exists, do not present it as verified instructions.
Choose one symptom. Do not combine different problems just because the same support team handled them. Readers need to recognise their case and compare environments.
Anonymise the input
Remove names, addresses, private document contents, account numbers, session identifiers and technical secrets. Inspect screenshots separately; they may expose information absent from the text.
Retain necessary technical facts: product, version, environment, symptom and triggering condition. If configuration identifies a customer, provide a safe description preserving the relevant cause. Do not publish the correspondence.
Use symptom–environment–fix
- Symptom: what readers see and when.
- Environment: product, version, system and relevant configuration.
- Match condition: how to establish applicability.
- Fix: steps verified for this case.
- Verification: the expected successful result.
- Scope and escalation: when to stop or contact support.
Distinguish a diagnostic step from a fix. Information collection is not a solution. For actions requiring data protection, refer to the product's verified procedure rather than inventing one.
Example article structure
This fictional case does not describe a Semly fault. In an example document application 2.4.0, an already open list omitted a new document after a confirmed permission change. Reloading the view restored the list; it did not change permissions.
Symptom: a new document is absent from an open view. Environment: version 2.4.0 and a session begun before the permission change. Match condition: the document is available in a newly opened view for the same account.
Example fix: save unsaved work, then reload according to application instructions. Verify that the document appears and opens with correct permission. If it is also missing from a new view, this case is unconfirmed and further diagnosis is needed.
Explain limits
A fix verified in one version may not address the same symptom everywhere. List only tested versions and configurations. Similar interfaces do not establish additional platform support.
Do not promise that refreshing fixes permissions or missing system data. Those are different causes with separate procedures. A clear match condition prevents repetition of irrelevant steps.
Test the text as a user
Ask a technical reviewer to reproduce the case safely and follow the instructions without the ticket. Check that all conditions and the successful result are explicit.
If additional information is needed, complete environment or match conditions. Instructions must not depend on knowledge available only to their author. Confirm the content before marking it ready for further editing.
Record verification and preserve translations
Retain verification date and owner. After a product change, recheck conditions and steps. A different cause and solution should not become an unrelated section of this article.
Translations preserve version, symptom, step order and success criterion. Match messages to the real interface. The result is one verifiable instruction for one recognisable case, not a general support-topic catalogue.
