Skip to content
Apply for pilot

Verification guide

Verify the customer outcome, not only the code change.

A merged pull request proves that code changed. A verified fix proves that the intended behavior reached the affected environment and addressed the original customer problem without unacceptable regression.

Apply for pilot Plan customer follow-up

Evidence stays connected to decisions, approvals, and outcomes.

Use multiple layers of verification

Different evidence answers different questions. Code review and automated tests support implementation correctness. Release records establish availability. A behavioral test confirms the original user path. Production telemetry looks for recurrence. Customer confirmation checks the real environment and expectations.

Not every problem requires every layer, but the choice should match risk. A copy correction may need a simple production check. A data-loss or authentication defect needs stronger regression, rollout, monitoring, and customer evidence.

  • Implementation: reviewed change and relevant automated tests.
  • Release: version, environment, rollout stage, and feature-flag state.
  • Behavior: original reproduction case now produces the expected result.
  • Operations: error, complaint, or failure pattern does not recur in the observation window.
  • Customer: affected user can complete the intended workflow or reports a remaining issue.

Define success before implementation begins

Use the original expected and actual behavior to write the verification case. Include environment, data setup, role, plan, version, and any condition necessary to reproduce the failure. Name the person responsible for the check and when it should run.

Define the observation window based on usage frequency. A daily workflow can show recurrence quickly, while a monthly export or renewal action needs a longer plan or a direct customer retest.

Confirm the change reached the affected path

A deployment event alone may not prove availability. Confirm the correct environment, tenant, region, app version, feature flag, data migration, permission, or cache state. Record partial rollout separately from general availability.

Then run the behavioral check against a safe representative case. When production testing is unsafe or impossible, document the substitute evidence and limitation. Keep access to customer data and environments within the approved scope.

Monitor recurrence and invite conflicting evidence

Watch the same support queues, errors, traces, reviews, or feedback sources that surfaced the problem. Compare equivalent time windows and account for changes in customer volume or instrumentation. A quiet source with a failed sync is not evidence of success.

Follow up with affected customers when appropriate. Ask whether they can complete the intended workflow, not whether they ‘like the fix.’ If a report persists, reopen the problem, attach the new evidence, and reassess whether the cluster contained multiple causes.

Continue withClose the feedback loop

Practical workflow

A risk-based product fix verification process

Preserve each result so the closure decision can be reviewed later.

  1. Restate the original failure

    Confirm the user, action, condition, expected behavior, actual behavior, affected environment, and representative source evidence.

  2. Choose verification layers

    Select implementation, release, behavioral, operational, and customer checks in proportion to severity and uncertainty.

  3. Confirm release availability

    Verify version, environment, rollout, feature flags, migrations, and any customer-specific conditions before testing.

  4. Run the behavioral check

    Execute the original case and relevant regressions. Record the result, artifacts, tester, time, and any limitation.

  5. Observe recurrence

    Monitor equivalent source and telemetry signals for a defined window while confirming that data collection remains healthy.

  6. Confirm with affected customers

    Send reviewed, contextual follow-up and record confirmation, no response, or evidence that the problem remains.

  7. Close or reopen with evidence

    Close when the required checks pass. Reopen when a check fails or new evidence conflicts with the original problem boundary.

Keep building the system

Workflow

Close the customer feedback loop

Carry verified release evidence into reviewed customer communication.

Read more Template

Customer defect evidence brief

Define verification criteria alongside the original problem evidence.

Read more Guide

Feedback-to-fix workflow

Place verification inside the complete operating cycle.

Read more

One evidence chain

Make the path from feedback to fix inspectable.

Bring customer reports, business impact, engineering context, approvals, releases, and follow-up into one operating record.

Apply for pilot View product requests