AI 扩展计划 / Playbooks
AI Service Blueprint / Customer Journey / Trust Playbook
以下来源是本文的设计锚点。本文把它们转译为金融零售 AI 的服务设计、信任校准、运营控制和架构证据要求。访问日期按 2026-06-29 记录。
700 行AI_SERVICE_BLUEPRINT_CUSTOMER_JOURNEY_TRUST_PLAYBOOK.md
AI Service Blueprint / Customer Journey / Trust Playbook
定位: 面向 AI PM / AI BA / Product Architect / Enterprise Architect / Service Design Lead / CX / Risk / Operations, 把 AI customer journey 和 service blueprint 升级为可运营、可审计、可治理的信任校准系统。
目标: 用 service blueprint 把 customer action、frontstage AI、frontstage human、backstage workflow、data / knowledge / model、controls / evidence 和 metrics 串起来, 让 AI 体验设计不止停留在界面流程, 而能覆盖失败模式、人工交接、投诉申诉、数据控制和架构边界。
核心观点: AI service blueprint 不是普通 journey map 的加长版。它是一张把客户体验、员工动作、模型能力、知识来源、风险控制、审计证据和运营指标放在同一张图上的设计与治理工件。
重要说明: 本文是学习、作品集和内部方案训练材料, 不构成法律意见、合规结论、审计意见、模型验证报告或监管解释。正式项目必须由 Legal、Compliance、Risk、Model Risk、Fair Lending、Privacy、Security、Accessibility、Operations、Customer Experience、Business Owner 和管理层结合机构类型、司法辖区、客户影响和内部政策确认。
1. Source Anchors
以下来源是本文的设计锚点。本文把它们转译为金融零售 AI 的服务设计、信任校准、运营控制和架构证据要求。访问日期按 2026-06-29 记录。
| Anchor | Official / primary source | 本文使用方式 |
|---|---|---|
| NN/g Service Blueprints | https://www.nngroup.com/articles/service-blueprints-definition/ | 用 blueprint lanes 区分 customer actions、frontstage actions、backstage actions、support processes 和 evidence, 并扩展到 AI data / model / controls。 |
| NN/g Customer Journey Mapping | https://www.nngroup.com/articles/customer-journey-mapping/ | 用 journey map 识别客户目标、触点、情绪、痛点和机会, 但不把它误当成 AI 运营蓝图。 |
| Microsoft Guidelines for Human-AI Interaction | https://www.microsoft.com/en-us/research/publication/guidelines-for-human-ai-interaction/ | 用 18 条 Human-AI Interaction guidelines 组织 expectation setting、uncertainty、correction、feedback、control 和 adaptation。 |
| Google People + AI Guidebook | https://pair.withgoogle.com/guidebook/ | 用 mental model、user value、explainability、feedback、control 和 trust calibration 设计 AI 体验。 |
| NIST AI Risk Management Framework | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 把 journey 风险转成 AI governance、controls、evidence、monitoring 和 improvement loop。 |
Standards-to-artifacts:
| Source lens | 可以产出的 artifact | 高级面试表达 |
|---|---|---|
| Customer Journey Mapping | AI journey map、trust moment map、pain point to control matrix | "我先看客户任务和信任转折点, 再决定 AI 放在旅程哪里。" |
| Service Blueprint | AI service blueprint canvas、frontstage / backstage responsibility map | "我会把客户看到的 AI 回复和后台知识、模型、审批、队列、证据连接起来。" |
| Human-AI Interaction Guidelines | uncertainty copy spec、correction path、feedback taxonomy、control inventory | "我不只设计回答, 还设计不确定、纠错、拒绝、转人工和恢复。" |
| Google PAIR | mental model card、explainability plan、trust calibration checklist | "我的目标不是让用户盲目信任 AI, 而是让信任程度匹配证据和风险。" |
| NIST AI RMF | AI journey risk register、release evidence pack、monitoring dashboard | "我用 RMF 的生命周期语言证明 AI 体验可以被治理和审计。" |
2. One-Sentence Positioning
AI Service Blueprint 是一张把客户旅程、AI 接触点、人工角色、后台流程、知识与模型、风险控制、审计证据和运营指标连接起来的服务架构图, 用来校准客户和员工对 AI 的信任, 并确保每个 AI 触点在成功、失败、升级、申诉和持续改进场景下都有明确责任边界。
一句话公式:
AI Service Blueprint =
Customer Journey
+ Frontstage AI / Human Interaction
+ Backstage Workflow
+ Data / Knowledge / Model Supply Chain
+ Controls / Evidence / Metrics
+ Recovery, Complaint and Appeal Paths
对已具备 CBAP 背景的人, 重点不是再学习如何画基础 journey map。更有价值的是回答这些问题:
- AI 在客户旅程中改变了哪些信任关系?
- 哪些触点需要 explain、uncertainty、handoff、correction、appeal 或 memory consent?
- 前台一句 AI 回复背后依赖哪些知识源、模型版本、policy rule、人工队列和审计证据?
- 当 AI 产生错误、过期、越权或模棱两可的内容时, 服务系统如何恢复?
- 如何证明 journey 不是体验图, 而是可以上线、运营、监控和复盘的服务能力?
3. AI 服务蓝图为什么不是普通 Journey Map
普通 customer journey map 通常回答:
客户是谁?
客户想完成什么任务?
客户经历哪些阶段和触点?
每个阶段有什么痛点、情绪和机会?
AI service blueprint 还必须回答:
AI 在哪里参与?
AI 扮演回答者、推荐者、摘要者、决策支持者、执行者还是路由者?
客户和员工应该相信 AI 到什么程度?
AI 输出依据哪些数据、知识、模型、规则和人工判断?
不确定、冲突、过期、越界或失败时系统怎么处理?
谁能纠正、覆盖、升级、回滚、申诉和关闭自动化?
哪些证据能证明控制真实运行?
3.1 Journey map 和 AI service blueprint 的差异
| 维度 | 普通 journey map | AI service blueprint |
|---|---|---|
| 核心对象 | 客户体验、触点、情绪、痛点 | 客户体验 + AI 能力 + 人工角色 + 后台流程 + 控制证据 |
| 视角 | 主要是客户前台体验 | 横跨前台、后台、数据、模型、运营和治理 |
| 重点 | 用户目标和 friction | 信任校准、失败恢复、责任边界、证据链 |
| 输出 | 机会点、体验改进、触点优化 | 服务设计、架构边界、控制设计、监控指标、运营 runbook |
| AI 风险 | 容易被简化为 "AI 回答是否好" | 识别 hallucination、stale knowledge、wrong policy、automation bias、handoff overload |
| 适用评审 | CX / Product / Design | CX / Product / Architecture / Risk / Ops / Audit / Model Risk |
3.2 AI 让 journey map 失效的五个原因
| 原因 | 表现 | Blueprint 需要补上的内容 |
|---|---|---|
| AI 输出不完全确定 | 同一问题可能因上下文、检索、模型版本产生不同回答 | answerability、source trace、uncertainty rule、eval coverage |
| AI 依赖后台知识质量 | 前台体验受知识库版本、政策生效日期、权限过滤影响 | knowledge owner、freshness SLA、retrieval log、source effective date |
| AI 改变责任感知 | 客户可能把 AI 回复理解为正式承诺, 员工可能把建议当成结论 | AI identity、role boundary、consequence disclosure、human accountability |
| AI 失败不是单点失败 | 错误可能来自 intent、检索、规则、模型、UI、人工队列或下游系统 | failure-mode walkthrough、root cause taxonomy、incident evidence |
| AI 信任需要动态校准 | 目标不是提高信任, 而是让信任与证据、风险和可逆性匹配 | trust moments、control strength、appeal and recovery path |
3.3 三层视角
Journey layer
客户目标、场景、触点、痛点、情绪、下一步
Service blueprint layer
frontstage AI、frontstage human、backstage workflow、support systems、evidence
AI trust and control layer
data / knowledge / model lineage、policy guardrails、human oversight、audit trace、metrics
高级 BA / PM / Architect 的价值在第三层: 把体验问题转成可实现的系统边界和可运营的控制。
4. Blueprint Lanes
AI service blueprint 的 lanes 不应只复制传统 service blueprint。金融零售 AI 至少需要七条 lane:
- customer action
- frontstage AI
- frontstage human
- backstage workflow
- data / knowledge / model
- controls / evidence
- metrics
4.1 Lane 1: Customer Action
| 设计问题 | 要捕捉的内容 | 金融零售例子 |
|---|---|---|
| 客户真实任务是什么 | 查询、解释、纠错、申请、投诉、申诉、确认、退出 | 客户想知道一笔费用为什么收取, 而不是只问 "费用政策是什么" |
| 客户处于什么风险状态 | 普通服务、账户问题、欺诈、信贷、困难援助、投资边界 | 客户说 "这笔交易不是我做的" 应进入 dispute / fraud 路径 |
| 客户是否知道 AI 参与 | AI 自助、AI-assisted human、人工、系统通知 | 移动银行页面说明回复由 AI 生成并由政策来源支持 |
| 客户如何表达不信任 | 重问、反驳、要求人工、投诉、沉默退出 | 客户连续两次质疑退款承诺, 应升级而不是继续生成答案 |
Customer action lane 不应只写行为动词。它要记录客户意图、风险、信任状态和服务权利。
4.2 Lane 2: Frontstage AI
| AI 行为 | 可接受边界 | 不可接受边界 |
|---|---|---|
| Answer | 回答公开或账户事实, 引用权威来源 | 无来源解释费用、信贷原因、投诉结论或投资建议 |
| Clarify | 请求必要信息, 说明为什么需要 | 反复追问已提供信息, 或要求超出目的的数据 |
| Summarize | 总结客户问题、案件历史、文档证据 | 把摘要写成最终判断或正式承诺 |
| Recommend next step | 推荐安全、可逆、流程内的下一步 | 推荐高影响动作且未说明后果 |
| Refuse or bound | 说明不能处理的原因和可用渠道 | 用模糊免责声明阻断客户 |
| Escalate | 带上下文转人工或专家 | 只给按钮, 不传递上下文和 SLA |
Frontstage AI lane 必须记录 AI identity、capability boundary、uncertainty behavior、source display、control affordance 和 recovery path。
4.3 Lane 3: Frontstage Human
| 人工角色 | 典型职责 | AI blueprint 要说明的边界 |
|---|---|---|
| Contact center agent | 解释政策、处理服务请求、识别投诉和欺诈 | 可使用 AI 草稿, 但必须确认事实和合规话术 |
| Branch / relationship staff | 面对面解释、身份验证、资料收集 | 不应把 AI 生成内容直接视为正式审批 |
| Underwriter / credit analyst | 审核材料、解释原因、做人工判断 | AI 可做材料摘要和政策匹配, 不自动做最终信贷决定 |
| AML / KYC analyst | 审核风险信号、补充调查、记录 rationale | AI 可汇总证据, 不替代 SAR / KYC 结论 |
| Complaint handler | 分类、调查、回应、补救和申诉处理 | AI 可整理时间线, 不关闭客户救济路径 |
| Supervisor / maker-checker | 审批例外、复核高风险动作、处理升级 | 需要看到 AI trace、人工编辑和理由记录 |
Frontstage human lane 的核心不是 "human in the loop" 口号, 而是明确人在何处拥有 approve、edit、reject、override、escalate、rollback 和 customer communication 权限。
4.4 Lane 4: Backstage Workflow
| Backstage workflow | Blueprint 中必须暴露的内容 | 风险 |
|---|---|---|
| Identity and entitlement | 认证状态、权限、账户范围、代表权限 | 未授权披露账户信息 |
| Case creation | case ID、类型、队列、SLA、owner | 客户以为已投诉, 实际只是聊天记录 |
| Policy decision | 哪些规则决定 answer / refuse / escalate / block | AI 越权解释政策或漏掉强制升级 |
| Queue routing | 目标队列、优先级、负载、技能要求 | handoff overload 或错误队列 |
| Maker-checker | 需要双人复核的动作和阈值 | 高影响动作缺少复核 |
| Remediation | 更正记录、退款、通知、申诉、再开案 | 错误发生后无法恢复 |
| Knowledge update | 反馈、缺口、审批、发布、回归测试 | 一线纠错没有进入知识库 |
Backstage lane 让服务设计从 "客户看到什么" 变成 "组织如何兑现承诺"。
4.5 Lane 5: Data / Knowledge / Model
| 子系统 | 需要记录 | 设计问题 |
|---|---|---|
| System of record | 核心银行、卡系统、CRM、case management、decision system | AI 是否只读? 是否可写入? 写入前谁批准? |
| Knowledge base | 政策文档、FAQ、流程手册、监管话术、产品条款 | owner 是谁? 生效日期是什么? 何时失效? |
| Retrieval layer | index version、source ID、chunk metadata、permission filter | 是否能证明回答引用了允许使用的来源? |
| Model layer | model version、prompt version、temperature、routing、fallback | 版本变更是否影响客户承诺和解释一致性? |
| Tool layer | 可调用工具、限额、confirmation、rollback、error handling | 哪些工具动作需要人工审批? |
| Memory layer | 会话记忆、偏好记忆、长期记忆、consent、retention | 客户是否同意 AI 记住偏好或历史? 是否可撤回? |
| Eval layer | golden set、failure set、regression、slice metrics | journey 中的信任时刻是否被测试覆盖? |
AI service blueprint 需要把 "前台一句话" 追溯到数据和模型供应链。没有这个 lane, trust design 会变成文案设计。
4.6 Lane 6: Controls / Evidence
| Control | Evidence | 适用场景 |
|---|---|---|
| AI identity disclosure | disclosure text version、channel、timestamp | 所有客户可见 AI |
| Source grounding | source ID、effective date、retrieval trace | 政策解释、费用解释、信贷解释、KYC 指引 |
| Uncertainty action | clarify / abstain / escalate / block decision log | 低置信、来源冲突、资料缺失 |
| Human approval | approver、role、time、diff、reason code | 高影响动作、正式通知、例外处理 |
| Handoff package | intent、context、AI answer、sources、risk tag、case ID | 转人工、投诉、欺诈、困难援助 |
| Complaint capture | complaint trigger、case type、acknowledgement、SLA | 客户表达不满、损害、监管关键词 |
| Appeal path | decision notice、appeal option、evidence bundle、owner | 信贷、账户限制、KYC 拒绝、争议处理 |
| Memory consent | consent scope、retention class、withdrawal event | 个性化服务、长期记忆、跨渠道连续体验 |
| Stop switch | scope、owner、reason、activation time | 严重幻觉、政策错误、数据泄露、队列失控 |
Controls / evidence lane 是让 blueprint 进入架构评审、风险评审和审计讨论的关键。
4.7 Lane 7: Metrics
| Metric family | 典型指标 | 解释 |
|---|---|---|
| Journey outcome | first contact resolution、case completion、repeat contact、time to resolution | 客户任务是否真正完成 |
| Trust calibration | evidence opened、uncertainty understood、over-reliance signal、under-trust signal | 用户是否在合适水平使用 AI |
| AI quality | groundedness、citation accuracy、unsupported claim rate、stale answer rate | AI 输出是否基于正确证据 |
| Handoff quality | warm handoff success、repeat-information rate、handoff SLA、queue abandonment | 人工交接是否真实有效 |
| Control usage | edit rate、reject rate、override rate、appeal rate、rollback rate | 人类控制是否被使用并产生信号 |
| Customer harm | complaint rate、misleading answer incidents、wrong denial support cases | 是否出现客户伤害 |
| Operations | backlog、AHT、QA defect、staff load、handoff overload ratio | AI 是否把问题转嫁给运营 |
| Governance | release gate pass rate、trace completeness、incident MTTR、knowledge freshness | 控制是否持续有效 |
指标要按 journey stage、channel、customer segment、language、product、risk tier 和 model / knowledge version 切片, 否则平均值会掩盖高风险失败。
5. Trust Moments
Trust moment 是客户或员工需要决定 "我是否应该相信 AI, 相信到什么程度, 下一步能不能行动" 的关键时刻。AI service blueprint 要把 trust moment 设计成控制点, 而不是宣传文案。
5.1 Trust moment overview
| Trust moment | 用户问题 | 设计输出 | 架构 / 运营支撑 |
|---|---|---|---|
| Explain | "AI 为什么这么说?" | 来源、理由、适用范围、下一步 | source trace、policy mapping、decision log |
| Uncertainty | "AI 可能错在哪里?" | 资料不足、来源冲突、低置信、需人工确认 | answerability check、conflict detection、fallback rule |
| Handoff | "我现在能找人吗?" | warm handoff、case ID、SLA、上下文传递 | routing、queue capacity、handoff package |
| Correction | "AI 说错了, 我怎么改?" | 纠错入口、字段修正、反馈分类、确认结果 | feedback workflow、record amendment、QA |
| Appeal | "我不同意结果怎么办?" | 申诉渠道、证据清单、处理时限、独立复核 | appeal workflow、case evidence、owner |
| Memory consent | "AI 会记住什么?" | 记忆范围、用途、保留、撤回 | consent service、retention、privacy controls |
| Regulated advice boundary | "这是建议、解释还是正式决定?" | 角色边界、禁止表达、人工路径 | policy engine、approved language、human review |
5.2 Explain
Explain 不是让 LLM 写一段看似合理的理由。金融零售里的 explain 应该区分四类:
| Explain type | 用途 | 例子 | 边界 |
|---|---|---|---|
| Source explanation | 说明答案来自哪里 | "该费用解释来自 2026-05-01 生效的账户条款第 4.2 节。" | 不得引用无权限、过期或内部敏感来源 |
| Process explanation | 说明下一步流程 | "提交争议后会创建 case, 团队会在服务时限内调查。" | 不承诺未批准的退款或结果 |
| Decision support explanation | 员工理解 AI 草稿或建议 | "摘要基于交易日志、客户通话记录和政策条款。" | 不替代正式审批理由 |
| Regulated decision explanation | 信贷、KYC、账户限制等解释 | "正式原因来自 decision system 的 reason code。" | LLM 不得自行推测 adverse action reason |
Good explain design 需要同时给客户可懂的解释和员工可审计的证据。两者信息深度不同, 但证据链必须一致。
5.3 Uncertainty
AI 不确定性应转成行动, 而不是只显示 "可能不准确"。
| Uncertainty trigger | Customer-facing behavior | Employee-facing behavior | System action |
|---|---|---|---|
| Source missing | 说明需要人工确认 | 显示 missing source 和查询位置 | abstain 或 route |
| Source conflict | 说明资料需要核对 | 显示冲突来源、版本、生效日期 | escalate to knowledge owner |
| Low intent confidence | 澄清客户意图 | 展示候选 intent 和置信差距 | ask clarify |
| Stale knowledge | 不给确定回答 | 显示 source age 和 freshness breach | block answer, create defect |
| Regulated boundary | 说明不能给该类建议 | 显示 prohibited output reason | refuse and route |
| High customer impact | 说明需要人工处理 | 强制 maker-checker 或 expert review | escalate |
不要把 "confidence score" 当成用户体验的核心。更好的做法是告诉用户: 哪个证据不足, 这意味着什么, 系统下一步做什么。
5.4 Handoff
Handoff 是服务系统能力, 不是按钮。
| Handoff element | 设计要求 | 失败信号 |
|---|---|---|
| Trigger | 用户要求人工、投诉、欺诈、低置信、来源冲突、高影响动作、语言或无障碍需要 | 客户反复表达不满仍被 AI 留在循环 |
| Target | 明确队列、技能、优先级、SLA | 所有转人工都进入普通客服 |
| Context package | 用户问题、身份状态、AI 回复、来源、不确定点、risk tag、case ID | 人工要求客户从头再说 |
| Customer promise | 告知下一步、等待方式、case reference | 客户不知道是否已进入正式流程 |
| Agent view | 高亮客户目标、失败原因、AI 已尝试内容 | 员工看不到 AI 上下文 |
| Monitoring | handoff success、repeat information、queue load、abandonment | 转人工量上升但解决率下降 |
5.5 Correction
Correction 设计要区分事实纠错、意图纠错、政策纠错和模型反馈。
| Correction type | 用户 / 员工动作 | 系统响应 |
|---|---|---|
| Fact correction | 客户指出交易、地址、金额、日期不对 | 验证后更正 case facts, 记录来源和时间 |
| Intent correction | 客户说 "不是查询, 我要投诉" | 重新分类并进入 complaint workflow |
| Policy correction | 员工发现 AI 引用了错误政策 | suppress response, create knowledge defect, notify owner |
| Draft correction | 员工编辑 AI 草稿 | 保留 diff、reason code 和 final sent version |
| Outcome correction | 发现错误影响客户结果 | 触发 remediation、客户通知和 incident review |
5.6 Appeal
Appeal 不能被藏在 FAQ 后面。涉及客户权益的 AI journey 要明确区分 "服务恢复" 和 "正式申诉"。
| 场景 | Appeal design |
|---|---|
| 信贷拒绝解释 | 展示正式通知、原因来源、可补充材料、重新审核路径和联系渠道 |
| KYC / AML 限制 | 在不泄露敏感规则的前提下说明可提供材料、处理渠道和服务限制 |
| 费用争议 | 创建 dispute / complaint case, 说明调查流程和沟通方式 |
| 账户冻结或关闭 | 提供允许范围内的说明、人工渠道、材料要求和升级路径 |
AI 可以帮助客户理解流程, 但不应替代正式申诉机制。
5.7 Memory Consent
AI 记忆能力会增强体验, 也会改变隐私和信任边界。
| Memory type | 例子 | Consent requirement | Control |
|---|---|---|---|
| Session memory | 当前对话里记住已验证交易和客户问题 | 会话内明确可见 | 清除会话、转人工时带上下文 |
| Preference memory | 客户偏好语言、联系方式、解释深度 | 明确用途和撤回路径 | 查看、修改、删除 |
| Case memory | 投诉、争议、KYC 案件的正式记录 | 按业务记录规则管理 | retention、access log、amendment |
| Personalization memory | 基于历史行为调整推荐或提示 | 需要用途限制和 opt-out | consent scope、policy enforcement |
| Employee workflow memory | 员工常用模板、队列偏好 | 员工可配置, 不影响客户权益 | admin control、audit |
5.8 Regulated Advice Boundary
金融零售 AI 最重要的 trust moment 经常是边界判断:
| 用户请求 | AI 可以做 | AI 不应做 |
|---|---|---|
| "我该买这个基金吗?" | 提供教育性信息、风险披露、引导持牌顾问 | 给个性化投资建议或暗示适合性 |
| "为什么我被拒贷?" | 引用正式 reason code 和通知信息 | 根据聊天内容猜测拒贷原因 |
| "我这个交易是不是诈骗?" | 引导安全步骤、冻结渠道、人工欺诈团队 | 保证是否诈骗或承诺损失结果 |
| "帮我绕过 KYC" | 拒绝并说明合规要求 | 提供规避建议 |
| "我想投诉" | 创建投诉或转投诉流程 | 把投诉当成普通咨询继续回答 |
6. Failure-Mode Walkthrough
AI service blueprint 必须包含 failure-mode walkthrough。原因很简单: 真实金融服务体验不是在 AI 答对时崩坏, 而是在 AI 似是而非、人工接不住、后台无证据时崩坏。
6.1 Hallucination
| Stage | Failure path | Controls |
|---|---|---|
| Customer action | 客户询问是否可免除某项费用 | AI 把费用解释为政策问题, 进入 source-grounded flow |
| Frontstage AI | AI 生成不存在的免除条件 | 强制 citation, 无来源不得回答具体资格 |
| Frontstage human | 员工直接复制 AI 回复 | 员工端显示 draft label、source required、send approval |
| Backstage workflow | 没有 case 或政策核查 | 高影响承诺需要 case type 和 supervisor approval |
| Data / model | RAG 未检索到有效来源, 模型补全 | answerability gate: no source -> abstain / handoff |
| Evidence | 缺少 source trace | audit log 记录 prompt、retrieval、output、sent version |
| Metrics | 短期 CSAT 高, 后续投诉上升 | unsupported claim rate、complaint after AI answer |
核心原则: 幻觉不是只靠 prompt 修复, 需要 source gating、UI copy boundary、human review 和投诉监控共同控制。
6.2 Wrong Policy
| Stage | Failure path | Controls |
|---|---|---|
| Customer action | 客户询问新产品费用或地区性规则 | 捕捉 product、region、effective date |
| Frontstage AI | 引用旧政策或错误地区政策 | 展示 source effective date 和 jurisdiction |
| Backstage workflow | 政策变更未同步知识库 | policy owner sign-off、freshness SLA、release calendar |
| Data / knowledge | index 包含旧版本并高排名 | versioned knowledge, expired source suppression |
| Controls | 无法区分有效与历史文档 | metadata required: status、effective_from、retired_at |
| Metrics | 线上答案准确率平均正常, 新政策问题错误高 | policy-change slice eval、stale answer rate |
核心原则: Wrong policy 通常是 knowledge governance 失败, 不是模型能力不足。
6.3 Stale Knowledge
| Stage | Failure path | Controls |
|---|---|---|
| Customer action | 客户问 "最新费率" 或 "当前资格" | 识别 time-sensitive intent |
| Frontstage AI | 用旧 FAQ 回答 | time-sensitive answer requires current source |
| Backstage workflow | 知识源没有 owner 和更新时间 | knowledge owner、review cadence、expiration rule |
| Data / knowledge | 文档缺少生效日期和失效日期 | mandatory metadata and ingestion validation |
| Evidence | 审计只能看到模型版本, 看不到知识版本 | log knowledge index version and source timestamp |
| Metrics | 同一类问题重复被纠错 | freshness breach count、knowledge defect closure time |
核心原则: 对时间敏感问题, "有引用" 不等于可信, 还要证明来源有效。
6.4 Automation Bias
| Stage | Failure path | Controls |
|---|---|---|
| Employee action | 员工在队列压力下接受 AI 草稿 | 默认需要查看关键证据后才能发送 |
| Frontstage AI | 草稿语气权威, 像正式结论 | 标注 recommendation / draft, 禁止结论式 UI |
| Backstage workflow | accept 按钮比 edit / reject 更突出 | balanced controls, require reason for high-risk accept |
| Data / model | 模型漏掉少数群体或例外情况 | slice eval、challenge set、fairness review |
| Controls | 没有记录员工是否看过证据 | evidence-open-before-approve event |
| Metrics | 采纳率高但 QA 缺陷上升 | accept-without-edit、material edit rate、QA critical defect |
核心原则: Automation bias 是 UI、运营压力和责任边界共同造成的, 不能只靠员工培训。
6.5 Handoff Overload
| Stage | Failure path | Controls |
|---|---|---|
| Customer action | AI 遇到边界就大量转人工 | 分层 trigger, 低风险澄清, 高风险升级 |
| Frontstage AI | 频繁说 "我无法处理" | refusal copy includes next best action |
| Frontstage human | 人工队列暴增, 等待时间变长 | capacity model、priority queue、skill routing |
| Backstage workflow | 转人工包缺少上下文, 员工重新询问 | mandatory handoff package |
| Data / model | 低质量 intent classifier 误判高风险 | intent confusion monitoring、routing QA |
| Metrics | handoff 量升高但解决率降低 | handoff success、repeat-information rate、queue SLA |
核心原则: 强化边界会增加 handoff, 所以 blueprint 必须同时设计队列容量、分流规则和上下文传递。
7. Financial Retail Case: 客服 / 投诉 / 信贷解释 / AML KYC AI Journey
下面用一个组合案例展示如何把 AI journey、service blueprint、trust moments 和 controls 连接起来。
7.1 Case context
场景: 一家区域银行上线 AI service assistant, 覆盖移动银行、客服坐席和后台运营。首批场景包括:
- 客服: 账户费用、交易状态、卡片问题和服务请求。
- 投诉: 客户表达不满、损失、误导、服务失败或监管关键词。
- 信贷解释: 客户询问信贷申请状态、材料缺口和拒绝原因。
- AML / KYC: 客户询问账户限制、补充材料和身份核验进度, 员工使用 AI 汇总 KYC case。
设计原则:
| 原则 | 含义 |
|---|---|
| 服务入口统一, 风险路径分流 | 客户可从同一 assistant 开始, 但后台按风险和意图进入不同流程 |
| AI 回答低风险事实, 不替代高影响决定 | AI 可解释流程和公开信息, 不做信贷、AML、投诉最终结论 |
| 每个高风险触点都有人工路径 | 投诉、欺诈、信贷、账户限制必须可升级 |
| 每个正式服务承诺都有证据 | case ID、source、SLA、owner、audit trace |
7.2 Journey stage blueprint
| Stage | Customer action | Frontstage AI | Frontstage human | Backstage workflow | Data / knowledge / model | Controls / evidence | Metrics |
|---|---|---|---|---|---|---|---|
| Discover | 客户打开移动银行 assistant | 说明 AI 身份、可处理事项、人工入口 | 无 | channel context、auth status | disclosure copy version | AI identity shown | AI disclosure comprehension、dismiss rate |
| Ask service question | 客户问 "为什么收了月费" | 查询账户事实和费用政策, 给来源和下一步 | 坐席可查看同样来源 | fee inquiry flow | account system + fee policy | source ID、effective date | groundedness、repeat contact |
| Express dissatisfaction | 客户说 "这太离谱, 我要投诉" | 识别 complaint trigger, 创建或转投诉流程 | 投诉专员接收摘要 | complaint case creation | complaint taxonomy + transcript | case ID、acknowledgement | complaint capture recall、handoff SLA |
| Credit explanation | 客户问 "为什么被拒" | 说明只能基于正式通知和 reason code 解释 | 信贷专员处理复杂问题 | credit status and notice lookup | decision system reason code | no LLM-generated reason | adverse explanation accuracy、appeal rate |
| KYC restriction | 客户问 "为什么账户被限制" | 提供允许范围内的流程说明和材料路径 | KYC team 处理材料 | KYC case workflow | KYC case status + policy | restricted disclosure rule | KYC completion time、policy breach |
| Employee assist | 员工打开 case copilot | AI 总结事实、来源和待核查点 | 员工编辑、批准或拒绝 | case review workflow | RAG + case history + model | diff、approval、reason code | accept-without-edit、QA defects |
| Handoff | 客户要求人工或系统判定升级 | warm handoff with context | 坐席看到 AI trace 和客户目标 | queue routing and SLA | context package | handoff event、target queue | repeat-information rate、abandonment |
| Recovery | 客户指出 AI 错误或结果不公 | 接受纠错, 创建更正或申诉路径 | 人工复核和补救 | remediation / appeal workflow | audit trace + case evidence | correction log、appeal case | recovery time、repeat complaint |
7.3 Customer service AI journey
| Touchpoint | Trust moment | Good design | Bad design |
|---|---|---|---|
| Fee explanation | Explain | 展示费用名称、账户事实、政策来源和生效日期 | "通常银行会收取..." 这种泛化回答 |
| Transaction status | Uncertainty | 如果交易状态未同步, 说明更新时间和人工路径 | 猜测交易最终结果 |
| Service request | Consequence | 确认创建 case 的后果和是否影响账户 | 客户以为提交后立即完成处理 |
| Agent assist | Correction | 坐席可编辑 AI 草稿并记录修改原因 | 一键发送, 无 diff 和 source |
7.4 Complaint AI journey
| Touchpoint | Trust moment | Good design | Control |
|---|---|---|---|
| Complaint detection | Regulated boundary | AI 识别 "投诉、损失、误导、没人处理、我要举报" 等表达 | complaint intent recall threshold |
| Acknowledgement | Explain | 明确已创建投诉 case, 给 reference 和下一步 | complaint case ID |
| Handoff | Handoff | 把客户问题、AI 已答内容、附件和情绪信号传给投诉队列 | warm handoff package |
| Response drafting | Human control | AI 可整理时间线, 投诉专员决定正式回应 | maker-checker for formal response |
| Appeal | Appeal | 客户不接受结果时有升级渠道 | appeal owner and SLA |
7.5 Credit explanation AI journey
| Touchpoint | Trust moment | Good design | Boundary |
|---|---|---|---|
| Application status | Explain | 从信贷系统读取状态, 不用 LLM 猜测 | source of record only |
| Missing documents | Correction | 客户上传材料后更新 checklist | document ingestion trace |
| Decline explanation | Regulated advice boundary | 只引用正式 notice 和 reason code | no generated adverse reason |
| Next steps | Appeal | 告知可补充材料或重新申请路径 | approved language |
| Employee copilot | Automation bias | underwriter 看到 evidence, AI 草稿不可直接变成最终决定 | human final decision |
7.6 AML / KYC AI journey
| Touchpoint | Trust moment | Good design | Boundary |
|---|---|---|---|
| Customer asks restriction reason | Explain with limits | 说明需要完成核验或补充材料, 不披露敏感监控规则 | restricted disclosure policy |
| Document request | Consequence | 明确需要哪些材料、用途和上传渠道 | privacy notice and data minimization |
| Analyst summary | Explain | AI 汇总交易、文档和 case history, 显示来源 | evidence citation required |
| Analyst decision | Human control | AI 不决定 KYC 是否通过或是否提交 SAR | analyst rationale and approval |
| Customer escalation | Appeal / complaint | 提供服务渠道和允许范围内的申诉路径 | case owner and audit trail |
7.7 Architecture control view
Customer / Employee Channel
-> Identity, consent and entitlement check
-> Intent and risk classifier
-> Policy boundary engine
-> Evidence retrieval and system-of-record lookup
-> Answerability and freshness check
-> Model response / summary / draft
-> Trust moment renderer
explain, uncertainty, controls, handoff, correction, appeal
-> Human workflow gateway
approve, edit, reject, override, route, rollback
-> Audit, metrics and feedback loop
| Component | Owner | Evidence |
|---|---|---|
| Intent and risk classifier | AI Product + CX + Risk | confusion matrix、high-risk recall、routing QA |
| Policy boundary engine | Product Architect + Compliance | rule version、decision log、approved language |
| Evidence layer | Data / Knowledge Owner | source ID、effective date、permission filter、retrieval trace |
| Model and prompt layer | AI Platform | model version、prompt version、eval report |
| Human workflow gateway | Operations | queue、SLA、approval、override log |
| Audit and observability | Architecture + Risk + Audit | trace ID、events、retention class、dashboard |
8. Artifact Templates
这些模板适合放入作品集、PRD 附录、architecture review 或 risk checkpoint。每个模板都给出具体字段和金融零售例子, 避免只有空表。
8.1 AI Service Blueprint Canvas
| Canvas field | 填写要点 | 示例: 信贷拒绝解释 assistant |
|---|---|---|
| Use case and channel | 场景、渠道、客户或员工角色 | 移动银行客户询问信贷申请拒绝原因 |
| Customer goal | 客户想完成的真实任务 | 理解拒绝原因, 知道是否能补充材料或申诉 |
| Risk tier | 客户权益、合规、可逆性、自动化程度 | 高影响解释场景, 不允许 LLM 自行生成原因 |
| Journey stages | 从进入、提问、解释、转人工、申诉到恢复 | ask status -> view notice -> explain reason -> human escalation -> appeal |
| Customer actions | 每阶段客户动作、信任状态、情绪 | 客户质疑 "这是不是歧视" |
| Frontstage AI | AI 说什么、显示什么、不能说什么 | 引用正式 notice 和 reason code, 不猜测额外原因 |
| Frontstage human | 人工在哪里接管、如何复核 | 信贷专员处理复杂解释和材料补充 |
| Backstage workflow | case、队列、审批、通知、SLA | credit service case, appeal route, supervisor review |
| Data / knowledge / model | 系统事实、知识源、模型、prompt、工具 | decision system、adverse action notice、approved explanation copy |
| Trust moments | explain、uncertainty、handoff、appeal | "这是否正式决定" 和 "我不同意怎么办" |
| Controls | guardrails、human oversight、stop switch | reason code only, no generated adverse reason, human escalation |
| Evidence | logs、sources、approval、trace | trace ID、notice ID、source version、handoff record |
| Metrics | outcome、quality、risk、ops | explanation accuracy、appeal completion、complaint after AI answer |
8.2 Trust Moment Checklist
| Checklist item | Strong answer | Weak answer |
|---|---|---|
| AI identity | 客户知道当前是 AI、自助 AI-assisted human 还是人工 | 只在条款里写 AI 可能参与 |
| Capability boundary | AI 明确能处理和不能处理的任务 | "我可以帮您处理所有问题" |
| Evidence | 关键回答有来源、生效日期和适用范围 | 只有自然语言解释 |
| Uncertainty | 不确定会澄清、拒答、转人工或创建 case | 用 "可能" 继续猜 |
| Human handoff | 有触发条件、目标队列、上下文包和 SLA | 一个通用 "联系人工" 按钮 |
| Correction | 客户和员工能纠正事实、意图、政策和草稿 | 反馈只收满意度 |
| Appeal | 高影响结果有申诉、复核或材料补充路径 | 客户被引回 FAQ |
| Memory consent | 说明 AI 记住什么、为什么、多久、如何撤回 | 默认跨场景记忆 |
| Regulated boundary | 区分教育、解释、建议、决策和行动 | AI 把解释写成正式建议 |
| Evidence for audit | 每个高风险触点可追踪 source、version、actor、action、outcome | 只有聊天 transcript |
8.3 Handoff Design Sheet
| Field | 设计要求 | 示例 |
|---|---|---|
| Handoff trigger | 用户要求人工、投诉、欺诈、低置信、来源冲突、高影响动作 | 客户说 "我要正式投诉" |
| Risk tag | 服务、投诉、欺诈、信贷、KYC、困难援助、脆弱客户 | complaint_high_priority |
| Target queue | 明确团队、技能、优先级和 SLA | Complaint Ops Tier 2, same business day acknowledgement |
| Context package | intent、summary、AI responses、sources、missing info、customer sentiment | 客户质疑费用误导, AI 已引用 fee policy v2026-05 |
| Customer message | 告知已转接、case reference、下一步和等待方式 | "已创建投诉记录 C-2026-1842, 专员会按服务时限联系您。" |
| Agent view | 高亮客户目标、AI 不确定点、证据、下一步建议 | "AI 未确认费用豁免资格, 需要人工核查账户状态。" |
| SLA and ownership | 谁负责、何时响应、超时升级 | 4 business hours response, supervisor escalation at breach |
| Audit event | 记录 handoff 时间、目标、上下文、接收人、结果 | handoff_created, handoff_accepted, case_resolved |
| Metrics | handoff success、repeat-info、SLA、abandonment、resolution | repeat-information rate under 10% for warm handoff |
8.4 Journey Metric Tree
North Star
Safe and successful AI-assisted service completion
Outcome metrics
first contact resolution
case completion
time to resolution
appeal completion
Trust calibration metrics
evidence-open rate
uncertainty-to-action success
AI answer challenge rate
over-reliance signal
under-trust signal
Quality metrics
groundedness
citation accuracy
policy compliance
stale answer rate
unsupported claim rate
Handoff metrics
warm handoff success
repeat-information rate
queue SLA
abandonment after handoff
Risk and harm metrics
complaint after AI answer
wrong policy incidents
adverse explanation defects
privacy boundary breaches
remediation time
Operations metrics
agent handle time
backlog
QA defect rate
handoff overload ratio
knowledge defect closure time
Metric tree review rule:
| Review question | Good answer |
|---|---|
| 是否只看效率 | 同时看客户完成、质量、风险、信任和运营负载 |
| 是否能发现低频高伤害问题 | 对投诉、信贷、AML、KYC、脆弱客户单独切片 |
| 是否能追溯根因 | 指标按 source、model、prompt、channel、journey stage 关联 |
| 是否连接治理 | 指标触发 release restriction、knowledge fix、prompt rollback 或 human capacity action |
8.5 Blueprint Review Checklist
- 是否明确 AI 在每个 journey stage 的角色: answer、draft、recommend、route、summarize、act 或 refuse。
- 是否区分 customer-facing AI 和 employee-facing AI 的证据深度。
- 是否标出 explain、uncertainty、handoff、correction、appeal、memory consent 和 regulated boundary。
- 是否有 frontstage human 的 approve、edit、reject、override、rollback 和 escalation 权限。
- 是否能追溯每个高风险 AI 输出的 source、effective date、model version、prompt version 和 actor。
- 是否定义 stale knowledge、wrong policy、hallucination、automation bias 和 handoff overload 的控制。
- 是否把投诉和申诉作为正式服务路径, 而不是普通客服 fallback。
- 是否定义 handoff 的目标队列、上下文包、SLA 和成功指标。
- 是否把 memory consent、data minimization、retention 和 access logging 纳入设计。
- 是否能用指标证明 journey 改善没有牺牲客户权益和运营稳定性。
9. Interview Answers
Q1: 30 秒版本
AI service blueprint 不是普通 journey map。Journey map 主要看客户触点和痛点, blueprint 要把前台 AI、前台人工、后台流程、数据知识模型、控制证据和指标放在一张图里。对金融零售 AI, 关键是校准信任: 用户什么时候能相信 AI、什么时候要看到来源、什么时候必须转人工、如何纠错和申诉, 以及组织如何证明这些控制真实运行。
Q2: 2 分钟版本
我会先用 customer journey 找到客户任务、触点、情绪和信任转折点, 但不会停在体验层。AI 加入后, 一句前台回答背后可能涉及身份验证、权限、知识库版本、检索、模型、policy guardrail、人工队列和审计日志。所以我会把它扩展成 AI service blueprint。
这张 blueprint 至少有七条 lane: customer action、frontstage AI、frontstage human、backstage workflow、data / knowledge / model、controls / evidence 和 metrics。每个高风险触点都要标出 trust moment, 比如 explain、uncertainty、handoff、correction、appeal、memory consent 和 regulated advice boundary。
例如信贷拒绝解释场景, AI 不能根据聊天内容猜测拒绝原因, 只能引用正式 notice 和 reason code。客户不理解或不同意时, 必须有人工解释和申诉路径。员工侧可以用 AI 汇总材料, 但最终判断、override 和正式沟通需要人负责并留痕。上线后我会看 groundedness、stale answer、unsupported claim、handoff success、appeal completion、complaint after AI answer 等指标。这样 journey map 就从体验图变成可以评审、上线、运营和审计的服务设计工件。
Q3: CPO 版本
如果我是 CPO, 我会把 AI service blueprint 当作 AI 产品组合的体验和风险共同语言。它帮助团队避免两个极端: 一是只追求自动化率和成本下降, 导致客户在投诉、信贷、欺诈、KYC 等高风险场景被 AI 阻断; 二是所有不确定都转人工, 让 AI 失去效率价值并压垮运营队列。
我会要求每个客户可见 AI use case 在 release 前提交 blueprint evidence pack: AI 放在哪个 journey stage、影响哪些客户权益、哪些输出需要来源、哪些场景必须转人工、投诉和申诉如何进入正式流程、上线后用哪些指标监控客户伤害和运营负载。这样产品团队仍然可以快速创新, 但创新发生在清晰的 trust boundary 和 governance cadence 内。
我会特别关注四个指标组合: 业务结果、客户信任、风险控制和运营承载。只看 adoption 或 handle time 是不够的, 因为一个 AI assistant 可能处理更快但制造更多错误承诺和投诉。好的 blueprint 能让管理层看到速度、质量、风险和客户权益之间的真实权衡。
Q4: Design + Architecture 版本
从设计角度, AI service blueprint 解决的是 trust calibration。用户需要知道 AI 是谁、能做什么、不能做什么、依据是什么、错了怎么办、何时有人接手。每个 trust moment 都需要 UI copy、交互控件和恢复路径, 例如来源展示、不确定性说明、转人工、纠错、申诉和记忆 consent。
从架构角度, 这些体验不是静态文案, 而是系统能力。Explain 需要 source trace 和 policy mapping; uncertainty 需要 answerability check 和 conflict detection; handoff 需要 queue routing、context package 和 SLA; appeal 需要 case workflow 和 evidence bundle; memory consent 需要 consent service、retention 和 access log; regulated boundary 需要 policy engine 和 approved language。
所以我会在 architecture review 里展示一条控制链: identity and entitlement -> intent and risk classifier -> policy boundary engine -> evidence retrieval -> answerability and freshness check -> model response -> trust moment renderer -> human workflow gateway -> audit and monitoring。这个链路能证明 AI 不是一个聊天组件, 而是嵌入服务运营和风险治理的能力。
Q5: 常见追问
| 追问 | 简短回答 |
|---|---|
| 如何判断哪些触点必须人工接管? | 按客户影响、监管边界、可逆性、证据质量、模型不确定性和客户表达来分层。投诉、欺诈、信贷解释、KYC 限制、投资建议和脆弱客户信号通常需要强人工路径。 |
| 如何避免 handoff 把运营压垮? | 不把所有不确定都转人工, 而是设计 clarify、abstain、self-service evidence、tiered routing 和 capacity model。指标看 handoff success、repeat-information、SLA 和 backlog。 |
| 如何处理 AI 给错政策? | 先阻断或更正客户影响, 保留 trace, 创建 knowledge defect, 检查 source metadata 和 index version, 做 policy-change regression, 必要时 rollback prompt / index / model。 |
| 如何证明 trust calibration 有效? | 不只看 CSAT, 还看 evidence-open、uncertainty-to-action、AI challenge rate、unsupported claim、appeal completion、complaint after AI answer 和 automation bias 指标。 |
| BA 在这里的高级价值是什么? | 把流程、规则、例外、客户权益、人工判断点和证据要求翻译成 AI 控制、eval criteria、handoff design 和 audit event。 |
Final Operating Principles
- 先画 customer journey, 再用 service blueprint 暴露后台流程和 AI 控制。
- 不把 AI touchpoint 当成界面组件, 要把它当成服务系统中的责任节点。
- 信任目标不是更高, 而是更准: 证据强时可用, 证据弱时谨慎, 高风险时可转人。
- 每个 explain 都要有来源、范围、有效性和责任边界。
- 每个 uncertainty 都要变成 clarify、abstain、refuse、handoff 或 block。
- Handoff 必须带上下文、队列、SLA、owner 和成功指标。
- Correction、complaint 和 appeal 是核心 journey, 不是失败后的补救说明。
- Memory consent 是产品体验、隐私控制和信任承诺的交叉点。
- Data / knowledge / model lane 决定 AI 体验能否被证明。
- 一个成熟的 AI service blueprint 能同时服务 PM、Design、Architecture、Risk、Ops 和 Audit。
一句话收束:
好的 AI service blueprint 不是让 AI 旅程看起来顺滑,
而是让客户、员工和组织在每个关键时刻都知道:
AI 依据什么工作, 应该被信任到什么程度, 出错时谁接手, 以及证据如何留下。