当服务交付涉及员工、系统和运营流程…

当员工、后台系统和运营流程共同构成服务体验时，用服务蓝图把前台、后台与支持系统映射到同一张图中，以揭示运营缺口、依赖关系和协调问题。

适用场景

解决思路

1. 定义范围：选择一个具体场景（例如“首次用户完成引导”），不要试图一次性为整个产品绘制蓝图。
2. 收集输入：用户旅程研究、干系人访谈、流程文档、分析数据。
3. 起草用户行动：从用户旅程图改编。
4. 映射前台：针对每个用户行动，系统或团队做了什么用户可见或可体验的事。
5. 映射后台：为支撑每个前台行动，背后发生了什么。
6. 映射支持流程：哪些基础设施、工具或第三方服务支撑后台行动。
7. 添加物理证据：用户在每个步骤看到、触摸或收到的物件（屏幕、邮件、收据、包装、空间）。
8. 识别失败点：泳道在哪里断开？延迟、错误或交接在哪里出问题？
9. 验证：与运营、工程和支持团队评审，他们常能发现遗漏的后台步骤。
10. 按五条水平泳道绘制蓝图：物理证据、用户行动、前台行动、后台行动、支持流程。
11. 用交互线分隔用户行动与前台，用可见性线分隔前台与后台，用内部交互线分隔后台与支持流程。
12. 阅读缺口：查找前台承诺而后台无法交付的地方。
13. 查找高密度后台集群：复杂度可能适合自动化或简化。
14. 查找单个前台行动依赖多个支持项：这是脆弱性，可能是单点故障。
15. 查找长时间没有用户触点的水平段：用户正在等待，确认是否已沟通。
16. 先绘制现状，再绘制未来状态，不要跳过现状。
17. 与运营团队共创，而不只是设计团队；他们了解后台。
18. 保持范围狭窄；一个聚焦场景的蓝图比覆盖一切的庞大图谱更有用。
19. 把蓝图用作跨职能规划中的协调工件，而不只是研究输出。
20. 服务变化时重新审视蓝图；它们比用户旅程图更快变得误导。

适用边界 · 注意事项

• 若只需映射客户可见体验层，不要用本技能，应使用 `experience-map`。
• 若只需要理解用户情绪旅程，使用用户旅程图；服务蓝图用于设计和修复交付系统。
• 不要一次性蓝图化整个产品；范围过宽会使图失去可操作性。