Product Journey Infrastructure for Support

Product Journey Infrastructure for Support connects support procedures to the product states, evidence, Decisions, and releases they explain. It helps support operations answer a hard question: does this recovery instruction still match the current product for the affected role, plan, locale, device, and account state?

The system does not replace case management, ticketing, or the help center. It maintains the product-truth layer underneath repeatable support guidance.

Support paths are real Product Journeys

Happy-path tests rarely cover the state customers bring to support. A support Journey may begin with:

• an expired invitation;
• insufficient permissions;
• a plan or capacity limit;
• partially completed setup;
• inconsistent synchronized data;
• an unavailable dependency;
• a stale browser session;
• an accessibility barrier;
• a failed delivery or webhook;
• a destructive action requiring safe recovery.

Treat the resolution as an observable outcome. “Tell the user to refresh” is not a maintained contract. “The authorized owner restores delivery, confirms the recipient receives one invitation, and no duplicate side effect occurs” is testable and reviewable.

Declare the state behind the procedure

Every procedure should identify the State Capsule that makes its steps valid: actor, role, account scope, plan, data prerequisites, flags, locale, timezone, theme, viewport, clock, dependencies, and permitted side effects.

The public procedure may present only the reader-relevant subset. The underlying evidence must preserve enough state to reproduce and verify the outcome without exposing secrets or customer data.

Separate symptom, diagnosis, and action

A reliable support procedure distinguishes:

1. Observed symptom: what the customer or operator can safely confirm.
2. State check: which role, account, plan, flag, or dependency determines the path.
3. Diagnosis: product defect, incorrect state, target mismatch, infrastructure failure, policy restriction, or expected behavior.
4. Authorized action: what the support actor may change.
5. Outcome checkpoint: how to prove recovery.
6. Escalation: which evidence and ownership transfer when recovery is not safe.

This prevents a procedure from recommending privileged or destructive actions outside its declared authority.

Generate from approved evidence

Run the support Journey against representative contexts. Retain functional results, visual checkpoints, relevant accessibility evidence, network or console policy outcomes, and state diagnostics. Complete Review before deriving a customer-facing procedure.

The supported Rendition can turn approved Observations into an ordered procedure, screenshot set, captioned clip, or troubleshooting branch. Support editors add empathy, prerequisite explanation, safety notes, escalation language, and channel-specific formatting.

Never publish raw private evidence. Redaction and publication policy must operate before delivery, and a receipt should identify the approved public version rather than the underlying sensitive Run artifact.

Keep procedures current after release

When a Journey Version changes, compare its definition, state, checkpoints, and outputs with the previous approved version. Mark dependent support Publications refresh-due only when the change can affect the procedure.

Examples:

• a control moved but its name and outcome remained stable: update visual guidance;
• a permission requirement changed: update prerequisites and branch logic;
• a recovery API changed: rerun functional and side-effect evidence;
• an accessible name changed: update instructions that refer to the control;
• a previously valid workaround became unsafe: block the old Publication;
• the product change did not affect the procedure: record a keep Decision instead of faking a refreshed date.

Measure support truth separately

Useful measures include:

• critical support Journeys with current outcome evidence;
• support procedures linked to current Journey Versions;
• procedures with current approved evidence;
• procedures with valid Publication receipts;
• unresolved state or policy failures;
• changes that correctly produced a keep Decision;
• cases where a stale procedure was discovered before customer use.

Avoid claiming deflection, handle-time, or resolution-rate improvement without connected first-party support data.

Review the procedure from three perspectives

Before publication, ask a product owner whether the procedure reaches the intended outcome, a support owner whether the diagnosis and escalation are usable, and a privacy/accessibility reviewer whether the outward instructions expose safe information and support the declared reader contexts. These are separate approvals when the subjects require different authority.

Retain unresolved disagreement as Review work. Do not merge a support workaround into canonical product behavior merely because it resolved one case. If the workaround relies on an unsupported state or privileged operation, label and constrain it or keep it internal.

Work with existing systems

Keep the support platform as the system of record for cases, customer identity, service levels, and agent communication. Keep the help center or knowledge base as the delivery channel. Keep product issue tracking in the engineering workflow.

Reshot links the reusable procedure to a versioned product outcome. A ticket can reference a Journey and Publication version without copying private customer evidence into public content.

First support Journey

Choose one recurring, bounded issue with a safe resolution. Define the intended recovery outcome and authorized actor. Declare two or three state variants that actually change the procedure. Execute the path, classify failures, and retain outcome evidence. Have support and product owners review the same evidence. Publish one sanitized procedure and retain its receipt.

On the next material product change, verify that the procedure becomes refresh-due, is explicitly kept, or is blocked for a reason. That persisted consequence—not the existence of a generated document—establishes the workflow.

Continue with Support Procedures from Product Journeys, Keep Help-Center Content Current, and Documentation Drift.