三个客户同时来电,先帮的不该是嗓门最大的
把严重程度、紧急程度和已签的 SLA 分开看,前线部署工程师(FDE)就能在十五分钟内排好上午的工作,并讲得出理由。
要点速览
- 严重程度衡量损害,优先级决定何时动手。两者不是一回事,不要混为一谈。
- 首次响应只需几分钟,却能守住 SLA 承诺,所以开始修复前先给每个客户发一条。
- 时限紧但影响小的问题,往往用变通方案就能交差,根因修复可以往后放。
设想这样一个场景:早上 8:40,手机十分钟内响了三次。三个客户,三个焦急的声音,每个人都确信自己的问题最要紧。
这时多数工程师会凭本能行事:谁嗓门大就先处理谁,或者谁先打来就先处理谁。无论哪种做法,都可能在不知不觉中违反已经签下的承诺。
假设你负责三个部署,每个客户都有自己的合同、工作时间和重要程度。你需要的能力,是在十五分钟内把工作排好顺序,并且能说清为什么这样排。
三个不同的问题,而不是一个
根本错误在于把一切都塞进一个词:“紧急”。其实每通电话都包含三个独立的问题,各有各的答案。
第一个是严重程度:这起事件对用户和业务造成多大伤害。在最高一级,PagerDuty 举的例子是 SEV-1:影响大量客户的严重事件,通常需要发布公告,并需要有人直接与高层管理者协同处理。
第二个是紧急程度,即问题对时间有多敏感。一个小 bug,如果客户下午 2 点要交报告,照样可能非常紧急。
第三个是你承诺的响应时间。按 Plain 的说法,支持类服务等级协议(SLA)是对客户的一项可衡量的承诺,规定你多快响应、多快解决。这个问题的答案不取决于任何人的感受,它写在合同里。
优先级不是第四个问题,而是前三个问题的结果。它决定你何时开始处理、反应要多快。ITIL 的做法把它概括为 Priority = f(Impact, Urgency)。
一个上午,三通电话
回到前面的假设。客户 A 是一家物流公司:报表导出功能对一位分析师失效了,而这份报表下午 2 点要提交董事会。影响小,紧急程度高。
客户 B 是一家零售连锁企业:回答库存问题的 Agent 给所有门店员工报出错误的数字。影响面广,并假设合同承诺 P1 事件 30 分钟内首次响应。
Plain 指出,P1 事件的首次响应目标通常是 15 到 60 分钟,所以这个假设数字处在常见区间内。
客户 C 是一家正在试点的银行,也是战略上最重要的客户。他们反映某个内部看板上的模型延迟略有上升,没有截止时间。影响小,紧急程度低,但名头很大。
下表是一个示例矩阵,用来把两个维度换算成优先级。具体阈值因公司而异,关键是在电话响起之前就把矩阵准备好。
| 时限紧 | 时限宽 | |
|---|---|---|
| 影响面广 | P1 — 客户 B | P2 |
| 影响面窄 | P2 — 客户 A | P3 — 客户 C(考虑升级之前) |
合理的顺序是:先 B,再 A,C 排进日程。但修复的顺序不等于联系的顺序,很多人恰恰在这里失分。
先响应,再修复
Plain 把 SLA 拆成两个计时:首次响应和解决。解决时间更难控制,因为有些 bug 需要工程团队介入,所以 Plain 建议为每个优先级分别设定目标。相比之下,首次响应完全掌握在你自己手里。
所以在 8:50,还没打开任何日志,你就发出三条消息。给 B:“已收到,定为 P1,下次更新时间 9:20。”给 A:“明白,你们的截止时间是下午 2 点,11 点前会给出解决方案。”给 C:“已收到,我们今天下午评估,下班前回复。”
写这三条消息只要几分钟。换来的是:B 在承诺时限内收到了首次响应,A 知道你理解他们的截止时间,C 虽然暂时没有被处理,但知道自己的问题有人听到了。
对 A 来说,时限紧并不意味着必须马上修复根因。11 点前发过去一份手动导出的 CSV,就能满足他们的真实需求,也就是开会要用的报表。底层 bug 可以明天再修。
大客户能插队吗?
incident.io 承认,影响大客户的低严重程度事件,可能值得提高级别。这很合理,你完全可以把客户 C 从 P3 提到 P2。但提级要有一个能写下来的理由,比如试点的评审会快到了,而不是出于害怕。
如果让客户 C 排到客户 B 前面,你调一个内部看板的时候,成千上万的零售员工还在拿到错误的库存数字。事后有人问起,你拿不出任何理由为这个决定辩护。
动手试试:前十五分钟的五个步骤
第一步:把每通电话用一句话记下来:影响了谁、多少人、症状是什么。第二步:按受影响的用户数和被阻断的业务流程给严重程度打分,而不是看来电者的语气。
第三步:直接问:“你们最晚什么时候需要结果,为什么?”这个“为什么”往往能引出变通方案。第四步:查每个客户的 SLA,发出首次响应,从承诺时限最短的客户开始。
第五步:把优先级顺序和理由发到团队的共享频道。当经理或客户经理问为什么客户 C 要等时,答案已经摆在那里。
常见的陷阱
最常见的陷阱是把严重程度和优先级当成一回事,结果一个时限紧的小 bug 被忘到下午 1:55。第二个陷阱是在电话里承诺解决时间,而你真正能掌控的只有响应时间。
第三个陷阱是修复期间一声不吭。客户看不到你在看日志,只看到一直没有消息。定好下次更新的时间并按时兑现,哪怕没有新进展。
把这项能力变成证据
阅读前线部署工程师(FDE)的岗位描述时,留意 on-call、SLA、escalation、同时对接多个客户这类表述。它们说明这个岗位恰恰要求这项能力。面试时,讲一次真实的分诊经历,覆盖影响、时限和承诺三个维度,再说明你做了什么选择、为什么。
在简历上,一句具体的话比“抗压能力强”更有分量。例如:“同时为四个客户进行事件分诊,一个季度内首次响应 SLA 零违约”。只写你能证明的数字。
三通电话的早上还会再来。准备好矩阵和消息模板,前十五分钟就不会那么手忙脚乱。
这篇文章对你有帮助吗?
感谢你的反馈!
5 个信源
- Understanding the differences between severity vs priority in incident management · 2023-01-03
- Incident severity vs priority: What's the difference? · 2022-02-24
- Incident Severity Classification: Best Practices to Speed Resolution · 2026-03-10
- How to Create Priority Calculation · 2026-01-30
- Customer Support SLAs for B2B SaaS: How to Set, Measure, and Actually Hit Them (2026) · 2026-06-30