Q4.05.1frontstage-backstage service blueprint设计研究
蓝图连接前台体验与后台流程
别名: 服务蓝图前台后台 · 可见线 · 互动线
概念解释
用户只看见取件柜打开，看不见谁在截单之后改了库存、谁在超时后关掉了柜门权限。服务蓝图（service blueprint）把同一时间线上的前台动作与后台流程画在一起，中间用可见线（line of visibility）分开：线上是顾客能遇到的互动，线下是支撑这些互动的内部步骤与系统。它不是把用户旅程再画一遍，而是给旅程补上「那一步之所以发生，后台当时在做什么」。
机制
体验在前台断裂时，原因常常已经在线下走完：库存同步滞后、权限未下发、工单还在另一个班次。只画前台，断裂表现为用户笨或界面差；接上后台，才能看到触发条件。可见线迫使团队承认：有些失败用户无法从界面自救，因为决定权不在那块屏幕上。蓝图的横向是时间，纵向是层级（顾客行为、前台员工、后台员工、系统），格子的对齐才是主张——声称某次开门依赖某次库存写回，就必须把这两格上下对齐。
怎么研究
选一次已观察的完整服务事件，把前台时间线钉死后，向各部门收集同一时间窗内的内部步骤与系统日志，检查能否对齐。对不齐的格子标为未知，而不是用「应该有这一步」填上。比较「仅旅程图」与「旅程+对齐后台」对同一失败的归因。因变量包括可对齐的后台步比例、仅靠前台无法解释的失败数。
边界
纯自助、几乎无内部工序的数字产品，蓝图会画成稀薄的系统层，收益有限，界面状态图可能更合适。内部工序高度保密或涉及安全作业时，可见线以下只能画到允许暴露的粒度，不能为了完整去刺探。蓝图也不自动等于组织架构图：同一格子里的人可能属于不同部门，连接的是活动而非汇报线。
怎么落地
- 先钉前台时间线，再请各执行团队在对应时刻填写自己当时做的事，禁止体验组代填后台。
- 每一前台关键动作至少对齐一格支撑活动或系统事件；对不齐就标未知，不编造。
- 用可见线检查：用户抱怨的那一步，决定权是否在线下方。是，则改界面救不了，要改流程或系统。
- 验收：拿一次新的现场事件，看蓝图能否指出当时后台应处于哪一格。指不出，图还只是前台旅程。