要用 AI 构建服务蓝图，先从一项范围明确的服务和经核实的旅程证据出发，再把客户动作、前台互动、后台工作、支持流程、系统、证据、交接和负责人分层对齐。让假设始终清楚可见：一个听起来合理的后台故事，并不是观察到的流程。

用负责任的 AI 流程来整理记录、质疑缺口。实际发生了什么，必须由服务负责人和实际执行工作的人确认。

关键要点

旅程图以用户体验为中心；服务蓝图把这种体验与交付联系起来。

先固定服务范围、角色、场景、渠道以及起点和终点。

在客户可见的活动与内部活动之间画出可见线。

每一项后台主张都要附上证据、负责人或假设状态。

复核交接、排队、失败点和恢复，而不只是顺利路径。

用 AI 构建服务蓝图会带来什么不同？

体验图或旅程图整理的是用户随时间推移所做、所遇、所想或所需。GOV.UK 建议团队依据研究绘制体验图，用它理解整体体验，而不是孤立的接触点。［1］服务蓝图则加上了产生这些接触点的运营层：前台人员或界面、后台操作、支持流程、系统、政策、证据、负责人和交接。

问题	旅程图	服务蓝图
主要视角	用户体验和目标	服务如何交付这种体验
典型证据	研究观察、引语、行为、需求	旅程证据，加上流程、系统、政策和运营记录
主要行	阶段、动作、接触点、需求、痛点	客户、前台、后台、支持、系统/证据、失败
主要边界	用户端到端的问题	一个界定清楚的服务交付范围
决策负责人	研究和产品团队	服务、运营、技术、政策和支持负责人

不要用一张内部流程图取代客户旅程图。把旅程作为一项承载证据的输入，再用蓝图把它与交付联系起来。

如何确定服务范围和证据？

步骤 1：写清服务范围

界定一个场景、角色、渠道组合、触发条件、结果和时间边界。“客户支持”太宽泛；“现有账户持有人通过网页聊天报告一笔不认识的扣款，收到案件决定，并看到账户已更新”才可以检验。

记录：

蓝图 ID、版本和负责人；
目标用户或角色，以及经核实的需求；
起始触发条件和期望结果；
开始和结束事件；
渠道、地点和相关变体；
纳入和排除的服务组成部分；
来源旅程图的版本和研究引用；
复核参与者和决策权限。

GOV.UK 关于“完整问题”的指南要求团队理解用户最终想做成什么，包括超出某一个组织服务范围的互动。［2］用这种更宽的视角识别依赖关系，但不要悄悄扩大一张蓝图，直到它试图代表所有可能的旅程。

步骤 2：先建证据登记表

为访谈、观察笔记、分析数据、客服记录、SOP、系统文档、政策、培训材料和员工走查建立稳定的证据 ID。每一项都记录来源、版本或日期、确切位置、适用的渠道或案件类型、负责人、访问边界和复核状态。

区分四种状态：

Observed：有用户或运营证据直接支持。
Confirmed：经承担责任的流程负责人确认。
Assumption：看似合理，但有待确认。
Conflict：来源之间不一致，或做法存在差异。

AI 不得因为好几个人都这样说，就把假设升级为事实。重复可能只说明某种看法很普遍，而不是系统的实际行为。把材料交给模型之前，尽量减少个人数据和机密数据；NIST 把隐私、虚构内容、信息完整性和人机配置列为生成式 AI 的风险。［4］

如何绘制客户动作和前台互动？

步骤 3：建立客户动作时间轴

从有旅程证据支持的客户动作开始。每一列放一个可观察的动作或有意义的等待状态。使用“提交”“等待”“收到”“查看”“重试”之类的动词，而不是“互动”这样宽泛的阶段。

每一列记录触发条件、动作、渠道、预期结果、证据 ID、不确定性和下一个事件。研究显示有放弃、重复尝试、切换渠道和等待时，也要纳入。这些时刻往往能揭示顺利路径流程图所掩盖的运营问题。

如果没有旅程图，不要让 AI 编造一张作为脚手架。开展或调取相应的研究，再建立一份可追溯的旅程。临时蓝图可以列出明确的研究缺口，但不应把想象出来的行为当作事实呈现。

步骤 4：在可见线上方添加前台互动

前台活动是客户能够感知到的内容：员工对话、消息、表单、状态、实物、通知或可见的界面反馈。把这些操作放在它们所支持的客户步骤下方。

每个前台单元格记录：

执行者或界面负责人；
动作和渠道；
输入和输出；
客户看到的服务证据；
经核实的响应时间或政策要求（如有）；
无障碍或协助服务的途径；
失败信号和恢复路径；
来源和状态。

在客户动作与前台操作之间画出互动线，在前台一栏下方画出可见线。可见线以下的内容，客户无法直接看到，尽管其结果可能在稍后显现。

不要根据面向客户的消息推断员工做了什么。一条“已批准”的通知，并不能证明是哪个团队、哪条规则、哪个系统或哪次审核产生了它。在运营证据确认其机制之前，把它保留为未知。

如何绘制后台与支持工作？

步骤 5：只按证据绘制后台工作

后台工作包括直接支持某个前台互动的内部决定、准备、分派、检查、转换和异常处理。与实际执行流程的人一起访谈或走查。把政策的规定与案件、日志和员工描述进行比较。

使用 action ID、trigger、performer、input、rule、system、output、handoff、queue、time、evidence ID、status 和 exception 等字段。某个字段未知，就保持未知，并指定一名核实负责人。

AI 提示可以稳妥地守住这条边界：

只把提供的证据整理进蓝图结构。让客户、前台、后台、
支持、系统、证据和失败各栏保持分开。
不要推断隐藏的工作、负责人、系统、规则、顺序、时间或因果关系。
无依据的单元格标为 Assumption，来源冲突标为 Conflict。
返回没有着落的证据和缺失的交接，供人工复核。

英国教育部发布过一个构建服务蓝图的示例，用来理解一项服务，并让工作在各团队之间可见。［3］用示例学习方法，而不要把它当作证明你的组织也有同样的栏目或角色的证据。

步骤 6：添加支持流程、系统和规则

支持流程为交付提供条件，但不一定与某个客户步骤一一对应：排班、采购、身份管理、数据维护、培训、合规审查、供应商运营和平台可靠性。把它们放在单独的一栏，以免蓝图暗示它们与客户直接互动。

增加一栏“系统与证据”，列出应用、记录、消息、文档、实物和控制证据。只有经过核实，才写明权威记录系统。把渠道与系统区分开：电子邮件可能负责传递通知，而案件平台才掌握状态。

政策和业务规则应写明负责人、版本、适用范围和位置。从旧 SOP 抄来的规则不一定是现行的。关于职责的问题，先链接到利益相关者地图；当某项具体决定或交付物需要明确问责时，再使用 RACI 矩阵。

如何表达交接与恢复？

步骤 7：把交接写成事件

当职责、信息、工作或状态在人员、团队、系统、供应商或渠道之间转移时，就发生了交接。把它画成一个事件，而不是一支没有标注的箭头。

记录：

交接字段	复核问题
发送方和接收方	双方是否都是具名的责任方？
触发条件	什么可观察的事件启动了转移？
转移内容	转移的是哪些数据、产物或状态？
接收确认	接收方如何知道它完整且有效？
排队与时间	工作可能在哪里等待、过期或乱序到达？
失败信号	如何发现丢失、被拒或重复？
恢复负责人	谁负责重试、更正、升级或通知客户？
证据	哪条记录证明交接已经发生？

留意没有去向的输出、多个负责人、隐性的排队、手工复制、渠道切换，以及没有验收标准的工作。这些是蓝图的发现，而不是根本原因的证明。

步骤 8：标记失败点与恢复

对每一列，都问一问：在可见互动之前、之中和之后，可能出什么问题？包括渠道不可用、输入无效、内容无法访问、依赖未满足、系统超时、重复案件、记录冲突、政策例外、容量限制和交接丢失。

把客户可见的症状与内部失败的假设分开记录。然后记录发现方式、遏制、恢复、沟通、升级、负责人和证据。在调查支持之前，不要给出根本原因的标签。

只有在蓝图暴露了依赖和例外之后，才把稳定、获批的操作顺序转化为 SOP 检查清单。蓝图用于诊断和对齐；清单用于指导可重复的执行。

如何验证并改进服务蓝图？

步骤 9：跨职能走查

召集用户或研究代表、前台员工、后台操作人员、支持团队、系统负责人、政策负责人和服务负责人。用真实的案例从左到右走一遍，其中至少包括一个失败案例和一个渠道变体。

请每位参与者只确认属于其证据和权限范围内的单元格。把更正记录为新的修订版本，而不是覆盖历史。通过调查实际案例和职责归属来解决做法上的冲突；不要让级别最高的人或模型最整洁的措辞来决定。

用可观察的记录检验蓝图。某个选定的客户动作，能否追溯到前台结果、后台活动、系统状态、交接记录和负责人？团队能否说明等待从哪里开始、在哪里结束？能否指出恢复失败时客户会看到什么？

步骤 10：治理改进

依据经核实的频率、对用户的后果、运营成本、风险和战略重要性，为失败点排定优先级。让证据质量保持可见。一个未经量化但很严重的无障碍障碍，不应因为另一个问题的数量更大就消失不见。

每一项改进都记录问题、受影响的蓝图单元格、证据、假设、负责人、依赖、决定、衡量方式、推出边界和重新绘制蓝图的触发条件。蓝图本身不是批准。产品、运营、技术、法律、无障碍和风险负责人仍各自保留其决定权。

复核清单

总结

把旅程图作为用户体验的证据，而不是整张蓝图。
让各运营层与一条范围明确的客户动作主线对齐。
把可见的互动放在可见线之上。
把缺乏依据的后台细节标为假设。
与承担责任的负责人一起检查交接、排队、失败和恢复。
随着服务和证据的变化，为蓝图做版本管理。

常见问题

没有用户旅程图能画服务蓝图吗？

你可以先搭一个临时结构，但客户动作仍需要研究证据。记录缺口，避免把假设的行为变成一份完成的旅程。

蓝图需要多少层？

使用能保持客户、前台、后台、支持、系统/证据和职责区分的最少层数。只有当新增一层能澄清真实的职责或依赖时才添加。

服务蓝图的可见线放在哪里？

放在客户能感知的互动之下、内部工作之上。如果可见性因渠道而异，就标出这种差异，而不是强行给出一个答案。

AI 能从旅程图推出后台流程吗？

它可以提出问题或占位内容，但无法把隐藏的工作确立为事实。后台操作要由操作人员、记录、系统和政策负责人确认。

蓝图是组织架构图吗？

不是。它描绘的是随时间推进的交付。组织架构图显示汇报关系；其他职责问题请使用利益相关者地图或职责地图。

每格多详细？

细到足以暴露输入、输出、交接、等待、失败和职责。如果不拆分就会掩盖不同的执行者或验收规则，就拆分该单元格。

每个失败点都要立项吗？

不需要。先核实证据，再在组织的决策流程下，按用户影响、运营风险、频率、成本和战略排定优先级。

何时更新蓝图？

在渠道、政策、系统、角色、供应商、流程或研究发生重大变化后更新，并保留每次决策所依据的版本。

来源

GOV.UK Service Manual — Creating an experience map — https://www.gov.uk/service-manual/user-research/creating-an-experience-map/
GOV.UK Service Manual — Map and understand a user's whole problem — https://www.gov.uk/service-manual/design/map-a-users-whole-problem
Department for Education — Building a service blueprint — https://design-histories.education.gov.uk/communicating-funding-beta/building-a-service-blueprint
NIST — Artificial Intelligence Risk Management Framework: Generative AI Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 2026 年 9 月 6 日。

如何用 AI 构建服务蓝图，把客户旅程连到后台与交接