触点图要标注目的，否则只是库存
体验盘点里，如果触点图仍是把触点画全就算完成，结果往往是图很完整，没有人知道每个点为何存在。
文章 · 体验与互动 · 汽车与出行
诊断要同时看覆盖和深度
诊断项目里，如果触点诊断仍是只看有没有这个触点，结果往往是有触点，但深到不足以影响决定。更稳妥的做法是同时记录是否存在，以及是否深到能影响决定，并用诊断表把这个选择固定下来。
核心要点
- 在诊断项目里，触点诊断不该继续停留为只看有没有这个触点。
- 放着不管，就会反复出现同一件事：有触点，但深到不足以影响决定。
- 起点换成：同时记录是否存在，以及是否深到能影响决定。
- 把选择写进诊断表，由体验负责人。
- 以后只按一个问题验收：一个只是存在的触点，是否被误当成已经做好。
01触点诊断由谁负责
在诊断项目里，触点诊断若没有明确的负责人，就会退化成只看有没有这个触点。大家都参与，也就没有人承担后果：有触点，但深到不足以影响决定。
负责不是亲自改每一句，而是有人有权在冲突时维持同时记录是否存在，以及是否深到能影响决定。
同时记录是否存在，以及是否深到能影响决定。做不到这一点，触点诊断就还停在只看有没有这个触点。
02触点诊断的交接物是什么
交接不能靠口头。上一环交给下一环的，应是诊断表，而不是继续沿用只看有没有这个触点。
没有交接物时，每个团队都会按自己的理解处理触点诊断，接缝里冒出来的仍是：有触点，但深到不足以影响决定。
03触点诊断的节奏怎么排
节奏要固定。诊断评审，比等到出了问题再开复盘会更节省注意力。
节奏一旦让给每一个临时战役，触点诊断就只在发布当天存在。
04触点诊断如何被使用
使用方式要简单。打开诊断表的人，应能判断眼下这件事该不该做。
如果使用诊断表还需要专人翻译，它就还是只看有没有这个触点，只是换了载体。
05触点诊断怎样算做完
做完的标准不是发出去了。标准是：一个只是存在的触点，是否被误当成已经做好。
体验负责人。人离开岗位时，诊断表还在，触点诊断才没有停在某一次项目里。
框架图
触点诊断的四层结构
从不可让渡的部分到现场可用的工具，每一层只回答一个问题，避免把触点诊断重新写成只看有没有这个触点。
L1覆盖
这一层写明触点诊断里什么不能让渡。
L2深度
这一层把触点诊断收成可检查的条件。
L3不够深时
这一层规定触点诊断在不同场合可以变什么。
L4优先补哪一个
这一层把触点诊断交给使用的人，并写明例外。
注：本图为概念框架示意，用于说明思考结构，不代表任何统计数据。来源：清美未来洞察团队。
行动建议
行动 01
先看现场
在诊断项目里标出触点诊断真正被调用的时刻，不要从改写只看有没有这个触点开始。
行动 02
收成一页
用诊断表代替更长的说明，只保留能支持「同时记录是否存在，以及是否深到能影响决定」的内容。
行动 03
按一个问题验收
诊断评审，只问：一个只是存在的触点，是否被误当成已经做好。答不上来，就还不是决策。
行动 04
写明维护人
体验负责人。没有维护人的触点诊断，会在冲突里被悄悄改掉。
相关
全部洞察相关洞察
低价值触点要敢于拿掉
体验优化里，如果触点删减仍是只加不减，结果往往是人被更多信息打扰，关键时刻却被冲淡。
同一问题在不同渠道答案要一致
多渠道服务里，如果答案一致仍是每个渠道按自己的习惯回答，结果往往是人换一个渠道就得到另一个答案。