开始前准备
单一用户场景 · 必需
对象、角色、起终点与当前或未来状态流程研究记录 · 必需
访谈、观察与日志；没有则先补研究交付支持角色 · 可补充
操作、维护、供应和管理责任资源与异常限制 · 可补充
等待、耗材、交接条件；未知单列
全流程规划与创新管理
服务蓝图与产品服务系统协同
Service Blueprinting
把用户动作、前台服务、后台支持与交接放到同一张图，挖掘设备交付和运维中遗漏的需求。
研究稿 · 创新方法 · 尚未独立专家审核或工程验证
本轮增补 · 为什么加入
补使用全周期与支持交接，区别于观察或JTBD本身。
内容可读，尚无执行契约。
先理解这个方法
解决什么问题
机器人能切割并不等于客户能稳定使用：搬运、安装、培训、清洗、耗材、故障和人工接管可能决定实际价值。R08收集观察证据、R09解释任务动机；服务蓝图把这些证据落到跨角色的交付链，暴露“这一环到底谁负责”。
为什么有效
沿单一用户场景组织用户动作、可见前台、不可见后台、支持过程和接触凭据，并用可见性等边界区分。图中依赖要来自研究，不因为两个动作画在相邻列就认定因果。当前流程与未来设想分别绘制。
什么时候适合用
适合设备加服务、跨团队交接或现场异常多的产品。需要明确一个用户群、一个具体任务场景和流程范围；现场证据不足时先画带未知的草图，不替客户编一条顺畅旅程。单零件静态强度分析不宜优先用它。
一张图看懂结构
依据本档案的输入、步骤与产物生成；卡片按档案顺序排列，具体依赖以“承接”标注为准，不强制串行。未表示实际运行已完成。
结束时带走
产品服务蓝图
需求补充与验证输入
- 01界定场景与协作角色
场景与状态边界
起点或独立准备 - 02整理用户动作与证据
用户动作与来源账
承接：界定场景与协作角色 - 03补前台后台和支持泳道
带泳道与交接的蓝图
承接：整理用户动作与证据 - 04探索异常与整体负担
痛点、潜在需求与代价清单
承接：补前台后台和支持泳道 - 05共同核对并交接验证
核对记录、需求与验证任务
承接：探索异常与整体负担
一步一步怎么做
01界定场景与协作角色
场景与状态边界
选定一类用户的一次任务，说明起终点、目标和参与角色。
到这里，先判断
是在描述当前流程，还是设计未来流程？
本步产物：场景与状态边界
检查：当前与未来不混画
何时返回或停下：无法确定用户和场景时暂停。
02整理用户动作与证据
用户动作与来源账
将观察过的动作按任务阶段排列，未观察的步骤明确留空。
到这里，先判断
哪些来自原话或日志，哪些是工作假设？
本步产物：用户动作与来源账
检查：不虚构耗时
何时返回或停下：没有一手资料只输出调研提纲。
03补前台后台和支持泳道
带泳道与交接的蓝图
为动作补可见接触、后台支持与接触凭据，核对交接依赖。
到这里，先判断
每次交接的责任与对象是否明确？
本步产物：带泳道与交接的蓝图
检查：相邻步骤不自动代表依赖
何时返回或停下：关键后台无人能说明时标未知。
04探索异常与整体负担
痛点、潜在需求与代价清单
沿故障、清洗、耗材和接管路径走查，提出可研究改进。
到这里，先判断
改善前台是否把成本转嫁给后台？
本步产物：痛点、潜在需求与代价清单
检查：正常与异常均需追踪
何时返回或停下：无证据不能估计收益。
05共同核对并交接验证
核对记录、需求与验证任务
由相关角色复核图，选取关键交接与负担设想做验证。
到这里，先判断
分歧与待确认责任有没有保留？
本步产物：核对记录、需求与验证任务
检查：客户确认与AI建议分开
何时返回或停下：未经观察验证不宣布优化成功。
如何理解结果
产物是哪些接触点依赖谁、交接什么以及哪里缺证的协同图。看见后台步骤不等于客户愿意付费；减少某个前台动作也可能增加后台负担，需合计人员、等待、错误恢复与维护条件。
例子与使用边界
跟着例子走一遍（教学示例）
平台教学设想：一次割胶班次分为领取设备、到树位、安装校准、作业、异常接管、清洗归还。操作者在前台确认树况；后台要有刀具状态、耗材和维护支持。若胶液混屑，图中追问谁判定污染、谁更换收集件、谁承担停机和复装检查。以上不是现场访谈结论，等待观察确认；不能预填耗时和成本。
容易走偏的地方
把理想SOP当真实当前流程；只画APP触点，漏掉搬运清洗；用平均作业时间遮住故障恢复；把服务凭据与来源证据混为一谈。反例：单个刀口尺寸优化应转工程分析，蓝图只提供使用约束。
怎样检查与验证
让实际操作、维护与管理角色分别回看流程，检验正常与异常路径能否走通。记录观察时间、角色原话、争议和未观察步骤。改进方案需要在真实或受控模拟中验证全周期负担，而非画完图即宣称效率提升。
用这些情境检查你的理解
以下为检查设想，未表示真实试验已经执行。
关键输入缺失
明确追问或输出待确认，不伪造输入。
例子被用于真实工程选型
回到真实工况、证据和专业审查，不把教学假设当实测。
把责任落到蓝图表
这是平台构造的教学回放，角色均待实际任命，不是客户现场记录。它展示“提交、接单、处理、恢复”为什么必须是不同责任与证据状态。
可见接触后台责任支撑与证据失败与恢复
| 用户事件 | 可见接触 | 后台责任 | 支撑与证据 | 失败与恢复 |
|---|---|---|---|---|
| 报异常 | 已提交，不宣称已接单 | 接单协调角色 | 队列、时间与接收身份 | 无人接单则升级协调 |
| 等待处理 | 显示当前责任与未决 | 维护分派角色 | 工单与资源状态 | 资源不足保留未决，不自动结案 |
| 维护记录完成 | 处理完，恢复待核 | 维护执行角色 | 范围与状态记录 | 缺实际状态则回核查 |
| 请求恢复 | 显示恢复审查状态 | 恢复授权角色 | 实际状态与授权依据 | 不得用维护完成按钮代授权 |
可以接着用哪些方法
平台适配说明
平台按机器人任务补入装卸、校准、清洗和人工退出等提问，仅作为待核场景。新增touchpoint、handoff、owner、exception、evidence_refs字段；五步编排是指南与本平台任务管理的组合适配。
原典与依据
服务蓝图是成熟服务设计工具；本条核读NN/g的定义与五步指南。它适用于产品周围的服务系统，但不把这两篇指南当作服务蓝图的最早原典，也不将其等同于完整PSS理论。
Service Blueprints: Definition
Nielsen Norman Group
核读位置：Key Elements、Lines、Secondary Elements
已读范围：网页相关正文核读
支持前台/后台/支持过程、可见性与接触凭据区分
The 5 Steps to Service Blueprinting
Nielsen Norman Group
核读位置：5-Step Framework、Best Practices
已读范围：网页相关正文核读
支持范围界定、研究驱动绘制与协作核对
尚待补证
两篇NN/g正文相关章节已核读；尚无本客户服务流程访谈、真实耗时或维修记录，无法给出ROI与最佳服务模式。需要核对客户如何采购、使用、维护及处理不适用树位。
调用与档案
此条目目前可检索、阅读；尚无对应的执行契约，不代表可直接自动执行。
{
"name": "method_supplement_get",
"arguments": {
"method_id": "R50"
}
}完整研究档案
结构字段和原始资料单独保留，便于复核与开发调用。