Build a support and incident runbook before launch
Define intake, acknowledgement, privacy-safe diagnostics, status communication, recovery, and learning.
Create a usable contact route
A customer must be able to report a problem without exposing credentials or private project data. State whether the channel is public, what response target means, and which information must never be posted.
Collect the smallest diagnostic set
Release version, affected screen, broad platform, time, and reproducible steps are usually enough to begin. Do not collect raw project text, account secrets, complete browser identifiers, or backups by default.
Separate acknowledgement from resolution
A first response confirms ownership and the next update time; it is not a promise that the defect is fixed. Use a public status record for broad incidents and a private route for security reports.
Close with evidence
Record the cause, affected versions, recovery action, validation result, and prevention task. A rehearsed runbook is stronger than a document that no operator has ever used.
Release-ready checklist
- Contact limitations are visible
- Diagnostics exclude private content
- Response and resolution targets differ
- Security has a private route
- A drill has produced a recovery record
This guide is written for planning and verification. Store rules and legal requirements can change; verify official requirements before submission.