customer-escalation

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

/customer-escalation

If you see unfamiliar placeholders or need to check which tools are connected, see CONNECTORS.md.

Package a support issue into a structured escalation brief for engineering, product, or leadership. Gathers context, structures reproduction steps, assesses business impact, and identifies the right escalation target.

若遇到不熟悉的占位符，或需要查看已连接的工具，请参考CONNECTORS.md。

将支持问题整理为结构化的升级简报，提交给技术、产品或领导团队。该流程会收集上下文信息、梳理复现步骤、评估业务影响，并确定合适的升级对接对象。

Usage

使用方法

/customer-escalation <issue description> [customer name or account]

Examples:

/customer-escalation API returning 500 errors intermittently for Acme Corp

/customer-escalation Data export is missing rows — 3 customers reported this week

/customer-escalation SSO login loop affecting all Enterprise customers

/customer-escalation Customer threatening to churn over missing audit log feature

/customer-escalation <问题描述> [客户名称或账户]

示例：

/customer-escalation Acme Corp的API间歇性返回500错误

/customer-escalation 数据导出丢失行数据——本周已有3位客户反馈

/customer-escalation SSO登录循环问题影响所有企业客户

/customer-escalation 客户因缺失审计日志功能威胁流失

Workflow

工作流程

1. Understand the Issue

1. 理解问题

Parse the input and determine:

What's broken or needed: The core technical or product issue
Who's affected: Specific customer(s), segment, or all users
How long: When did this start? How long has the customer been waiting?
What's been tried: Any troubleshooting or workarounds attempted
Why escalate now: What makes this need attention beyond normal support

Use the "When to Escalate vs. Handle in Support" criteria below to confirm this warrants escalation.

解析输入内容，明确以下信息：

问题核心: 技术或产品层面的具体故障或需求
受影响对象: 特定客户、客户群体或所有用户
持续时长: 问题何时开始？客户已等待多久？
已尝试方案: 已执行的故障排查或临时解决方法
升级原因: 为何该问题需要超出常规支持的关注

请参考下方的「何时升级 vs. 支持团队自行处理」标准，确认该问题是否需要升级。

2. Gather Context

2. 收集上下文信息

Pull together relevant information from available sources:

~~support platform: Related tickets, timeline of communications, previous troubleshooting
~~CRM (if connected): Account details, key contacts, previous escalations
~~chat: Internal discussions about this issue, similar reports from other customers
~~project tracker (if connected): Related bug reports or feature requests, engineering status
~~knowledge base: Known issues or workarounds, relevant documentation

从可用数据源整合相关信息：

支持平台: 相关工单、沟通时间线、已执行的故障排查步骤
CRM（若已连接）: 账户详情、关键联系人、历史升级记录
内部聊天: 关于该问题的内部讨论、其他客户的类似反馈
项目跟踪工具（若已连接）: 相关Bug报告或功能需求、技术团队处理状态
知识库: 已知问题或临时解决方法、相关文档

3. Assess Business Impact

3. 评估业务影响

Using the impact dimensions below, quantify:

Breadth: How many customers/users affected? Growing?
Depth: Blocked vs. inconvenienced?
Duration: How long has this been going on?
Revenue: ARR at risk? Pending deals affected?
Time pressure: Hard deadline?

结合以下影响维度，量化问题的业务影响：

覆盖范围: 受影响的客户/用户数量？是否在增加？
影响程度: 是完全阻塞业务，还是仅造成不便？
持续时长: 问题已存在多久？
收入影响: 是否有ARR面临风险？是否影响待成交的订单？
时间压力: 是否有硬性截止日期？

4. Determine Escalation Target

4. 确定升级对接对象

Using the escalation tiers below, identify the right target: L2 Support, Engineering, Product, Security, or Leadership.

根据下方的升级层级，确定合适的对接对象：L2支持、技术团队、产品团队、安全团队或领导团队。

5. Structure Reproduction Steps (for bugs)

5. 梳理复现步骤（针对Bug）

If the issue is a bug, follow the reproduction step best practices below to document clear repro steps with environment details and evidence.

若问题为Bug，请遵循下方的复现步骤最佳实践，记录清晰的复现步骤，包含环境细节和相关证据。

6. Generate Escalation Brief

6. 生成升级简报

undefined

undefined

ESCALATION: [One-line summary]

升级简报: [一句话摘要]

Severity: [Critical / High / Medium] Target team: [Engineering / Product / Security / Leadership] Reported by: [Your name/team] Date: [Today's date]

严重级别: [Critical / High / Medium] 对接团队: [技术团队 / 产品团队 / 安全团队 / 领导团队] 提交人: [你的姓名/团队] 日期: [今日日期]

Impact

影响范围

Customers affected: [Who and how many]
Workflow impact: [What they can't do]
Revenue at risk: [If applicable]
Time in queue: [How long this has been an issue]

受影响客户: [对象及数量]
业务流程影响: 客户无法完成哪些操作
风险收入: （若适用）
等待时长: 问题已存在多久

Issue Description

问题描述

[Clear, concise description of the problem — 3-5 sentences]

[清晰简洁的问题描述——3-5句话]

What's Been Tried

已尝试方案

[Troubleshooting step and result]
[Troubleshooting step and result]
[Troubleshooting step and result]

[排查步骤及结果]
[排查步骤及结果]
[排查步骤及结果]

Reproduction Steps

复现步骤

[If applicable — follow the format below]

[Step]
[Step]
[Step] Expected: [X] Actual: [Y] Environment: [Details]

（若适用——遵循以下格式）

[步骤1]
[步骤2]
[步骤3] 预期结果: [X] 实际结果: [Y] 环境信息: [详情]

Customer Communication

客户沟通情况

Last update to customer: [Date and what was communicated]
Customer expectation: [What they're expecting and by when]
Escalation risk: [Will they escalate further if not resolved by X?]

上次客户更新: [日期及沟通内容]
客户预期: 客户的期望及截止时间
升级风险: 若未在X时间内解决，客户是否会进一步升级？

What's Needed

需求说明

[Specific ask — "investigate root cause", "prioritize fix", "make product decision on X", "approve exception for Y"]
Deadline: [When this needs resolution or an update]

[具体需求——如“排查根因”、“优先修复”、“对X做出产品决策”、“批准Y的例外情况”]
截止日期: [需要解决或更新的时间]

Supporting Context

参考材料

[Related tickets or links]
[Internal discussion threads]
[Documentation or logs]

undefined

[相关工单或链接]
[内部讨论线程]
[文档或日志]

undefined

7. Offer Next Steps

7. 提供后续行动建议

After generating the escalation:

"Want me to post this in a ~~chat channel for the target team?"
"Should I update the customer with an interim response?"
"Want me to set a follow-up reminder to check on this?"
"Should I draft a customer-facing update with the current status?"

生成升级简报后，可询问：

“是否需要我将此发布到对接团队的聊天频道？”
“是否需要我向客户发送临时回复？”
“是否需要我设置跟进提醒，以便后续检查进度？”
“是否需要我起草一份面向客户的状态更新？”

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违约需要跨职能决策、需要批准政策例外、存在公关或法律风险 需包含内容: 完整业务上下文、风险收入、已尝试方案、具体决策或行动需求、截止日期

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

升级后并非万事大吉，需持续维护客户关系。

严重级别	内部跟进频率	客户更新频率
Critical	每2小时	每2-4小时（或按SLA要求）
High	每4小时	每4-8小时
Medium	每日	每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

并非所有升级都需保持升级状态。在以下场景可降级：

找到根因，且问题可由支持团队解决
找到临时解决方法，可解除客户阻塞
问题自行恢复（但仍需记录根因）
新信息改变了严重级别评估

降级时需：

通知对接的升级团队
在工单中更新解决方案
告知客户解决方案
记录经验教训，供未来参考

Escalation Best Practices

升级最佳实践

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升级需包含复现步骤——这是技术团队最需要的信息
明确需求——“排查”“修复”“决策”是不同的需求
设置并传达截止日期——无截止日期的紧急性是模糊的
即使升级了技术问题，也要持续维护客户关系
主动跟进——不要等待接收团队联系你
记录所有内容——升级轨迹对模式识别和流程改进很有价值