服务蓝图

服务蓝图是一张图表，它描绘了客户在使用服务过程中的所有步骤，以及支撑这些步骤的所有要素：客户可见的操作、客户可见的员工活动、客户不可见的员工活动、涉及的内部流程，以及每个步骤所依赖的系统。它将客户旅程图向下延伸至提供服务的运营环节。

它的结构采用水平条带，并以明确的线条分隔。客户操作位于顶部。交互线下方是前台操作，即客户能够感知到的员工活动。可见线下方是后台操作，即在不为人知的情况下为服务提供支持的操作。内部交互线下方是支持流程和系统。垂直阅读每个步骤，即可了解该步骤成功所需的所有步骤。

这种纵向解读具有诊断价值。当分析客户问题时，流程图会显示员工的操作、流程以及底层系统，这往往表明问题的根源并非症状出现之处。例如，某个环节的响应缓慢可能源于三层以下的审批步骤；客服人员无法回答问题可能源于系统中缺少相关信息。

故障点和等待时间是使流程蓝图真正发挥作用的关键标注。标记流程中常见的故障点、交接点以及客户等待点，既能明确所需的恢复机制，又能识别耗时最集中的区域。在大多数服务中，步骤之间的等待时间远超步骤本身所占的总时长，而这在仅记录操作的流程图中是无法体现的。

构建流程图需要设计团队无法获取的信息。一线员工了解流程的实际问题所在以及维持流程运转的变通方法，运营团队了解流程的限制条件，技术团队则清楚系统能够支持和不能支持的功能。如果缺少这些贡献者的参与，生成的流程图描述的只是流程文档，而非实际执行情况，而这两者之间的差异往往正是改进机会所在。

除了设计之外，该成果还能服务于多个用户群体。运营团队用它来识别低效和重复工作，技术团队用它来了解哪些系统支持哪些环节以及集成差距在哪里，而领导层则用它来理解为什么如果不进行结构性变革就无法兑现面向客户的承诺。正是这种广泛的应用范围，使其比单纯的客户旅程图更具组织影响力。

蓝图不仅在诊断方面有用，而且在预测方面也同样重要。为一项尚未存在的服务制定蓝图，就能迫使我们在构建任何功能之前，明确决定由谁执行哪些操作、哪些系统需要提供哪些信息以及交接环节在哪里进行。精心设计运营流程远比在服务上线后才发现承诺的客户体验背后缺乏流程要划算得多。

范围控制至关重要，因为试图涵盖所有内容的蓝图会变得毫无用处。一份针对某个重要流程、细节程度一致的蓝图，既清晰易懂又切实可行。而试图涵盖所有服务组合及其所有变体的蓝图，最终只会沦为一面装饰画，在研讨会上或许能给人留下深刻印象，但之后便无人问津。选择业务量最大或故障率最高的流程，比追求面面俱到的蓝图更能带来丰厚的回报。

由于输出结果通常反映的是流程和系统而非接口的变化，因此根据输出结果采取行动需要超出设计职能的权限。实际上，蓝图是通过以下方式生成的： 用户体验审核 以及服务设计工作，并提供证据 用户研究 包括员工访谈在内的各项工作，以及访谈中暴露出的系统依赖关系，通常会成为交付路线图的输入。 产品开发.