Capita 的两步走：先建立采用基础，再让智能体接手流程

一家替别人跑流程的公司，先要改自己的流程

Capita 的生意就是流程本身。这家英国业务流程外包公司替公私部门客户处理复杂、量大、有合规要求的业务环节。它不是把 AI 当锦上添花的公司——客户买的就是它把流程跑得更省、更快的能力。

这带来一个特殊的紧迫感：面对的不是「要不要试试 AI」，而是「怎么把 AI 变成可以卖出去的交付能力」。横在中间的矛盾很具体：一方面要压掉分散在邮件、文档和沟通里的重复办公成本，另一方面要把这种个人层面的效率提升，延伸到面向客户的服务流程里。前者靠铺工具就能起步，后者需要动业务节点。两件事难度不在一个量级，但只做第一件，省下的时间很难变成客户看得见的交付改善。

关于规模，需要先划清一条口径线：官方披露的员工总数是公司体量，不等于 AI 的实际使用人数；官方给出的使用规模是每月 34 万次 Copilot 操作，这是操作计数，不是去重用户数。本文后续凡涉及「规模」一律指操作量口径。

重复劳动藏在邮件、评估和路线里

官方点名的三个改造场景，代表三类不同性质的重复劳动。邮件问询是纯信息处理量问题：每天数千封需要读懂、归类、分派、回复。消防风险评估是标准化合规材料，人工投入大量时间在结构相似的内容上。车队配送路线属于需要按实时条件反复重算的调度问题。

起点不在这三个场景，而在员工的日常办公。公司先用 Microsoft 365 Copilot 提升个人生产率，官方特别提到其中一项收获是支持神经多样性同事的工作方式——这个细节容易被效率叙事盖过，但它解释了内部推广为何阻力不大：员工先感受到工具对自己有用。

从「个人用得顺手」到「流程被改掉」之间有一道坎。个人使用是自愿的、低风险的，失败了只影响一份草稿；流程改造要嵌进业务节点，出错就是客户端的问题。Capita 数字化负责人 Tiina Stephens 把这个转折说得很直接：下一步是智能体。

谁在推、谁在管、哪些判断不交给机器

官方披露三位具名角色，对应三种职能。数字化总监 Tiina Stephens 负责方向，把「嵌入 Copilot 与智能体」和「改善内部流程、为客户带来更好结果」放在同一句表述里。云技术顾问 Shivani Tanwar 负责技术侧，描述的是智能体网络的搭建方式：一个智能体把任务交给下一个，靠 Copilot 的可扩展性做端到端改造。持续改进负责人 Claire Thistlethwaite 站在业务流程一侧，她的团队在 Copilot Studio 里做出了那个每天分拣数千封邮件的智能体。CEO Adolfo Hernandez 把整件事定位成流程、技术和人的组合。

实施顺序是四步：先用办公助手建立采用基础；再把注意力从个人效率转向具体服务流程；然后用智能体接手邮件和流程任务；同时按月追踪操作量与节省工时。Capita 开放了 Agent Builder 供员工自建智能体，也启用了 Researcher、Analyst 这类开箱即用智能体——这意味着智能体的产生不完全依赖中央团队。开放范围的具体授权边界官方未披露。

人机分工有两处明确边界。治理层面：编排网络中每个智能体都有清晰的问责和监督归属，对齐 Microsoft 的负责任 AI 标准。任务层面：邮件智能体做的是分拣，把人从归类工作里腾出来，专注共情和问题解决。也就是说，「这封邮件属于哪一类」交给系统，「怎么真正解决这个人的问题」留给人。

再往下的操作细节官方材料未披露：智能体上线前的评审流程、准确率验收标准、分拣出错时的纠正路径、消防风险评估中人工复核的具体节点、以及自建智能体的数据访问范围如何限定，都没有公开说明。这些正是复现这类项目时最需要自己设计的部分。

三个数字，三种口径

官方披露的核心结果是每月节省 19,000 小时，这是组织层面的月度汇总值，Capita 归为 Copilot 的整体效果；与之并列的是每月 340,000 次 Copilot 操作。两个数字必须一起读：34 万次操作说明这不是几十人的深度试验，而是形成了常规使用量；1.9 万小时是在这个操作规模上得出的汇总，不是某个团队或某个流程的成绩，也无法反推人均效果或使用人数。

流程级别最具体的数字是邮件问询响应时间下降 60%。它来自那个每天分拣数千封邮件的智能体，衡量的是答复速度，不涉及答复质量、解决率或客户满意度。

消防风险评估和车队路线两个场景，官方表述是定性的：评估环节节省时间和成本并加强合规与安全，车队服务里由自主智能体动态优化配送路线。没有量化结果，因此无法判断它们在总节省工时中占多大比重。

最需要留意的限制在计算方式上。1.9 万小时的口径没有完整公开，Microsoft 365 Copilot 与 Copilot Studio 智能体各自贡献多少、三条业务线如何分摊，案例都没有拆分。数据属于客户与供应商联合披露，未经独立第三方核验。因此这些数字可以说明 Capita 报告了什么，但不足以支撑「操作量增加就带来等比例工时节省」这类因果推断——操作次数是采用广度的代理指标，不是业务价值的度量，也不是用户规模的度量。

这条路径能搬到什么样的组织

DataHub 判断：这套两步走成立的前提，是组织里有大量知识员工做着标准化程度高的服务流程，且流程边界清楚到能指出「每天数千封邮件」这样的具体对象。共享服务中心、大型运营部门和其他 BPO 具备类似条件；如果流程依赖大量个案判断、输入形式不统一，第二步很难落地，第一步的个人效率提升也不会自动传导到交付端。

DataHub 判断：先铺办公助手再改流程的顺序，让员工在低风险场景里先建立对工具的判断力，等智能体进入业务节点时，使用者已经知道在哪里不该信任输出。前提是第一阶段跑够长时间，而不是把工具部署当成一次性的许可证发放。

要自己补齐的是官方没写的那半边：集中管理授权、身份和使用日志是起点；更关键的是在试点设计阶段就把使用量指标和业务结果指标分开，并为分拣类任务定义错误的发现方式与回退路径。Capita 把共情和问题解决留给人，这条分界线值得照搬，但准确率门槛、复核比例和例外升级规则，每个组织都得自己算。