
人员
4 - 10

准备时间
45-60 分钟

时间
60 分钟

难度
中等
使用此技巧
在您至少发生了一起涉及大量客户沟通的事件后,可以运行这个剧本。下次事件发生后再运行一次,看看进步情况。
材料
白板或牛皮纸
记号笔
便利贴
准备
画一幅最近发生的事件的图(20 分钟)
选择最近发生的事件,该事件持续了两个多小时,让您的客户感到痛苦,并且至少涉及一些客户沟通。
回答有关该事件的以下问题:
- 事件是什么时候开始的?(您可能需要回头看看您的监控/警报工具)
- 事件是什么时候结束的?
- 这起事件调查阶段的时间范围有多长?
- 这起事件的升级/决策/变更阶段的时间范围有多长?
- 客户在您的产品中看到了什么,从而让他们知道有问题?(例如,尝试登录时,客户被引导到“出现问题”错误页面,该页面将他们指向我们的支持门户)。如果您有这个屏幕截图,可以在笔记本电脑上显示或打印出来。
- 事件期间/之后发出了哪些通信?
- 通信是通过什么媒介发送的?(可以是社交媒体渠道、服务台、状态页面、电子邮件、信鸽等。您懂的。)
- 谁负责发送每个通信?
- 每个通信是在什么时间发送的?
创建时间线(10 分钟)
提前 5-10 分钟到达会议(相应地,请务必预订会议室!)。使用白板或牛皮纸绘制事件时间线,记录事件的开始时间和事件的结束时间(问题得到解决的时间)。您可以随心所欲地让它变得简单或复杂!
初始警报 ------------------------------------------------------------------- 解决
回到您在上面回答的问题,并使用便利贴在时间线中填写事件期间用于客户通信的时间和渠道。
如果一个渠道使用了多次,则从中画出一个分支,并在每次使用该通道时用圆点表示。

例如...
您的事件响应通信时间线将如下所示。

专业提示
会议结束后,与尽可能多的同行、同事和朋友分享您的经验教训。吸取经验教训,尽可能多地告诉同行、同事和朋友,也问问他们学到了什么。这是持续带来好处的礼物!
第 1 步
搭建舞台(10 分钟)
开始会话,描述您选择重点关注的事件。展示您创建的时间线,并要求参与者根据您绘制的内容和他们从事件中记住的内容来浏览时间线。填写所有遗漏的渠道或通信。
强调这是一个安全的空间,参与者可以在这里大胆发表自己的挫折感、困惑、分歧等意见。
第 2 步
注意空白(10 分钟)
注意通信时间线中的间隔。
- 事件开始/初始警报和第一次更新之间的时间:x 分钟/小时
- 第一次更新和第二次更新之间的时间:x 分钟/小时
- 第二次更新和第三次更新之间的时间:x 分钟/小时
- 第三次更新(或解决之前的任何更新)和解决更新之间的时间:x 分钟/小时
用记号笔圈出时间最长的间隔。

专业提示
我们发现尽早(一发现影响客户的问题)沟通很重要,而且要经常沟通(每隔 20-30 分钟提供某种更新,直到问题得到解决)。除此之外的任何其他内容都可以被视为这项工作的空白。
第 3 步
沟通评估(15 分钟)
使用便利贴要求参与者写下事件期间客户沟通中的问题空白、混乱和类似问题。如果事情陷入停顿,请使用以下提示。
- 当客户到达错误页面时,我们引导他们走了哪条路?当您的产品/系统出现错误时,这是客户的典型流程吗?
- 如果您遇到类似的问题,作为客户,您会有什么感受?
- 我们是否尽早并经常与客户沟通?(您在步骤 2 中的差距应该可以回答这个问题)为什么或为什么不呢?
- 我们是如何确定谁将与客户沟通的?
- 我们是否与合适的客户进行了沟通?我们如何知道?
- 所使用的媒体/渠道是否便于客户访问/可见?客户怎么知道在哪里可以找到媒体/渠道?
- 我们发出的通信是否减少了客户联系我们支持团队的需求?
- 现在,仅从我们在事件期间/之后发出的通信中,我们的客户对这起事件了解了哪些信息?
第 4 步
根本原因分析(15 分钟)
让每个参与者上来把他们的“问题”便利贴贴在时间线旁边。让他们简要描述他们写的内容,并以小组形式讨论你们为什么认为会出现这个问题。换句话说,您的事件通信流程出现问题的根本原因是什么?
示例:
- 问题:事件发生期间,我们已有四个多小时没有向客户通报最新情况。
- 根本原因:在这四个小时内,我们没有收到开发团队的更新,所以我们不知道该对客户说些什么。

专业提示
如果您在确定所列问题的根本原因时遇到困难,请参阅我们的“五次为什么”剧本。
第 4 步
制定计划(10 分钟)
作为一个小组,根据您刚才所做的根本原因分析,选择 2-3 个高优先级问题来解决。制定行动计划,包括负责人和截止时间。
例如:
空白的根本原因 | 要填写的建议 |
---|---|
我们还不知道问题出在哪里,所以我们无法告诉客户任何有意义的事情。 | “我们对此造成的任何干扰深表歉意,我们正在紧急调查该问题。”或“我们仍在调查问题 x,我们将在 30 分钟后再次为您更新。”即使是像这样模糊的更新也比沉默要好得多。 |
没有人负责向客户传达信息 | 明确定义事件沟通角色,这样下次事件发生时您就能清楚地确定责任。 |
我们不知道该说什么或怎么说。 | 为常见事件撰写模板,或者为事件更新创建语气/风格指南,以便您的团队在事件混乱中轻松参考这些模板。 |
作为一个团队,我们尚未就一致的事件沟通计划达成一致 | 使用这个方便的模板来创建事件沟通计划。 |
对于处理事件通信的人来说,我们并不像处理事件解决的人那样有命令链。 | 使用这个便捷的模板来确定事件通信的角色、责任和上报。 |

反模式
不要仅仅为了完成剧本而写下操作项目,仅记录您的团队关注的计划。
搞定了?
请务必与您的团队共同运行一次完整的状况监控会话或检查点,从而验证是否有所改善。
想要更多手册?
请将您的电子邮件发送到下方,以便在我们添加新的状况监控和剧本时收到通知。
得到反馈吗?
在 Atlassian 社区网站上提问或发表评论。