航司客服为什么是硬场景
航空公司的客户服务有两个特征，使它与其他行业的客服自动化不在同一难度上。一是时效要求高，航班取消或延误之后的每一小时，都会同时放大旅客的不满与赔付成本；二是政策复杂，退款规则、行李处理、常旅客权益彼此交叉，还叠加不同航线与不同市场的监管差异。
在 Dreamforce 2026 上，Salesforce 公布了 Air India 的一项部署：这家塔塔集团旗下的航空公司将使用由 Agentforce 驱动的智能体处理退款请求、行李与常旅客权益相关的索赔，并在符合条件时按乘客要求改名并重新出票。这是该公司整体智能化计划的一部分。
披露了哪些指标
公开内容里的量化信息集中在两处。退款请求在四小时内处理完成；资格核查与改名换票在三十分钟内完成。应用范围覆盖退款、行李与常旅客权益三类工单，目标是减少这些环节的处理时间。
与很多同类公告相比，这两组数字的形态值得留意。它们描述的不是智能体完成了多少通对话，也不是替代了多少人力，而是单类业务从提交到办结的时长。这是一种更接近运营口径的表达方式：旅客关心的不是我用了什么技术，而是钱什么时候到账、行李问题什么时候有答复。
没有披露的部分同样需要记录。官方未说明上线时间表、覆盖的客群比例、单月工单量级、人工坐席规模是否变化，以及自动化处理占比与人工接管比例。这些缺口决定了「四小时」与「三十分钟」是稳定服务水平，还是特定条件下的结果。
指标口径正在从「量」转向「时长」
把这组数字放回 Dreamforce 的客户名单里看，会发现一个有意思的变化。同一批公布的企业案例中，有的强调的是人力效率，例如招聘集团在推广智能体之后给出的工时节省比例；有的强调的是流程质量，例如工业企业在销售线索环节把无效线索的规模压下一大截。而航空这组案例给出的，是端到端的办理时长。
三种指标各自对应不同的价值主张。工时节省回答的是成本问题，线索质量回答的是收入问题，办理时长回答的是旅客体验与赔付成本问题。有意思的是，航空业的指标恰好是最难被技术话术修饰的一类——它在企业内部本来就有既有的服务水平统计口径，宣称与自己过去的运营数据无法分开评估。这也让这类公告相对更有参考价值：不是因为它更诚实，而是因为它更可被外部对照。
真正的难点不在问答，在不规则运营
客服智能体处理标准问题早已不是难点。真正吃掉工单时间的部分，往往出现在规则之外的场景：极端天气导致的批量取消、系统故障带来的重复扣款、政策例外下的赔偿判定，以及同一名旅客同时涉及机票、行李与常旅客积分的组合问题。
这些问题对智能体提出的要求，与对话能力关系不大。它需要能同时写入订座、常旅客与支付等不同系统，并在任一步骤失败时把状态回滚到一致；需要能识别哪些请求超出自己的授权范围，并干净地交给人；需要对自己的结论给出可复核的依据，因为后续可能需要面对投诉与监管问询。任何一环缺失，处理的就不是「时长」，而是「返工次数」。
还有一类隐性成本容易被忽略：被拒绝的请求如何解释。拒赔、拒退与不符合改签条件的情形，是投诉最集中的地方。如果智能体只是把拒绝发出去，投诉量可能上升，而投诉的处理恰恰是最难自动化的一环。
需要观察的风险与边界
改名与重新出票这类操作涉及身份信息与票务安全，属于对准确性要求较高的动作。官方未披露这类操作是否需要人工复核、是否设置次数或金额上限、以及出现误操作时的回滚路径。这些问题是把智能体接入核心业务系统时的通用门槛，也是判断这套部署成熟度的关键指标。
此外还有两类信息缺口。一是商务侧，Salesforce 在此次发布中并未披露相关产品的定价与正式可用时间，客户部署的时间表也未明确。二是组织侧，航司客服与地面服务、机场柜台的工作流高度耦合，智能体在其中承担的部分是否改变了岗责划分，目前没有公开信息。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
把工单交给智能体的前置条件
阅读这类案例时，容易被忽略的是它成立所依赖的工程量。智能体要在三十分钟内完成资格核查与改名换票，前提是它能够读取并写入订座、常旅客与支付等系统，并且在任一步骤失败时保持状态一致。这不是对话能力的延伸，而是集成能力的考验——它要求每个业务动作都有明确的接口、幂等语义与失败回滚路径。
另一项前置条件是政策知识的结构化程度。退款与改签规则本身充满条件分支与例外，如果这些规则只存在于客服的话术培训材料里，智能体就只能靠模型推断；只有当规则被整理成可查询的结构，自动化处理才谈得上稳定。这也解释了为什么航司往往从规则边界清晰的工单类型切入，而把争议较大的请求留在人工通道。
第三项是人工兜底的设计。公开信息里没有提及抽检比例与接管机制，但对任何高时效的自动化流程来说，这两项决定了错误以多快的速度被发现。缺少抽检的情况下，被错误拒绝的请求通常不会立刻暴露，而是以投诉的形式延后出现，届时纠正成本更高。
同类部署可以横向比对什么
把视角从航司放大到整个客服自动化赛道，可以看到指标的选择正在分化。零售与电商侧的部署更强调首轮解决率与转化贡献，因为客服本身承担一部分销售职能；出行与旅游侧更强调改签与退款的响应时长，因为这类请求直接关联赔付与监管；软件与 IT 服务侧则更多强调工单分流与升级路径的准确性。
指标分化背后是业务价值的不同来源。同一条技术能力，落在不同行业里能被记入哪本账，取决于这门生意里成本压力最大的环节在哪里。对航司而言，最紧的是处理时效与投诉，所以指标写成了时长。这也是判断同类案例含金量的一个简便方法：看它选了哪个指标，基本就能推断出它想解决的成本项。对读者来说，这比记住某家用了哪套系统更有参考价值。
结语
这个案例的可读之处，不在于它用了哪家的智能体，而在于它把承诺写成了时长。当指标从「上线的智能体数量」换成「退款几小时到账」，自动化的价值就有了可验证的落点，同时也把失败暴露得更彻底。接下来真正值得追踪的不是这两组数字能否兑现，而是它们在一段较长时间里的波动幅度——一个在淡季能跑出四小时的流程，遇上大面积延误时会变成什么样，才更接近这门生意的真实难度。