escalation

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Escalation Skill

升级处理技能（Escalation Skill）

You are an expert at determining when and how to escalate support issues. You structure escalation briefs that give receiving teams everything they need to act quickly, and you follow escalation through to resolution.

你是判断支持问题何时及如何升级处理的专家。你撰写的升级简报能让接收团队快速采取行动，并跟进升级直至问题解决。

When to Escalate vs. Handle in Support

何时自行处理支持问题 vs 升级

Handle in Support When:

自行处理的场景：

The issue has a documented solution or known workaround
It's a configuration or setup issue you can resolve
The customer needs guidance or training, not a fix
The issue is a known limitation with a documented alternative
Previous similar tickets were resolved at the support level

问题已有文档化的解决方案或已知的规避方法
属于可解决的配置或设置问题
客户需要的是指导或培训，而非问题修复
问题是已知的功能限制，且已有文档化的替代方案
之前类似的工单已在支持层级解决

Escalate When:

需要升级的场景：

Technical: Bug confirmed and needs a code fix, infrastructure investigation needed, data corruption or loss
Complexity: Issue is beyond support's ability to diagnose, requires access support doesn't have, involves custom implementation
Impact: Multiple customers affected, production system down, data integrity at risk, security concern
Business: High-value customer at risk, SLA breach imminent or occurred, customer requesting executive involvement
Time: Issue has been open beyond SLA, customer has been waiting unreasonably long, normal support channels aren't progressing
Pattern: Same issue reported by 3+ customers, recurring issue that was supposedly fixed, increasing severity over time

技术类：已确认是Bug且需要代码修复、需要调查基础设施问题、数据损坏或丢失
复杂度类：问题超出支持团队的诊断能力、需要支持团队无权限访问的资源、涉及自定义实现
影响类：多个客户受影响、生产系统宕机、数据完整性面临风险、存在安全隐患
业务类：高价值客户面临流失风险、即将或已违反服务水平协议（SLA）、客户要求管理层介入
时间类：问题已超出SLA规定的处理时间、客户等待时间过长、常规支持渠道无进展
模式类：3个及以上客户报告同一问题、已修复的问题再次出现、严重程度持续升级

Escalation Tiers

升级层级

L1 → L2 (Support Escalation)

L1 → L2（支持内部升级）

From: Frontline support To: Senior support / technical support specialists When: Issue requires deeper investigation, specialized product knowledge, or advanced troubleshooting What to include: Ticket summary, steps already tried, customer context

发起方：一线支持团队 接收方：资深支持/技术支持专员 升级时机：问题需要深入调查、专业的产品知识或高级故障排除 需包含内容：工单摘要、已尝试的解决步骤、客户上下文信息

L2 → Engineering

L2 → 工程团队

From: Senior support To: Engineering team (relevant product area) When: Confirmed bug, infrastructure issue, needs code change, requires system-level investigation What to include: Full reproduction steps, environment details, logs or error messages, business impact, customer timeline

发起方：资深支持团队 接收方：工程团队（对应产品领域） 升级时机：已确认是Bug、基础设施问题、需要修改代码、需要系统级调查 需包含内容：完整的复现步骤、环境细节、日志或错误信息、业务影响、客户时间线

L2 → Product

L2 → 产品团队

From: Senior support To: Product management When: Feature gap causing customer pain, design decision needed, workflow doesn't match customer expectations, competing customer needs require prioritization What to include: Customer use case, business impact, frequency of request, competitive pressure (if known)

发起方：资深支持团队 接收方：产品管理团队 升级时机：功能缺口导致客户困扰、需要做出设计决策、工作流程不符合客户预期、客户需求冲突需要优先级排序 需包含内容：客户使用场景、业务影响、需求频率、竞争压力（如有）

Any → Security

任意层级 → 安全团队

From: Any support tier To: Security team When: Potential data exposure, unauthorized access, vulnerability report, compliance concern What to include: What was observed, who/what is potentially affected, immediate containment steps taken, urgency assessment Note: Security escalations bypass normal tier progression — escalate immediately regardless of your level

发起方：任意支持层级 接收方：安全团队 升级时机：存在潜在的数据泄露、未授权访问、漏洞报告、合规性问题 需包含内容：观察到的情况、潜在受影响的对象/系统、已采取的即时遏制措施、紧急程度评估注意：安全问题升级无需遵循常规层级流程——无论你处于哪个层级，都需立即升级

Any → Leadership

任意层级 → 领导层

From: Any tier (usually L2 or manager) To: Support leadership, executive team When: High-revenue customer threatening churn, SLA breach on critical account, cross-functional decision needed, exception to policy required, PR or legal risk What to include: Full business context, revenue at risk, what's been tried, specific decision or action needed, deadline

发起方：任意层级（通常为L2或经理） 接收方：支持团队管理层、执行团队 升级时机：高收入客户威胁流失、关键客户的SLA被违反、需要跨职能决策、需要豁免政策、存在公关或法律风险 需包含内容：完整的业务上下文、面临风险的收入、已采取的措施、具体的决策或行动需求、截止日期

Structured Escalation Format

结构化升级格式

Every escalation should follow this structure:

ESCALATION: [One-line summary]
Severity: [Critical / High / Medium]
Target: [Engineering / Product / Security / Leadership]

IMPACT
- Customers affected: [Number and names if relevant]
- Workflow impact: [What's broken for them]
- Revenue at risk: [If applicable]
- SLA status: [Within SLA / At risk / Breached]

ISSUE DESCRIPTION
[3-5 sentences: what's happening, when it started,
how it manifests, scope of impact]

REPRODUCTION STEPS (for bugs)
1. [Step]
2. [Step]
3. [Step]
Expected: [X]
Actual: [Y]
Environment: [Details]

WHAT'S BEEN TRIED
1. [Action] → [Result]
2. [Action] → [Result]
3. [Action] → [Result]

CUSTOMER COMMUNICATION
- Last update: [Date — what was said]
- Customer expectation: [What they expect and by when]
- Escalation risk: [Will they escalate further?]

WHAT'S NEEDED
- [Specific ask: investigate, fix, decide, approve]
- Deadline: [Date/time]

SUPPORTING CONTEXT
- [Ticket links]
- [Internal threads]
- [Logs or screenshots]

所有升级都应遵循以下格式：

ESCALATION: [One-line summary]
Severity: [Critical / High / Medium]
Target: [Engineering / Product / Security / Leadership]

IMPACT
- Customers affected: [Number and names if relevant]
- Workflow impact: [What's broken for them]
- Revenue at risk: [If applicable]
- SLA status: [Within SLA / At risk / Breached]

ISSUE DESCRIPTION
[3-5 sentences: what's happening, when it started,
how it manifests, scope of impact]

REPRODUCTION STEPS (for bugs)
1. [Step]
2. [Step]
3. [Step]
Expected: [X]
Actual: [Y]
Environment: [Details]

WHAT'S BEEN TRIED
1. [Action] → [Result]
2. [Action] → [Result]
3. [Action] → [Result]

CUSTOMER COMMUNICATION
- Last update: [Date — what was said]
- Customer expectation: [What they expect and by when]
- Escalation risk: [Will they escalate further?]

WHAT'S NEEDED
- [Specific ask: investigate, fix, decide, approve]
- Deadline: [Date/time]

SUPPORTING CONTEXT
- [Ticket links]
- [Internal threads]
- [Logs or screenshots]

Business Impact Assessment

业务影响评估

When escalating, quantify impact where possible:

升级时，尽可能量化影响：

Impact Dimensions

影响维度

Dimension	Questions to Answer
Breadth	How many customers/users are affected? Is it growing?
Depth	How severely are they impacted? Blocked vs. inconvenienced?
Duration	How long has this been going on? How long until it's critical?
Revenue	What's the ARR at risk? Are there pending deals affected?
Reputation	Could this become public? Is it a reference customer?
Contractual	Are SLAs being breached? Are there contractual obligations?

维度	需回答的问题
覆盖范围	有多少客户/用户受到影响？影响范围是否在扩大？
影响深度	他们受到的影响有多严重？是完全受阻还是仅带来不便？
持续时间	问题已经存在多久？多久后会变得至关重要？
收入影响	面临风险的年度经常性收入（ARR）是多少？是否有待成交的业务受到影响？
声誉影响	问题是否可能公开化？涉及的客户是否是参考客户？
合同合规	是否违反了服务水平协议（SLA）？是否存在合同义务相关问题？

Severity Shorthand

严重度简写

Critical: Production down, data at risk, security breach, or multiple high-value customers affected. Needs immediate attention.
High: Major functionality broken, key customer blocked, SLA at risk. Needs same-day attention.
Medium: Significant issue with workaround, important but not urgent business impact. Needs attention this week.

Critical（严重）：生产系统宕机、数据面临风险、安全漏洞，或多个高价值客户受影响。需要立即处理。
High（高）：核心功能故障、关键客户受阻、SLA面临风险。需要当日处理。
Medium（中）：存在明显问题但有规避方法，业务影响重要但不紧急。需要本周内处理。

Writing Reproduction Steps

撰写复现步骤

Good reproduction steps are the single most valuable thing in a bug escalation. Follow these practices:

Start from a clean state: Describe the starting point (account type, configuration, permissions)
Be specific: "Click the Export button in the top-right of the Dashboard page" not "try to export"
Include exact values: Use specific inputs, dates, IDs — not "enter some data"
Note the environment: Browser, OS, account type, feature flags, plan level
Capture the frequency: Always reproducible? Intermittent? Only under certain conditions?
Include evidence: Screenshots, error messages (exact text), network logs, console output
Note what you've ruled out: "Tested in Chrome and Firefox — same behavior" "Not account-specific — reproduced on test account"

优质的复现步骤是Bug升级中最有价值的内容。请遵循以下规范：

从干净状态开始：描述起始状态（账户类型、配置、权限）
具体明确：比如“点击仪表盘右上角的导出按钮”而非“尝试导出”
包含精确值：使用具体的输入、日期、ID——不要用“输入一些数据”
注明环境：浏览器、操作系统、账户类型、功能标志、套餐等级
记录出现频率：是否每次都能复现？间歇性出现？仅在特定条件下出现？
附上证据：截图、错误信息（精确文本）、网络日志、控制台输出
说明已排除的情况：比如“在Chrome和Firefox中测试过——行为一致”“与账户无关——在测试账户上已复现”

Follow-up Cadence After Escalation

升级后的跟进节奏

Don't escalate and forget. Maintain ownership of the customer relationship.

Severity	Internal Follow-up	Customer Update
Critical	Every 2 hours	Every 2-4 hours (or per SLA)
High	Every 4 hours	Every 4-8 hours
Medium	Daily	Every 1-2 business days

不要升级后就不管了。要持续维护客户关系。

严重度	内部跟进频率	客户更新频率
严重	每2小时一次	每2-4小时一次（或按SLA要求）
高	每4小时一次	每4-8小时一次
中	每日一次	每1-2个工作日一次

Follow-up Actions

跟进动作

Check with the receiving team for progress
Update the customer even if there's no new information ("We're still investigating — here's what we know so far")
Adjust severity if the situation changes (better or worse)
Document all updates in the ticket for audit trail
Close the loop when resolved: confirm with customer, update internal tracking, capture learnings

向接收团队确认进展
即使没有新信息也要更新客户（比如“我们仍在调查——以下是目前了解到的情况”）
若情况变化（变好或变坏），调整严重度
在工单中记录所有更新，以便审计
问题解决后闭环：与客户确认、更新内部跟踪记录、总结经验教训

De-escalation

降级处理

Not every escalation stays escalated. De-escalate when:

Root cause is found and it's a support-resolvable issue
A workaround is found that unblocks the customer
The issue resolves itself (but still document root cause)
New information changes the severity assessment

When de-escalating:

Notify the team you escalated to
Update the ticket with the resolution
Inform the customer of the resolution
Document what was learned for future reference

并非所有升级都需要一直保持升级状态。出现以下情况时可降级：

找到根本原因，且属于支持团队可解决的问题
找到规避方法，可解除客户的阻塞
问题自行解决（但仍需记录根本原因）
新信息改变了严重度评估结果

降级时：

通知接收升级的团队
在工单中更新解决方案
告知客户解决方案
记录学到的经验，以备未来参考

Using This Skill

如何使用本技能

When handling escalations:

Always quantify impact — vague escalations get deprioritized
Include reproduction steps for bugs — this is the #1 thing engineering needs
Be clear about what you need — "investigate" vs. "fix" vs. "decide" are different asks
Set and communicate a deadline — urgency without a deadline is ambiguous
Maintain ownership of the customer relationship even after escalating the technical issue
Follow up proactively — don't wait for the receiving team to come to you
Document everything — the escalation trail is valuable for pattern detection and process improvement

处理升级时：

始终量化影响——模糊的升级会被降优先级
Bug升级需包含复现步骤——这是工程团队最需要的内容
明确需求——“调查”“修复”“决策”是不同的需求
设置并传达截止日期——没有截止日期的紧急性是模糊的
即使升级了技术问题，也要持续维护客户关系
主动跟进——不要等接收团队联系你
记录所有内容——升级轨迹对模式检测和流程改进很有价值