---
name: incident-customer-notice
description: 按事故的各个阶段（调查中、已定位、监控中、已恢复）撰写面向客户的故障公告和事后复盘摘要，讲清发生了什么、影响了谁、做了什么、之后改什么，道歉直接、不含糊其辞。适用于服务宕机、状态页更新、服务中断、数据或计费事故，或有人要写故障通知邮件、状态更新、给客户的事故复盘（postmortem）摘要时。
---

# 面向客户的事故公告

事故进行中，客户最想尽快知道 3 件事：是不是你们的问题、会不会影响他们、什么时候能听到下一次消息。事故结束后，他们要知道发生了什么、有人在负责、以及为了不再发生会改什么。尽早发布，只说已确认的事，每次都给出下一次更新的时间。

## 适用场景

- 某项服务对客户宕机、变慢或出错，需要发状态页公告或邮件。
- 事故进入新阶段，需要更新。
- 事故已恢复，需要向客户说明发生了什么、之后改什么。
- 不适用于涉及个人信息的安全泄露：那类事件有法定的通知规则，请和律师或隐私负责人一起起草。也不适用于单个客户的工单：用 reply-in-our-tone。

## 需要准备

- 客户看到的现象（报错、变慢、数据错误）、涉及哪些产品功能、哪些客户或地区，以及开始时间（含时区）。
- 当前阶段，以及团队已经确认的内容。未确认的原因不写进客户公告。
- 已恢复公告和复盘摘要还需要：结束时间、用大白话讲的原因、修复方式、之后的改进、客户需要做的操作（重新运行任务、核对发票等）。
- 缺少的信息写成“[待确认：……]”。团队没给出的修复时间，绝不自己估。

## 步骤

1. **标明阶段。** 只用以下之一：调查中（已看到现象，原因未知）、已定位（找到原因，正在修复）、监控中（修复已上线，持续观察）、已恢复。得知客户受影响后 15 分钟内发出第一条“调查中”更新。复盘摘要另发一条消息。
2. **先用客户的话讲影响。** 比如“部分客户无法登录”“今天发出的发票税额可能有误”。功能名称用客户熟悉的叫法。知道影响了谁就写明；不知道就写“部分客户”。
3. **说明正在做什么，只说已确认的。** 调查中：“我们正在排查。”已定位：原因确认后，用大白话说出原因。监控中：“修复已上线，我们正在观察。”不猜原因，早期更新中不把责任推给供应商。
4. **给出下一次更新时间。** 每条更新都以“下一次更新不晚于 [时间，时区]”结尾。这个技能的默认值：客户无法使用期间每 30 分钟更新一次，只要还有人受影响，两次更新间隔不超过 1 小时。到了时间即使没有进展也要发，并说明没有变化。
5. **撰写恢复公告。** 写明开始时间、结束时间、持续时长、影响范围、修复方式，以及客户需要做的操作。道歉一次，说得直接：“非常抱歉，这让您在 [时长] 内无法 [操作]。”不写“给您带来的不便”，不写“可能遇到了”。
6. **在承诺的时间内发出复盘摘要。** 发生了什么（时间线 3 到 6 行）、为什么（用大白话讲根本原因）、我们做了什么、之后改什么（具体措施，给出负责人或日期的就写上），以及如何获得帮助。这个技能的默认值：5 个工作日内发出。
7. **简短，并且各渠道一致。** 状态页、邮件和应用内横幅说的事实一致。状态更新控制在 2 到 4 句。

## 输出格式

```markdown
**[阶段] — [功能 / 服务]：[几个字概括影响]**
[日期、时间、时区]

[客户看到的现象和受影响范围。][我们正在做的事。][客户需要做的操作（如有）。]
下一次更新不晚于 [时间，时区]。
```

已恢复公告和复盘摘要：

```markdown
**已恢复 — [功能]：[影响]**
[开始时间] 至 [结束时间]（共 [时长]），[受影响的内容和对象]。[修复方式。][客户需要做的操作，或“您无需做任何操作。”]非常抱歉：[这让您无法做什么]。

# [日期] 发生了什么：[功能][影响]
**概要：** [2–3 句]
**时间线（[时区]）**
- [时间] — [事件]
**原因：** [根本原因，用大白话]
**我们将改进：** [措施，给出日期的就写上]
**需要帮助：** [联系方式]
```

## 示例

**输入：**

> 北京时间 09:12：华南地区客户在支付页面报错。09:40：定位为与支付服务商连接的证书过期。09:55：证书已续期，支付恢复。10:30：确认稳定，已恢复。约 380 次结账失败；客户可以重试。改进：证书自动续期，并在到期前 30 天告警，负责人：平台组，月底前完成。

**输出（节选）：**

```markdown
**调查中 — 结账：华南地区部分客户支付失败**
6月4日（周四），北京时间 09:20

部分华南地区客户在结账付款时看到报错。我们正在排查。
下一次更新不晚于北京时间 09:50。

**已定位 — 结账：华南地区部分客户支付失败**
6月4日（周四），北京时间 09:45

我们找到了原因：我们与支付服务商之间连接所用的安全证书已过期。正在续期。
下一次更新不晚于北京时间 10:15。

**已恢复 — 结账：华南地区部分客户支付失败**
北京时间 09:12 至 09:55（共 43 分钟），华南地区客户无法在结账时完成付款。我们已续期过期的证书，支付已恢复正常。如果您的付款失败，请重新尝试；失败的付款不会扣费 [待确认：确认未产生扣款]。非常抱歉：这让您在 43 分钟内无法付款。
```

## 发送前检查

- [ ] 第一行写明了阶段、功能和影响。
- [ ] 每条更新都给出了带时区的下一次更新时间。
- [ ] 团队确认之前，没有写任何原因。
- [ ] 恢复公告写明了开始时间、结束时间、持续时长，以及客户需要做的操作。
- [ ] 道歉是一句直接的话，没有“给您带来的不便”或“可能”。
- [ ] 时间、数量和改进措施都来自输入，或已标为“[待确认：……]”。

## 常见错误

- 等查明原因才发公告。先发“调查中”。
- 错过承诺的更新时间。宁可发“暂无新进展”，也不要不发。
- 把责任推给供应商。客户选择的是你们，要自己担起来；只有在复盘摘要中、确实有帮助时才提供应商的名字。