Support Procedures from Product Journeys

Support Procedures from Product Journeys turn verified recovery outcomes into maintained operational guidance. The procedure retains the Journey Version, declared state, exact evidence, authorized Review Decision, Rendition provenance, and Publication receipt behind its instructions.

The result is safer than assuming that a captured screen sequence remains valid for every role, plan, account condition, and release.

Define the support outcome

Write the consequence a support actor must establish. Examples include restoring delivery without duplicates, recovering access for the authorized owner, repairing a failed integration, or confirming that a product limitation is expected for the declared plan.

Separate the customer’s symptom from the diagnosis. The same symptom may come from product failure, state mismatch, missing target, unavailable infrastructure, policy restriction, or unsupported behavior.

Declare authority and state

The State Capsule identifies actor, role, account scope, plan, data, flags, locale, viewport, clock, dependencies, and permitted side effects. The procedure exposes only what the reader needs while the private evidence preserves reproducibility.

Record actions that require elevated authority. Do not turn an internal operator step into public customer guidance. Destructive or externally visible operations require explicit confirmation, cleanup, and escalation policy.

Execute representative branches

Test the normal recovery, one common state mismatch, and one failure or escalation boundary. Avoid a giant permutation matrix. Preserve which cells were selected, skipped, or unsupported and why.

At meaningful checkpoints retain:

• functional outcome evidence;
• state diagnostics;
• target resolution;
• relevant visual evidence;
• automated or manual accessibility evidence;
• network, console, privacy, and side-effect results;
• initial infrastructure failures and retry history.

Classify before writing

A support writer should not convert every failed Run into generic troubleshooting. Route product failures to the product owner, state mismatches to prerequisite or repair guidance, target failures to source repair, infrastructure exceptions to retry policy, and privacy/policy failures to quarantine or escalation.

Only write a reusable procedure when the action is supported, safe, and attributable. Preserve uncertainty instead of inventing a confident resolution.

Compile the procedure

An approved procedure Rendition should contain:

1. scope and intended audience;
2. observable symptom;
3. prerequisites and authority;
4. safe state checks;
5. ordered recovery actions;
6. success checkpoint;
7. rollback or cleanup;
8. escalation evidence and owner;
9. limitations and prohibited actions;
10. source Journey and revision information appropriate for the channel.

Writers can simplify language and add empathy without changing protected product semantics.

Protect private evidence

Use fictional or approved fixture data for public examples. Redact identifiers before creating outward Renditions. Do not publish storage state, tokens, account IDs, internal endpoints, customer messages, or screenshots copied from private cases.

A public Publication should reference sanitized approved output, not expose the underlying Run.

Review and publish

Product owners verify behavior, support owners verify operational usability, privacy/security owners verify exposure, and accessibility owners verify their subjects. The Decision identifies exact evidence and scope.

Deliver through the existing knowledge base or support system. Retain channel, stable URL, version identity, content hash, delivery status, and receipt. A queued job is not delivery proof.

Detect drift

When the Journey changes, evaluate prerequisites, authority, sequence, outcome, recovery, screenshots, accessible names, and side effects. Mark the procedure keep, refresh, merge, redirect, block, or retire. Update the public date only for a material change.

Track Journey ownership, version alignment, approved evidence, and Publication receipt separately with the Documentation Drift Calculator.

Example: failed invitation delivery

The symptom is “the recipient did not receive an invitation.” The procedure first confirms the authorized workspace and intended recipient without exposing private data. It checks whether the product created exactly one pending invitation, whether delivery was queued, and whether a policy or capacity limit applies.

If the invitation was never created, functional evidence points to product or state investigation. If it exists but delivery failed, the procedure follows the supported delivery diagnostic. If the actor is a member rather than an owner, the outcome is an authorization boundary, not an email problem. If the runner cannot reach the service, retain the infrastructure failure and retry under policy without changing the diagnosis.

The outward procedure explains safe customer-visible actions. The internal Rendition can include additional escalation evidence and owner references under restricted access.

Govern temporary workarounds

A workaround should identify scope, authority, risk, evidence, grant time, and expiry. When the product is remediated or the exception expires, reopen the procedure Review. Do not let a temporary manual action become permanent canonical guidance because it was copied between tickets.

Track which Publications contain the workaround so release or policy change can invalidate them together.

First procedure

Select one recurring issue whose supported resolution is reachable and reversible. Execute three representative branches. Classify all failures. Produce one internal and one sanitized outward procedure if their audiences require different detail. Complete Review and verify the served channel result.

At the next product change, confirm that the procedure receives an explicit consequence. That persistence establishes value; the existence of generated Markdown does not.

Read Product Journey Infrastructure for Support, Keep Help-Center Content Current, and the internal documentation refresh study.