道歉与澄清
出错后不回避：承认事实、说明影响、给出补救与防止复发的具体动作。
可整段复制 占位符用双大括号标出，替换成你的内容即可
# 道歉与澄清｜{{事项}}
## 一、事实
- 发生了什么：{{客观描述}}
- 发生时间：{{时间}}
- 影响范围：{{人/系统/客户}}
- 当前状态：{{已恢复/处理中/待确认}}
## 二、承认与责任
- 这是我的责任：{{具体责任范围}}
- 不是我负责的部分：{{说明，但不推卸}}
- 我当时判断：{{当时的想法}}
- 我漏掉了：{{关键疏忽}}
## 三、影响说明
- 对客户：{{影响}}
- 对团队：{{影响}}
- 对项目：{{影响}}
- 已采取的止损：{{动作}}
## 四、补救方案
1. 立即：{{今天要做的}}
2. 短期：{{本周要做的}}
3. 长期：{{防止复发的机制}}
4. 补偿：{{如有必要}}
## 五、防止复发
- 流程调整：{{新增检查/审批}}
- 工具调整：{{监控/自动化}}
- 责任明确：{{谁在什么节点检查}}
- 复盘安排：{{日期}}
## 六、沟通话术
### 对客户
关于 {{事项}}，我们确认了 {{事实}}，给你带来 {{影响}}，非常抱歉。
我们已 {{补救}}，预计 {{时间}} 恢复。后续会 {{防止复发措施}}。
如果你还有疑问，可以随时联系 {{姓名与联系方式}}。
### 对团队
这次 {{事项}} 是我的责任，影响是 {{影响}}。
我已 {{补救}}，接下来会 {{改进}}。
需要大家配合的是 {{事项}}。
## 七、跟进
- [ ] {{日期}} 确认补救完成
- [ ] {{日期}} 更新复盘文档
- [ ] {{日期}} 回访受影响方
复制与下载都在浏览器本地完成，不会上传内容，也不需要登录。
怎么用
- 先讲事实与影响，再道歉；不要一上来长篇解释原因。
- 补救方案要分立即、短期、长期，让对方看到行动。
- 防止复发比道歉更有价值，尤其是重复性失误。
为什么这么写
- 结构化道歉能降低对方的不确定感，恢复信任。
- 承认责任范围但不背不属于自己的锅，保持专业。
- 补救与防复发让沟通从情绪转向解决。
- 回访确认能形成闭环。
常见错误
- 用「如果让你不舒服」代替明确道歉。
- 解释原因多于补救动作。
- 道歉后没有跟进，同样问题再次发生。