v1 Published snapshot
Resolve a Customer Escalation
Use when a CS or FDE owner must coordinate a serious customer-visible issue across internal teams, restore confidence, and verify resolution. Covers the customer-facing escalation from intake through closure; the incident commander or engineering owner retains technical response authority. Do not use as a substitute for on-call incident procedures or security breach response policy.
Starting inputs
- issue *
Observed issue, impact or escalation trigger.
string
- urgency
Optional severity/customer timing in their own terminology.
string
- customer *
Affected customer or account.
string
- evidence
Support ticket, incident, contract, impact examples or communication sources.
array
Steps
- 1
Triage scope, severity, ownership and safety
Collect exact customer symptoms, occurrence window, affected users/workflows, reproduction examples, contractual commitments, known mitigations and business impact. Separate user reports, system observations and speculation. Determine if production incident, security, privacy or regulatory procedures supersede this playbook and activate the correct authorized response owner. Establish customer-facing owner and engineering escalation path; do not self-assign incident-command powers. Gate: severity and response ownership are explicit, or an immediate safety escalation is initiated.
- 2
Create one coherent technical and customer evidence trail
Review ticket history, system evidence and prior commitments with permitted access. Construct a timestamped event sequence covering changes, observed failures, mitigations and customer communications. Work with engineering/support to identify the most plausible fault boundary and tests that discriminate causes. Avoid overclaiming root cause before confirmation. Preserve sensitive logs securely and disclose only approved information to the customer. Gate: internal responders work from an accurate shared problem statement and can test the leading hypotheses.
- 3
Coordinate response and set truthful expectations
Compare viable mitigations, temporary workarounds, permanent fixes and no-action risks, including customer effort. Agree who can approve each action, response cadence and the next evidence checkpoint. Draft a customer update containing acknowledged impact, current verified status, workaround if safe, and next update timing; do not promise an unapproved fix time. Escalate blocked decisions to the actual owner. Gate: the customer has an accurate update ready and internal owners have testable response actions.
- 4
Validate the fix in the customer's workflow
Obtain evidence for technical fix and customer-observed restoration; compare against the original failure example and regression criteria. Distinguish fix developed, deployed, technically verified and customer-confirmed. If the issue persists, update diagnosis and communication rather than declaring success. Actions affecting external systems and outbound communication require the applicable permission. Gate: the original customer impact is demonstrably resolved or explicitly remains open with a bounded mitigation.
- 5
Close with a proportionate account of cause and prevention
Prepare a short closure note describing impact, verified timeline, confirmed cause where known, resolution evidence, customer-visible limitations and any necessary preventive action. Avoid blaming individuals, inventing RCA or creating elaborate postmortems for trivial issues. Confirm closure criteria with the authorized customer owner; follow contract or incident policy for any required formal notice. Gate: closure is based on verified restoration and the customer has a truthful account appropriate to severity.
Content digest
sha256:sha256:a54e24b47669c05e321b228fffeda247ff713e2a06a4277f4f803a4f151b98b4{"category":"operations","description":"Use when a CS or FDE owner must coordinate a serious customer-visible issue across internal teams, restore confidence, and verify resolution. Covers the customer-facing escalation from intake through closure; the incident commander or engineering owner retains technical response authority. Do not use as a substitute for on-call incident procedures or security breach response policy.","inputSchema":{"additionalProperties":false,"properties":{"customer":{"description":"Affected customer or account.","minLength":1,"type":"string"},"evidence":{"description":"Support ticket, incident, contract, impact examples or communication sources.","items":{"type":"string"},"type":"array"},"issue":{"description":"Observed issue, impact or escalation trigger.","minLength":1,"type":"string"},"urgency":{"description":"Optional severity/customer timing in their own terminology.","type":"string"}},"required":["customer","issue"],"type":"object"},"schemaVersion":1,"steps":[{"expectedOutputs":[{"description":"Impact summary, facts vs hypotheses, severity and response ownership.","kind":"escalation-triage"}],"id":"D37H","instructions":"Collect exact customer symptoms, occurrence window, affected users/workflows, reproduction examples, contractual commitments, known mitigations and business impact. Separate user reports, system observations and speculation. Determine if production incident, security, privacy or regulatory procedures supersede this playbook and activate the correct authorized response owner. Establish customer-facing owner and engineering escalation path; do not self-assign incident-command powers. Gate: severity and response ownership are explicit, or an immediate safety escalation is initiated.","resourceHints":[],"title":"Triage scope, severity, ownership and safety"},{"expectedOutputs":[{"description":"Timeline, reproduction conditions, competing causes and known unknowns.","kind":"incident-evidence"}],"id":"UO25","instructions":"Review ticket history, system evidence and prior commitments with permitted access. Construct a timestamped event sequence covering changes, observed failures, mitigations and customer communications. Work with engineering/support to identify the most plausible fault boundary and tests that discriminate causes. Avoid overclaiming root cause before confirmation. Preserve sensitive logs securely and disclose only approved information to the customer. Gate: internal responders work from an accurate shared problem statement and can test the leading hypotheses.","resourceHints":[],"title":"Create one coherent technical and customer evidence trail"},{"expectedOutputs":[{"description":"Mitigation options, communication draft, owner responsibilities and checkpoints.","kind":"response-plan"}],"id":"BQGC","instructions":"Compare viable mitigations, temporary workarounds, permanent fixes and no-action risks, including customer effort. Agree who can approve each action, response cadence and the next evidence checkpoint. Draft a customer update containing acknowledged impact, current verified status, workaround if safe, and next update timing; do not promise an unapproved fix time. Escalate blocked decisions to the actual owner. Gate: the customer has an accurate update ready and internal owners have testable response actions.","resourceHints":[],"title":"Coordinate response and set truthful expectations"},{"expectedOutputs":[{"description":"Verification record, remaining issues and customer-facing resolution status.","kind":"resolution-verification"}],"id":"E41J","instructions":"Obtain evidence for technical fix and customer-observed restoration; compare against the original failure example and regression criteria. Distinguish fix developed, deployed, technically verified and customer-confirmed. If the issue persists, update diagnosis and communication rather than declaring success. Actions affecting external systems and outbound communication require the applicable permission. Gate: the original customer impact is demonstrably resolved or explicitly remains open with a bounded mitigation.","resourceHints":[],"title":"Validate the fix in the customer's workflow"},{"expectedOutputs":[{"description":"Customer-ready resolution note and targeted recurrence prevention.","kind":"closure-summary"}],"id":"83WA","instructions":"Prepare a short closure note describing impact, verified timeline, confirmed cause where known, resolution evidence, customer-visible limitations and any necessary preventive action. Avoid blaming individuals, inventing RCA or creating elaborate postmortems for trivial issues. Confirm closure criteria with the authorized customer owner; follow contract or incident policy for any required formal notice. Gate: closure is based on verified restoration and the customer has a truthful account appropriate to severity.","resourceHints":[],"title":"Close with a proportionate account of cause and prevention"}],"title":"Resolve a Customer Escalation"}