Sierra 是垂类 Agent 的代表公司，很多人知道它是商业模式比较有代表性：outcome-based pricing，也就是按结果付费。
意思是 B 端客户使用了 Sierra 作为 AI 客服，如果进线的会话被 Agent 端到端 resolved 了而没有转人工，就意味着 Agent 产生了价值，要计费。反之只要人工介入了，本次会话就不收费。
我好奇的是 Sierra 如何定义 resolved，以及具体的实施流程是怎样的，于是从官网 book a demo，然后 Sales 带着我端到端体验了一把客户视角的 outcome-based pricing。
我一开始以为会先看产品 demo，结果真正有价值的部分反而在 demo 前面。他们需要先知道我的客服规模、主要渠道、ticket volume、现在的 automation rate、平均处理时长、转人工比例、CSAT、用什么 CRM / contact center / 订单系统，以及最想先自动化哪几类问题。
这个流程不是传统那种“我给你一个 AI 客服，你接上去试试”。更像是先把我的客服业务拿出来做一次拆账：哪些会话有明确结果，哪些只是咨询，哪些有系统动作，哪些容易扯皮，哪些压根不适合 result-based pricing。
然后就进入最关键的一步：定义 billable resolution。
比如退款，不能写成“Agent 帮用户解决退款问题”。这句话上不了账单。真正能落地的定义要具体到：用户身份验证通过，订单符合退款政策，Agent 成功调用订单系统生成 return_id，退款标签发送成功，CRM 里状态更新，并且整个会话没有转人工。满足这些条件，这一单才算 resolved。
查订单也是一样。只是告诉用户“订单状态”不一定能计费。要看它是不是命中了双方约定的 outcome：识别用户、查到订单、解释异常、给出下一步动作，用户没有继续升级，也没有进入人工队列。
取消订阅更典型。Agent 劝用户留下来不叫结果。它要识别取消原因，给出规则允许的挽留方案，用户接受后，订阅系统里真的完成 pause、discount 或 plan change。这个时候才可能被记成一个 saved membership。
我觉得 Sierra 这里最重的工作，是把“AI 客服觉得解决了”翻译成“系统、运营、财务都承认解决了”。
后面实施会变成很工程化的几步。
先拿历史 ticket 做 intent mapping。比如过去 90 天的会话，按订单查询、退款、地址修改、物流延迟、优惠券、会员取消、投诉升级这些桶切开。每个桶再判断：能不能闭环？闭环需要哪些字段？需要调用哪些系统？失败时什么时候转人工？
接着是系统集成。知识库只是让 Agent 能说话，CRM 和订单系统才让 Agent 能办事。没有 write-back，没有 tool call，没有状态更新，就很难按结果收费，因为结果没有凭证。
然后是 simulation。拿真实历史对话去回放，让 Agent 跑一遍。用户没给订单号怎么办？政策边界不清楚怎么办？接口失败怎么办？用户情绪很差怎么办？Agent 什么时候该继续问，什么时候必须 handoff？这些都要在上线前打出来。
真正上线也不会一把梭。通常会先选少数几个低争议、高频、系统动作明确的场景，小流量跑。比如只开放 web chat 的订单查询和退货，先看 resolved rate、handoff rate、recontact rate、false resolution。
false resolution 这个指标我觉得非常关键。系统判定 resolved，但用户 24/48 小时内又回来找人工，或者质检发现其实没有处理完，这种就不应该算钱。否则 result base 会变成供应商和客户每个月对账吵架。
所以我最想看的不是那个很顺的 demo，而是账单明细。
每一行 billable case 后面，应该有 conversation id、intent、outcome type、工具调用记录、系统返回值、handoff reason、最终判定规则。客户应该可以抽样回放，也应该可以 dispute。比如这条为什么算 resolved？那条为什么不算？用户第二天又来问同一个问题，上一笔还收不收？
跑完这一圈，我对 Sierra 的理解反而更清楚了。
它表面是 AI 客服，实际卖的是一套“可验收的自动化客服 workflow”。result-based pricing 不是换一种收费方式这么简单，它要求产品把业务结果拆得足够细，细到能执行、能记录、能复盘、能对账。
所以 resolved 不是 AI 自己说“我回答完了”。resolved 是一份合同，是一条系统记录，也是一笔可以被客户财务接受的账。
意思是 B 端客户使用了 Sierra 作为 AI 客服，如果进线的会话被 Agent 端到端 resolved 了而没有转人工，就意味着 Agent 产生了价值，要计费。反之只要人工介入了，本次会话就不收费。
我好奇的是 Sierra 如何定义 resolved，以及具体的实施流程是怎样的，于是从官网 book a demo，然后 Sales 带着我端到端体验了一把客户视角的 outcome-based pricing。
我一开始以为会先看产品 demo，结果真正有价值的部分反而在 demo 前面。他们需要先知道我的客服规模、主要渠道、ticket volume、现在的 automation rate、平均处理时长、转人工比例、CSAT、用什么 CRM / contact center / 订单系统，以及最想先自动化哪几类问题。
这个流程不是传统那种“我给你一个 AI 客服，你接上去试试”。更像是先把我的客服业务拿出来做一次拆账：哪些会话有明确结果，哪些只是咨询，哪些有系统动作，哪些容易扯皮，哪些压根不适合 result-based pricing。
然后就进入最关键的一步：定义 billable resolution。
比如退款，不能写成“Agent 帮用户解决退款问题”。这句话上不了账单。真正能落地的定义要具体到：用户身份验证通过，订单符合退款政策，Agent 成功调用订单系统生成 return_id，退款标签发送成功，CRM 里状态更新，并且整个会话没有转人工。满足这些条件，这一单才算 resolved。
查订单也是一样。只是告诉用户“订单状态”不一定能计费。要看它是不是命中了双方约定的 outcome：识别用户、查到订单、解释异常、给出下一步动作，用户没有继续升级，也没有进入人工队列。
取消订阅更典型。Agent 劝用户留下来不叫结果。它要识别取消原因，给出规则允许的挽留方案，用户接受后，订阅系统里真的完成 pause、discount 或 plan change。这个时候才可能被记成一个 saved membership。
我觉得 Sierra 这里最重的工作，是把“AI 客服觉得解决了”翻译成“系统、运营、财务都承认解决了”。
后面实施会变成很工程化的几步。
先拿历史 ticket 做 intent mapping。比如过去 90 天的会话，按订单查询、退款、地址修改、物流延迟、优惠券、会员取消、投诉升级这些桶切开。每个桶再判断：能不能闭环？闭环需要哪些字段？需要调用哪些系统？失败时什么时候转人工？
接着是系统集成。知识库只是让 Agent 能说话，CRM 和订单系统才让 Agent 能办事。没有 write-back，没有 tool call，没有状态更新，就很难按结果收费，因为结果没有凭证。
然后是 simulation。拿真实历史对话去回放，让 Agent 跑一遍。用户没给订单号怎么办？政策边界不清楚怎么办？接口失败怎么办？用户情绪很差怎么办？Agent 什么时候该继续问，什么时候必须 handoff？这些都要在上线前打出来。
真正上线也不会一把梭。通常会先选少数几个低争议、高频、系统动作明确的场景，小流量跑。比如只开放 web chat 的订单查询和退货，先看 resolved rate、handoff rate、recontact rate、false resolution。
false resolution 这个指标我觉得非常关键。系统判定 resolved，但用户 24/48 小时内又回来找人工，或者质检发现其实没有处理完，这种就不应该算钱。否则 result base 会变成供应商和客户每个月对账吵架。
所以我最想看的不是那个很顺的 demo，而是账单明细。
每一行 billable case 后面，应该有 conversation id、intent、outcome type、工具调用记录、系统返回值、handoff reason、最终判定规则。客户应该可以抽样回放，也应该可以 dispute。比如这条为什么算 resolved？那条为什么不算？用户第二天又来问同一个问题，上一笔还收不收？
跑完这一圈，我对 Sierra 的理解反而更清楚了。
它表面是 AI 客服，实际卖的是一套“可验收的自动化客服 workflow”。result-based pricing 不是换一种收费方式这么简单，它要求产品把业务结果拆得足够细，细到能执行、能记录、能复盘、能对账。
所以 resolved 不是 AI 自己说“我回答完了”。resolved 是一份合同，是一条系统记录，也是一笔可以被客户财务接受的账。
