# Customer Success SOP: Evidence-backed escalation handoff Version: draft-1 / 2026-11-09. Department: Customer Success. Source: [Canonical SOP](https://dive.vladyslavpodoliako.com/sops/customer-success-escalation/) > Untested general-purpose draft. All procedure steps, quality checks, and acceptance tests are not run. These are proposed templates, not actual Belkins SOPs or hands-on test reports. No external actions, sends, model calls, or schedules are performed or configured. No action is preapproved. Separate reported symptoms, observed behavior, and hypotheses in a redacted escalation packet with an unsent response. ## Purpose Prepare a clear escalation packet from approved ticket evidence. This template cannot promise a resolution, issue a credit, grant access, change entitlement, or deliver a customer response. ## Ownership and trigger - Owner: Customer success owner. Named person: not assigned. - Approver: Customer success lead. Named person: not assigned. - Proposed trigger: A cleared ticket meets documented escalation criteria. Missing account identity or conflicting severity rules block the handoff. ## Approved inputs - Approved ticket reference, account identifier, run identifier, and minimal redacted evidence. - Known account entitlement with its source and date, or an explicit unknown value. - Approved support policy, severity criteria, permitted destination team, and escalation audience. - Named customer success owner/lead, approved processing environment, and handling rules for restricted logs. ## Proposed procedure (not run) 1. [ ] Not run: Verify processing permission, account match, and approved destination team. Stop on a mismatch or an audience outside the handling policy; ticket visibility alone does not authorize redistribution. 2. [ ] Not run: Separate customer-reported symptoms, documented reproduced behavior, and hypotheses. Build a timeline with time zones and source references. Do not describe reproduction as completed without supplied evidence. 3. [ ] Not run: Apply the documented severity criteria only to observed facts. Keep unknown impact and entitlement explicit; neither customer tone nor a plausible account history establishes either one. 4. [ ] Not run: Draft minimal safe reproduction instructions and list already attempted actions with evidence. Remove secrets and unnecessary personal information. A restricted log reference should remain private rather than be copied into the packet. 5. [ ] Not run: Draft the handoff with impact, evidence, hypotheses, reproduction instructions, owner request, and unanswered questions. Prepare any customer reply as unsent, without an invented refund, delivery date, or resolution promise. 6. [ ] Not run: Request lead review of destination, urgency, and wording. Leave the decision pending. Any later delivery or account change belongs to a separate authorized process with its own receipt and duplicate-prevention policy. ## Proposed outputs - Escalation draft and source-linked timeline separating reports, observations, and hypotheses. - Redacted reproduction instructions and evidence for previously attempted actions. - Unsent response, unknowns, and a specific owner request. - Empty reviewer disposition and delivery receipt fields; unknown entitlement remains unknown. ## Quality checks (not run) - [ ] Not run: Reported, reproduced, and hypothesized facts are distinct and source-linked. - [ ] Not run: Proposed severity is supported by the approved policy and known impact. - [ ] Not run: Secrets and unnecessary customer details are excluded from the handoff. - [ ] Not run: No invented entitlement, delivery date, refund, or resolution promise is included. ## Acceptance tests (not run) - [ ] Not run: Normal. Proposed fixture: Synthetic ticket, redacted log excerpt, and approved severity policy. Expected result: The draft contains the required escalation fields and distinguishes facts from hypotheses. - [ ] Not run: Unknown entitlement. Proposed fixture: A ticket with no supplied entitlement record. Expected result: The output requests verification; it does not grant access or infer a service level. - [ ] Not run: Secret in log. Proposed fixture: A synthetic log containing a decoy secret marker. Expected result: The export excludes the marker and flags the restricted source for owner review. - [ ] Not run: Duplicate trigger. Proposed fixture: The same synthetic ticket/run identifier presented twice. Expected result: A duplicate is flagged; no second handoff or customer send is authorized. ## Stop and recovery - Stop on identity mismatch, uncertain permission, sensitive data without an approved handling route, or conflicting severity criteria. - Keep the draft private and route the blocker to the customer success lead. Do not compensate for missing facts by making a customer promise. - Resume after the lead documents the resolution and rechecks the destination, minimal evidence, and current ticket state. ## Evidence record (empty) - Template version: draft-1 / 2026-11-09. Adapted version and run identifier: not recorded. - Run status: Not run. Fixture/source versions and approved environment: not recorded. - For each proposed step and check: actual result, evidence reference, reviewer, and observation date are not recorded. Expected results above are not observations. - Actual model/harness configuration, elapsed time, cost, retries, and corrections: not recorded. No model call is made here. - Human decision: pending. Approver identity, review date, and scope: not recorded. No response is not approval. - External execution: none performed by this template. Any separate execution approval, receipt, duplicate-prevention key, and recovery record: not recorded. - Keep any future evidence in its approved restricted location. Public packets must exclude credentials, raw customer records, and unnecessary personal information. ## Related planning reference [SOP library](https://dive.vladyslavpodoliako.com/sops/) | [Workflow planner preset](https://dive.vladyslavpodoliako.com/workflow-planner/?preset=customer-success-escalation) The planner preset is an editable starting specification, not an execution of this procedure. Its fields are starting values: replace its owner, approver, trigger, and inputs with this SOP's, and reconcile the rest before use.