AI 行业落地 | 第20期：发票不用人追，工单不用人等

AI行业落地 · 2026-10-26 · 九羲科技

发票卡在入账前，员工卡在支持流程里，旅客卡在退款等待里——这三个地方，过去都要靠人一封封邮件、一张张单子去推。这一期三个案例，讲的都是同一件事：智能体进了生产，靠什么站住脚。答案不在模型参数表里，在三处提前钉死的位置上：数据在哪个门口被修好，人被放在哪个位置，失败时流向哪里。

先把成色说在前面：三个案例的数字都来自厂商案例或厂商公告，经行业媒体整理转述，没有独立审计。读的时候，数字当作“厂商口径的业务信号”，方法当作“可以抄走的设计选择”，两者分开算。

· · ·

发票先修好：Asurion 把异常拦在入账之前

1. 背景：异常不是偶发，是常态

Asurion 是一家全球技术保障与支持公司，美洲区的发票量不小：直接采购订单发票一年约 3 万张，其中约 90% 至少遇到一个异常；间接发票一年约 2.5 万张，逾 75% 存在表头一级的问题。¹ 异常堆在入账口，财务每天的活儿，很大一部分是在给单子“擦屁股”——对不上采购订单、供应商物料号写错、数据缺一块，任何一项都能把一张发票挡在账外。

2. 方案：不换系统，在旧流程里加一道修理工序

做法克制得有点出乎意料：用一个 Microsoft Copilot Studio 智能体，嵌进已有的发票采集流程，不动财务系统的底座。智能体在记录进入 Microsoft Dynamics 365 Finance 之前动手：识别采购订单引用对不上的地方，修正供应商物料号的差异，把发票数据补齐到能入账的样子；修不好的，交给 Power Automate 按异常类型分流、重处理。¹ 关键设计选择是位置——修理工序放在“入账前”，而不是“入账后对账时”。入账前修，错单不进账；入账后修，账已经乱了，越修越贵。

图：AI 发票处理示意。图片来源：InfotechLead 发票智能体专题配图。

3. 效果与成色：首周过半，随后过七成，但基线口径要打个问号

微软案例披露的数字是：无触碰处理率上线第一周超过 55%，随后超过 70%，公司称有望向 85% 以上走；部署前的无触碰率低于 20%。¹ 但这里有个口径提醒，同一家媒体在另一篇梳理里专门点过：低于 20% 的基线针对的是两家供应商，与后来美洲区整体的口径不完全是同一群人。所以“从 20% 到 70%”别读成同一口径的精确增幅，读成“从两成不到的水平，爬到了七成以上”这个量级变化，更老实。数字是厂商案例口径，没有独立审计。

值得抄走的方法点：先把异常收敛到两三类能规则化的问题（订单引用、物料号、表头数据），再谈智能体；系统不用推倒重来，修好“进账前那一公里”，收益来得最快。

· · ·

先认员工做过的事：微软内部智能体的信任课

1. 背景：30 万人的大场子，智能体一开始没人爱用

微软内部 IT 组织 Microsoft Digital 在 2025 年秋天，向 30 万多名员工与外包人员推出了员工自助智能体（Employee Self-Service Agent），横跨 HR、IT 支持、园区设施三条线，建在 Copilot Studio 上，放在 Microsoft 365 Copilot 里，目标是工单分流 40%。² 模型、连接器都不缺，早期使用情况却不如预期。问题不在技术，在人对机器的预期上。

2. 方案：把智能体从“搜索引擎”改成“同事”，先承认，再帮忙

微软请设计研究机构 Designit 做了调研，结论很耐琢磨：员工不是把智能体当搜索引擎用，而是当同事看。² 平常人遇到问题，先查文档、重启电脑、问同事，实在不行才打开智能体；智能体上来就让人把刚做过的基础步骤重做一遍，挫败感一下子就起来了。更深一层是怕：怕智能体是挡在真人前面的一道墙，问了半天，还是见不到人。

改法对着这两处下手：对话流程先承认用户已经做过的排查，不让人重复劳动；同时明明白白承诺，自助走不通就转真人技术人员，转过去不用从头再讲一遍。还有一处容易被忽略的准备工作：返岗政策高峰来之前，团队先把核实过的返岗文档并成一份单一信源文件喂给智能体，那个主题的用户满意度从 85% 升到了 98%。² 智能体答得准不准，有一半是信源整没整干净。

图：信任先行、分流随后的方法示意。本报绘制，非实拍。

3. 效果与成色：工单新建量降三成，先用智能体的人过半

到 2026 年 10 月，微软内部披露：IT 支持工单新建量下降 30%，从智能体开始支持旅程的员工占比从 27% 升到了 50%。² 注意两个边界：30% 指的是 IT 工单的新建量，不是全部三条服务线；数字来自微软自己 10 月 8 日的 Inside Track 回顾，没有第三方审计。40% 的分流目标还没说达成，读成“在路上的进展”比较稳。

值得抄走的方法点：分流率是结果，不是入口。入口是信任设计——把“用户已经做过的步骤”当成对话的输入，而不是当成需要纠正的错误；把“转真人”写进流程的明处，用户才敢先用智能体。

· · ·

先自动化交易本身：印度航空的退款与改名

1. 背景：140 多个系统，退款是最绕的一道流程

印度航空的数字底座横跨 140 多个企业系统，在途的智能体项目超过 30 个。³ 客服流程里最绕的是退款：多重验证、政策核对、后端交互、跨团队依赖，全占齐了。只做一个“回答问题”的聊天窗口，解决不了这种流程——问题答对了，钱还是退不出去。

2. 方案：Agentforce 编排验证、审批与后端动作，置信度不够就留给人

印度航空用 Salesforce Agentforce 把退款流程里的验证、审批与后端退款动作编排起来，不再是人拿着工单在系统之间搬运。³ 扩展开的三件事各有讲究：自动邮件回复先拆一封邮件里的多个诉求——退款、行李、常旅客可能同在一封信里——用专门的子智能体分别取数、验证、执行，再按核准模板合成一封回复；姓名更正则把多重资格校验、票务操作、重新出票、送达新票全串起来；知识智能体给一线客服实时查政策、票价规则与操作指引，省掉在多个知识库之间翻找的时间。

审批与人机分工钉在一条硬线上：符合条件的自动邮件回复，只在系统置信度超过 95% 时生成，不足就转人工。³ 这个 95% 是运行规则的阈值，不是独立测出来的准确率——它划的是“机器可以自己签字的边界”，边界之外，人必须在场。

图：印度航空 Agentforce 相关通稿配图。图片来源：NewsVoir / ANI 通稿图片。

3. 效果与成色：内部退款 14 天变 4 小时，银行那段没变

厂商公告给出的数字：内部退款处理时间从约 14 天压到约 4 小时，姓名更正从约 3 天压到 30 分钟。³ 但公告自己也留了口子：银行处理时间不变。也就是说，旅客体感到的“到账”快慢，还要看银行那一段；4 小时是航空公司内部的流程时间，不是全程到账时间。数字来自 Salesforce 2026 年 9 月 16 日的公告，经多家媒体转述，同样是厂商口径。

值得抄走的方法点：客服自动化的分水岭，是从“回答问题”跨到“执行交易”——验证、审批、后端动作、回执，四步串起来才算数；同时给自动执行设一条公开的置信度门槛，门槛以下一律留给人，这条线本身就是对客户的交代。

· · ·

今日启示：对九羲来说，私有智能中心进客户现场之前，先帮客户把这三处定下来——异常在哪个门口修、员工与客户在哪个环节接手、失败流向谁——再谈模型与算力；本地部署的价值，放在这个背景里看就多了一层意思：异常、权限与审计都留在客户手里，这本身就是一种踏实。

· · ·