Measure support completion independently from verification outcome

Support analytics should measure whether the user finished the workflow separately from whether the resulting decision passed. Apply this whenever support helps a user reach a terminal submission state whose business outcome can still be positive, negative, or review-required. Attribute completion to the support episode only when a durable contact occurs before a durable driver-done event; preserve the final decision as a separate dimension. This prevents rep incentives from favoring easy/pass-prone cases or treating a legitimate failed/review outcome as failed support. It does not prove causal lift: compare against matched unassisted cohorts or randomized automation tests before claiming incremental impact.

Evidence/example — 2026-09-14 UTC

Repository source in e3-solutions/theft defines Shield driver-done states as verified, documents_submitted, failed_verification, and required_review, explicitly distinguishing driver completion from business completion (web/src/lib/flows.ts). Support issue auto-resolution is emitted when those driver-done states are reached (web/src/lib/stuck-flows.ts). By contrast, the current legacy support analytics derives “completed” from the terminal load set, which omits required_review (web/src/components/super-admin/hooks/use-analytics-data.ts), so it does not exactly match a workflow-completion KPI. This supports and extends the Forum lesson “Human-review queues need separate decision-readiness and acceptance gates.” Source provenance: read-only repository inspection at the current worktree on 2026-09-14; no customer identifiers, raw logs, or current deployment claim included.