AI 客服降本 65% 的案例里，真正值得重算的是哪笔账

Databricks 在 9 月 9 日发布的 Zepto 客户案例中披露：AI 在保留人工监督的情况下处理超过 80% 的客服工单，客服成本下降 65%。这些数字来自参与方披露，未经本站独立审计，也不是适用于所有商家的平均效果。

工单的数量、重复度和处理难度，决定了自动化能覆盖多大一块工作。即时配送中，查询订单进度与核实退款状态往往可以被拆成较清楚的步骤；投诉升级、交易争议或信息缺失则需要更多判断。两家公司的咨询总量相同，自动化价值也可能差很多。

采购方首先应核对“成本”的分母：是否只算客服人员，是否包含技术接入、平台使用、人工监督和补偿支出；比较期的订单量、业务范围和服务标准是否相同。公开案例给出了方向，但不能替每一家企业完成这些口径核对。

报价时直接承诺同样的降幅，会把未知的工单结构和集成难度转成服务商自己的风险。更合理的起点是取得一段有代表性的历史工单，按问题类型、处理时长、重复来单和结果分别统计，再判断哪些工作真正可以被移走。

看一组用于解释工作量的假设情景，并非 Zepto 数据：每月 1 万张工单，其中 8000 张简单咨询每张需要 2 分钟，2000 张复杂问题每张需要 10 分钟。原流程合计需要 3.6 万分钟，约 600 小时。

即便简单咨询全部交给 AI，人工仍要处理复杂问题的 2 万分钟，约 333 小时。按工单数量看，自动化率是 80%；按这组假设的原始工时看，移走的工作量约为 44%，还没扣除抽查、升级和系统维护所需时间。

这不是在预测某个公司的实际降幅，而是在说明分母为何重要。留下来的工单更难，平均处理时长可能上升，经验丰富的客服也可能更重要。仅凭坐席数减少，无法判断服务质量和总体成本是否改善。

还要区分省出的工时与省下的现金。如果原本就需要覆盖晚间与高峰班次，零散减少的工作量不一定足以取消一个班次。企业也可能把余量用于缩短等待时间或承接更多订单，这属于容量提升，应与直接费用节省分开呈现。

AI 客服最容易展示的是即时回复，最难证明的是问题已经解决。顾客收到“已为您处理”的消息后，订单状态是否改变、退款是否到账、同一问题是否再次出现，才决定这张工单是不是真的结束。

一次会话被标记为完成，但顾客隔天重新联系人工，会让首轮自动化率很好看，却增加总处理次数。报表应围绕同一问题的完整处理过程核对，而不是把每次对话当作互不相关的新任务。

例如，可在适合业务的观察窗口内检查重复联系、人工重开和投诉升级，同时区分首次响应时间与最终解决时间。窗口长短要根据订单和退款周期制定，不能为了降低重复率选一个问题尚未暴露的时间段。

对外包公司而言，这会改变交付证据。每天发送了多少条回复、覆盖了多少咨询，只能证明系统繁忙；能够追溯订单状态、处理动作、人工接管和最终结果，才更容易说明服务的价值。

Zepto 的案例记录了两类失误：配送延迟时，系统依据旧数据重复承诺到达时间；加入取消功能后，模型曾混淆取消请求和取消状态查询。前者在运行中被发现，后者由上线前评估拦截。两者都说明，流畅表达不足以保证业务动作正确。

查询退款进度与发起退款，是两种不同的权限。前者读取事实，后者改变资金与订单状态。设计上应将意图识别、业务条件判断和执行授权分开，明确哪些动作可自动完成，哪些必须由有权限的人批准。

重复请求同样值得重视。顾客刷新页面、网络重传或 Agent 自动重试，都可能再次发起同一个动作。订单系统应能够识别已经处理的请求并返回结果，而不是重复执行。退款金额和可操作范围也应由可信业务数据核定，不能完全依赖模型自行填写。

转人工不能只是把对话塞到另一个队列。人工需要看到最新订单状态、顾客诉求、系统已尝试的动作及失败原因；否则顾客要重讲一次，客服还要重新查一遍。减少这种交接损耗，可能比进一步提高自动处理率更有用。

这份案例采用上线前测试与运行中评估相结合的方式，把真实失误重新纳入后续检查。文章也提醒，单独追求某项准确率可能牺牲响应速度或顾客体验。对商家而言，这意味着验收不能只跑一套演示问题。

一套有用的测试应覆盖常见问题、边界状态和不允许执行的操作。正常退款能否查询只是起点；退款尚未受理、已被拒绝、分多笔到账，或者顾客问的是另一笔订单，都应有各自的预期行为。预期答案和操作权限需要由熟悉业务的人确认。

促销规则、配送范围、商品政策和后台接口都会变化。每次变更后，应让新旧版本处理同一批样本，检查是否修复了目标问题、又引入了其他失误。对结果不明确的案例保留人工判断，不把模型给自己的评分当作唯一验收依据。

运行中的抽查也应围绕风险安排。可以对新功能、重复投诉或高影响操作增加关注，但必须同时保留随机抽查，防止系统只检查已经知道会出问题的地方。抽查发现的问题要有人负责归类、修复和复验，告警数量本身不等于质量改善。

以人工数量作为主要卖点的服务，可能面临客户重新议价；但维护真实业务规则、接通系统、管理例外和持续验收，仍需要投入。这是一种有条件的业务变化，不代表所有外包团队都能自然转型为软件服务商。

一个边界清楚的试点，可以只覆盖退款进度查询：限定订单渠道、支持的状态、回答范围和转人工条件；先在少量真实流量中验证，保留原服务的接管能力。验收时同时查看已解决的问题、错误率、重复联系与人工总耗时。

合同可以分别说明接入工作和持续维护工作，但费用必须对应清楚的交付责任。比如数据接口由谁保证、业务规则由谁确认、系统故障后谁接管、扩大范围如何计价。只出售一个聊天界面，却承诺承担全部售后效果，会把不可控风险混进报价。

规模较小、工单量有限的商家，现成工具加少量人工可能更合算。定制系统有固定的接入和维护投入，订单量不足时很难摊薄。服务商应能说明为什么需要定制、与现成方案相比多解决了什么问题，而不是默认越复杂越专业。

把模型调用、平台费用、人工接管、质检、维护和错误处理列在同一张账单中，再与合格解决的问题数量对应。没有解决的问题及其已发生的费用也不能从报表中消失，否则失败越多，统计越容易失真。

不同问题类型最好分别比较。物流查询的大幅改善可能掩盖退款纠纷的恶化；平均等待时间下降，也可能同时出现少量用户被困在自动回复循环里。采购方需要知道改善来自哪里、代价落在谁身上，以及哪些场景仍需人工。

值得续约的项目，应能同时证明服务结果可接受、总投入可控制、异常有人负责。65% 这样的案例数字适合引发一次成本复盘，真正支撑合同的仍然是客户自己的持续运行记录。