Define the expected result first
An acceptance matrix begins with a scenario and the result you expect for each relevant record. Include a first purchase, missing feature, failed collection, plan change and departure. Write the expected result before the rehearsal so a surprising outcome is not retroactively described as intended. Mark untested cases unknown rather than borrowing confidence from another client or a similar feature.
Choose safe evidence
Prefer documented preview, synthetic local records or an appropriately authorized non-production environment. Do not trigger real charges, messages or account deletions just to complete a checklist. A presentation preview can prove wording and layout, while actual account state needs different evidence. Keep those categories separate, and avoid claiming that a passing mock demonstrates a successful live billing integration.
An original case row
For a fictional plan downgrade, the row might ask whether the effective date is correct, the removed feature is handled safely, the billing record matches and the client receives an accurate explanation. Each result has its own observation and owner. If access changed but billing is unclear, the case is partially resolved. It should not receive one global pass merely because the final screen loaded.
Use failures to narrow the launch
Investigate the smallest failed transition and keep unrelated working paths intact. A repeated uncertain write is not a test strategy; preserve the attempt and reconcile it. Launch only the scope whose required evidence is sufficient. Review the matrix after a material product or process change, but do not manufacture ongoing test traffic or transactions to make activity charts look healthy. The matrix is a control for client continuity, not a performance claim. Keep expected and observed results in separate columns. A mismatch is an investigation item, not a reason to edit the expected result after the fact merely to obtain a passing checklist.
Sources used for this page
These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.
- Subaccount feature permissions — Merchant documentation · help.gohighlevel.com · Merchant-controlled · checked 2026-09-27
- Custom SaaS cancellation flow — Merchant documentation · help.gohighlevel.com · Merchant-controlled · checked 2026-09-27
- Stripe subscription lifecycle — Merchant documentation · docs.stripe.com · Merchant-controlled · checked 2026-09-27