Escalation Policy

Purpose

This skill defines when a case exceeds the handling authority of the first-line agent and must be formally escalated to a specialist team. It provides decision criteria, routing rules, urgency levels, and handoff protocols to ensure no case falls through the cracks and every escalation reaches the right team with the right information.

Escalation is not failure — it is correct process execution. Apply this policy proactively, before a case worsens, not reactively after damage has occurred.

Escalation Tiers

Every case that cannot be resolved with documented knowledge base content, standard troubleshooting steps, or approved response templates must be escalated. Determine the correct tier using the criteria below.

1. Product Team

Escalate when:

• A confirmed bug or unexpected product behavior cannot be resolved via workaround

• A feature is missing, broken, or behaves differently from documented specification

• The customer reports a regression (something that previously worked no longer does)

• A product question cannot be answered from current documentation or release notes

• Multiple customers report the same issue (pattern detected across 2+ tickets)

Do not escalate to Product for:

• General "how do I use this" questions (handle via KB or documentation links)

• Feature requests without impact on active usage (log in backlog, do not escalate)

Handoff requirements:

• Ticket ID and full conversation history

• Reproducible steps or screen recording if available

• Affected account(s), plan tier, and number of impacted users

• Frequency: first occurrence, sporadic, or systematic

2. Engineering Team

Escalate when:

• Infrastructure, API, or backend system is down or degraded

• Data loss, data corruption, or data inconsistency is reported or suspected

• Performance degradation affects core product functionality (loading failures, timeouts, errors)

• An integration (third-party or internal) has stopped functioning

• A technical error cannot be reproduced via standard debugging and requires code-level investigation

• Security-adjacent technical issues requiring root cause analysis (see also Security below)

Do not escalate to Engineering for:

• UI cosmetic issues without functional impact (route to Product)

• Configuration errors resolvable by the customer or support agent

Handoff requirements:

• Error logs, error codes, or HTTP response codes

• Timestamp of first occurrence (with timezone)

• Environment details (browser, OS, API version, tenant/account ID)

• Reproduction rate: consistent, intermittent, or isolated

3. Legal Team

Escalate when:

• A customer or user makes a formal legal claim, demand, or threat (including cease-and-desist, litigation notice, or regulatory complaint)

• A request for data deletion, data access, or data portability is received (GDPR Art. 15–17 rights)

• Contract terms, SLA definitions, or liability language are disputed by the customer

• A subpoena, court order, or law enforcement request is received

• Intellectual property concerns are raised (copyright, trademark, patent)

• A customer references applicable law or regulation as the basis of their complaint

• A partner or vendor raises a breach-of-contract allegation

Do not escalate to Legal for:

• General privacy questions from customers (handle via Privacy Guidelines or KB)

• Internal compliance questions without legal claim element (route to Compliance Officer)

Handoff requirements:

• Full verbatim customer communication (do not paraphrase legal claims)

• Relevant contract or agreement reference if applicable

• Date and channel of communication

• Do not respond to the customer after Legal escalation until Legal clears the response

4. Security Team

Escalate when:

• A customer reports unauthorized access to their account or data

• Suspicious login activity, credential compromise, or account takeover is suspected

• A potential vulnerability, exploit, or penetration is reported (responsible disclosure)

• Personal data of customers or employees may have been exposed to unauthorized parties

• Unusual API activity, rate limit abuse, or bot behavior suggests an active attack

• A phishing or social engineering attempt targeting the organization is identified

• Any incident that may constitute a data breach under GDPR Art. 33 (72-hour notification window applies)

Do not escalate to Security for:

• Password reset requests (handle via standard account recovery flow)

• Generic spam or unsolicited email (log and discard unless targeted phishing)

Handoff requirements:

• Immediate escalation — do not delay to gather additional information

• Account ID, IP addresses, timestamps, and affected data types if known

• Do not alert the potentially compromised party before Security assessment

• Preserve all evidence; do not delete or modify related records

GDPR note: If a data breach is suspected, Security must assess within 24 hours. If breach is confirmed, Legal and DPO must be notified to meet the 72-hour reporting obligation under GDPR Art. 33.

5. Customer Success (CS) Team

Escalate when:

• A customer signals churn risk, cancellation intent, or dissatisfaction that goes beyond a single issue

• An enterprise or strategic account (defined by account tier) reports a critical issue regardless of severity level

• A customer has submitted 3 or more unresolved tickets within 30 days on the same theme

• A customer requests executive contact, account review, or formal escalation meeting

• A customer's NPS score or CSAT response signals severe dissatisfaction (score ≤ 3 out of 10)

• An upsell or renewal conversation is underway and a support issue threatens to derail it

• A customer raises concerns about the relationship, not just the product

Do not escalate to CS for:

• Standard support tickets resolvable within SLA (handle first-line)

• Feature requests from satisfied customers (log in backlog and thank the customer)

Handoff requirements:

• Customer health context (account tier, contract value, renewal date if known)

• Summary of open issues and resolution history

• Tone and sentiment of recent communications

• Recommended CS action (proactive outreach, executive call, compensation consideration)

Severity Classification

Use this matrix to determine urgency and response timing alongside the routing decision above.

SEV 1 and SEV 2 cases always require escalation. SEV 3 and SEV 4 cases escalate only if they meet the team-specific criteria above.

Escalation Process — Step by Step

1. Identify — Determine whether the case meets escalation criteria (use team-specific triggers above).

2. Classify severity — Assign SEV 1–4 using the matrix. SEV 1 always triggers immediate escalation.

3. Route — Select the correct team (Product / Engineering / Legal / Security / CS). If multiple teams apply, escalate to the highest-risk team first (Security > Legal > Engineering > Product > CS).

4. Document — Prepare the handoff package: ticket ID, full context, required data points per team (see handoff requirements above).

5. Notify — Inform the escalation team via the designated channel (internal ticket, Slack channel, or incident tool). For SEV 1: call or page directly — do not rely on async tools.

6. Communicate — Inform the customer that their case has been escalated and set a realistic expectation for next contact. Do not overpromise timelines.

7. Monitor — Remain the primary contact for the customer until the escalation team takes ownership. Follow up if no acknowledgment is received within the response target window.

Multi-Team Escalation

When a case spans multiple escalation targets, apply this priority order:

Security → Legal → Engineering → Product → Customer Success

Escalate to the highest-priority applicable team first. Brief the secondary team in parallel, referencing the primary escalation ticket. Do not create duplicate escalation paths — one ticket, one owner, cc'd stakeholders.

Communication Rules During Escalation

• Acknowledge the customer within 30 minutes of receiving a SEV 1 or SEV 2 case, even if no resolution is available yet.

• Never speculate about root causes, fix timelines, or liability in customer-facing messages during active escalation.

• Legal cases: Do not send any customer response after escalating to Legal until Legal approves the wording.

• Security cases: Do not confirm or deny a breach to the customer until Security has completed initial assessment.

• Keep the customer informed at agreed intervals (e.g., every 4 hours for SEV 1, every business day for SEV 2) even if only to say "investigation is ongoing."

Output Format — Escalation Handoff

When drafting an escalation handoff, use this structure:

ESCALATION HANDOFF

Ticket ID: [ID]
Date/Time: [Timestamp with timezone]
Escalating Agent: [Name / Team]
Escalation Target: [Product / Engineering / Legal / Security / Customer Success]
Severity: [SEV 1 / SEV 2 / SEV 3 / SEV 4]

CUSTOMER CONTEXT
Account: [Name, tier, contract value if known]
Contact: [Name, role, email]
Renewal / Health Risk: [Yes / No / Unknown]

ISSUE SUMMARY
[2–4 sentences describing the issue, its scope, and its impact on the customer]

STEPS TAKEN SO FAR
[Bulleted list of troubleshooting steps or responses already attempted]

EVIDENCE / ATTACHMENTS
[Error logs, screenshots, timestamps, API traces — or "none available"]

REQUESTED ACTION
[Specific ask: investigate, provide workaround, review legal claim, run security assessment, etc.]

CUSTOMER EXPECTATION SET
[What was communicated to the customer and when]

Guardrails

• Never close a ticket as "resolved" if the underlying issue has only been escalated, not fixed.

• Never promise a fix timeline, refund, or compensation without explicit approval from the relevant team.

• Never share internal escalation details, team names, or incident status with the customer unless explicitly approved.

• Never delay a Security escalation to gather more information — escalate immediately and gather in parallel.

• Always confirm handoff receipt with the escalation team. If no acknowledgment within the response target window, follow up proactively.