01 / CONTEXT
解决什么问题，为什么值得做？
Klarna 在 2024 年 2 月公告中介绍，AI 助手在应用内支持支付、退款与退货等服务，首月处理 230 万次会话，覆盖多语言与全天候服务，同时保留人工渠道。公告还报告了重复咨询减少。学习重点是从“完成对话”推进到“问题得到处理”。
业务价值
常见问题更快处理，复杂问题带着上下文交给能解决的人。
- 协作角色
- 客户、客服专家、交易系统负责人、质量运营、FDE
02 / DISCOVERY
FDE 怎样把症状变成可解决的问题？
以下为结合案例设计的 FDE 实战推演，展示同类问题的排查与实施方法；公开团队的已披露做法见上方背景。
从再次来电倒查失败
演练把同一问题的多次联系串起来：是答案没说清、后台状态没变，还是人工接手丢了上下文？一段会话结束不应自动标为解决。
把服务意图与系统动作对应
查询状态只需读工具，取消与退款则改变状态。分别列出凭证、权限、金额、幂等标识和结果查询方式。
03 / DELIVERY ROUTE
方案如何一步步落到工作里？
- 01
理解问题
确认订单与诉求，缺条件先澄清，不把关键词直接等同意图。
- 02
核对事实
从业务系统读取当前状态和可执行动作；避免拿过期文本当状态。
- 03
执行或交接
低风险动作按契约执行；争议或例外转人，附来源与已尝试步骤。
- 04
确认解决
读取执行结果并回访同问题是否重复出现；修复知识或流程。
04 / DECISIONS
哪些判断决定方案是否可靠？
速度不能挤掉解决质量
把复杂问题分层评估。缩短对话但增加重复联系，可能只是把成本移到了下一班客服。
网络超时后先查账
退款请求返回超时不代表未执行。先按操作键查询结果；盲目重试可能造成重复退款。
05 / WORKED EXAMPLE
退款结果未知时该怎么做
合成教学样例
合成售后系统：refund_request=R-24 提交后超时。练习只在模拟系统内执行。
- 不可直接做
- 生成新请求编号再发一次退款。
- 应当先做
- 用 R-24 查询状态：成功则返回原凭证，处理中则等待。
- 无法确认
- 保留 unknown，交接给人工并说明已提交，禁止无依据重复执行。
06 / COURSEWORK
对应课程：你要做什么、交什么？
从重复咨询重建问题路径
- 交付物
- 问题单元与服务路径图
- 通过条件
- 问题数与会话数分开计
实现退款模拟与幂等重试
- 交付物
- 动作契约 + 状态机
- 通过条件
- 重复执行不增加退款金额
定义真正解决的观察窗口
- 交付物
- 服务质量与成本验收
- 通过条件
- 重复联系与人工返工计入成本
07 / ACCEPTANCE & REUSE
怎样证明完成，下一次复用什么？
验收检查
评估解决率、重复联系、复杂问题质量、转人工成功和每成功任务成本。历史公司自报数字只用于理解案例，课堂不把它设成统一目标。
可复用资产
同样适用于售后、预约与订单服务：识别意图只是起点，业务状态与后续处理才决定是否完成。
