背景：MSP 的瓶颈不在人不够，而在工单要转手
托管服务商（MSP）的商业模式决定了它的成本结构：客户越多，工单越多，而工单越多，需要的人就越多。这条线性关系让规模扩张的边际收益很有限。Thrive 为数千家中小企业与中端市场客户管理 IT 环境，提供网络安全、AI、云与托管服务，客户基数增长带来的直接压力是：如何在不按比例增加人工与升级的情况下维持服务质量。
传统工单流程的问题不在单个环节，而在转手。一条工单进来，要先读、判断类别与优先级、路由到某个组、翻知识库、找到能处理的人、处理、最后写解决说明。每一次转手都带来延迟和上下文丢失。Thrive 的运营总监 Scott Steele 把目标说得很朴素：尽可能多用自动化，让工程师的工作更轻松。
主体：Thrive 是谁，它要解决什么
Thrive 是一家面向中小企业与中端市场的托管服务商，客户横跨多个行业，提供的服务包括网络安全、AI、云与托管服务。它选择的服务对象是需求碎片化、单客户价值有限但总量庞大的一类市场，这决定了它的解决方案必须是高吞吐、低单笔成本的，而不是靠资深专家逐个攻坚。
这一点很重要，因为它决定了后面所有设计的取向：Thrive 需要的不是更强的专家，而是更少的转手。
三步路径：先换底盘，再上智能体，最后接端点
这条路径是本文认为这个案例里最值得抄的部分，因为它和多数团队的直觉顺序相反。
| 步骤 | 做了什么 | 解决的瓶颈 | 为什么不能跳步 |
|---|---|---|---|
| 步骤一：换数据底盘 | 在 ServiceNow AI 平台上用 TPSM 搭建 NextGen 平台；TPSM 是面向技术供应商的服务 CRM，含 Service Exchange 用于实时客户协作 | 把客户服务与技术支持集中到一个数据模型上 | 没有统一数据模型，智能体看到的是 彼此割裂的上下文，路由判断依据不足 |
| 步骤二：上智能体 | 部署专用 AI 智能体，让工单自动分类、路由、调查，工程师只在最关键的工单上介入 | 减少转手与人工分诊 | 智能体的分类与路由能力依赖步骤一沉淀的结构化历史数据 |
| 步骤三：接端点 | NextGen 3.0 接入 ServiceNow DEX 数字员工体验能力与 TeamViewer 远程连接技术 | 从「等工单」转为「主动发现并即时处置」 | 看不到终端设备的健康状态，就只能在客户报障之后被动响应 |
步骤三容易被当成锦上添花，但它的意义是一次价值曲线的位移。前两步优化的是「工单来了之后多快解决」，步骤三改变的是「工单是不是一定要来」。ServiceNow 的表述是：两者结合让 Thrive 的团队获得设备健康与终端用户体验的实时可见性，并能当场远程诊断与处置，在问题打断客户工作之前就发现并解决，而不是等一张工单进来。
常见失败路径是先买智能体、后补数据：智能体上线后发现工单历史分散在多个系统里，分类准确率上不去，最后退回人工分诊，项目停在试点。Thrive 的顺序把最枯燥的底层工作放在前面，这也是它在一年内能把路由量做到每六个月 31.5 万的原因。需要说明的是，这三步的划分是本文依据新闻稿披露的实施内容所做的归纳，Thrive 与 ServiceNow 均未使用「三步」这一表述，也未披露各阶段的起止时间。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
五笔账：73%、63%、99.2%、1.45 万小时、9.2 万次
披露的量化结果集中在五处，各自的口径不同，需要分开读。
| 指标 | 读数 | 口径说明 | 本文的可用性判断 |
|---|---|---|---|
| 自动路由任务量 | 每六个月超过 31.5 万个 | 明确标注为每六个月 | 可用，是全流程侧的吞吐量指标 |
| 节省的人工工时 | 2.1 万小时 | 与上一行同句出现，应同属六个月口径 | 可用，但周期需自行确认 |
| 首次接触解决率 | 73% | 未给出定义与基线 | 方向可用，不可横向比较 |
| 解决时长 | 降低 63%；连接时间从 6 分钟降到不足 1 分钟 | 63% 为相对值，连接时间给出了绝对值 | 连接时间这组绝对值更有说服力 |
| 客户满意度 | 99.2% | 未给出样本量、问卷方式与基线 | 谨慎使用 |
| 自动协助次数 | 超过 9.2 万次，其中 8.8 万条为解决说明 | 累计口径，未标注周期 | 可用，需与工时账分开 |
| 返还的工程工时 | 1.45 万小时以上 | 累计口径，未标注周期 | 可用，与 2.1 万小时是两笔不同的账 |
| 采纳率与部署规模 | 74% 采纳，覆盖 1000 多个已配置的执行者 | 分母是已配置人数而非全员 | 关键，见下文 |
本文折算：两笔工时账不能相加，以及单位收益
新闻稿里出现了两个工时数字——2.1 万小时与 1.45 万小时。把它们相加得到 3.55 万小时是一个常见误读，因为两者口径不同：前者是流程侧被自动化替代的人工工时，绑定在「每六个月 31.5 万个任务」上；后者是工程侧被返还的产能，绑定在「9.2 万次自动协助」上，且未标注统计周期。
| 折算项 | 计算 | 结果 | 性质 |
|---|---|---|---|
| 每个任务节省的人工 | 21,000 小时除以 315,000 个任务 | 约 0.0667 小时，约合 4.0 分钟 | 本文推算 |
| 每次自动协助返还的工时 | 14,500 小时除以 92,000 次协助 | 约 0.158 小时，约合 9.5 分钟 | 本文推算 |
| 人均自动协助次数 | 92,000 次除以约 1,000 名已配置执行者 | 约 92 次每人 | 本文推算，分母为约数 |
| 流程侧年化节省 | 21,000 小时每六个月乘以 2 | 约 42,000 小时每年，按每人年 2,000 小时计约 21 个人力年 | 本文推算，含三项假设 |
4 分钟每任务对应的是路由与分诊环节的自动化，属于「减少转手」；9.5 分钟每次协助对应的是写解决说明这类文档工作，属于「减少书写」。两者指向不同的工具与不同的团队，把它们混成一句「省了 X 小时」会让后续优化失去方向。年化约 42,000 小时这一推算依赖三项未披露的假设：任务量在年内保持稳定、2.1 万小时确为六个月口径、以及每人年按 2,000 小时计。任何一项不成立，结果都会有数量级偏差，因此该数字只应作为量级参考。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
74% 采纳率意味着什么：已配置不等于在用
披露的部署规模是「1000 多个已配置的执行者（provisioned fulfillers）」，采纳率 74%。这两个数字放在一起，可以算出一个经常被忽略的差额：约四分之一已经拿到账号的执行者并没有真正用起来。
这个差额对做同类项目的团队有三点提示。其一，采购席位数不等于活跃用户数，用席位数计算 ROI 会系统性高估收益。其二，74% 是一个不低的采纳率，说明这套工具确实嵌入了工作流，但这个数字同时也说明「配了就能用起来」的假设不成立。其三，在对外汇报时应当明确区分已配置与活跃两个口径，否则后续一旦活跃度下滑，前期报出去的收益数字会失去支撑。
同行两例：罗利市与 LTIMindtree 验证了同一条规律
ServiceNow 在同期发布的另一份材料中给出了两个可比案例，虽然行业不同，但结构与 Thrive 高度相似，可以用来检验「先数据后智能体、最后做主动触达」这条规律是否成立。
| 主体 | 规模与范围 | 做法 | 量化结果 |
|---|---|---|---|
| 美国罗利市政府 | 4 人帮助台服务 4,400 名员工 | 部署 AI 专员自主处理请求并准确路由其余工单 | 每年返还 1,300 小时以上；98% 工单首次接触即路由正确；IT 服务台成本降低 66% |
| LTIMindtree | 87,000 名员工、700 多个客户、40 多个国家 | 以 AI 智能体、智能体工作流与 AI 专员组成自治劳动力，覆盖 IT、HR、安全与项目交付的发票处理与事件管理 | HR 生产力提升 21%，入职满意度从 4.7 升至 5.0；IT 工单量下降 30%；非计划中断的平均恢复时长下降 72.3%；全企业每年释放 326,000 小时 |
把三例的量化项并排放，会发现高度重合：Thrive 的 31.5 万个任务是路由，9.2 万次协助里 8.8 万条是解决说明；罗利市的 98% 首次路由正确；LTIMindtree 的工单量下降 30% 与恢复时长下降 72.3%。也就是说，真正被规模化的收益集中在「判断这件事归谁」与「把做过的事写下来」两类动作上，而不是「替人把问题想明白」。本文据此给出一条选型建议：评估一个服务台智能体的价值时，先问它在路由与文档上的自动化比例，再问它能不能自主解决；把顺序反过来做，容易买到一个演示效果好但落地 ROI 有限的产品。
共同结构：哪四类工作适合先交给智能体
从三个案例里可以抽象出一组可迁移的筛选标准。
| 特征 | 说明 | 本案例中的对应 |
|---|---|---|
| 高频且量大 | 总量足够大，单位收益乘以规模才划算 | 每六个月 31.5 万个任务 |
| 判断依据可结构化 | 分类与路由依赖的信息已经在系统里 | TPSM 统一数据模型与历史工单 |
| 结果可核验 | 对错能在短时间内被验证 | 首次接触解决率与路由正确率可统计 |
| 失败代价可控 | 判断错误的后果可回退 | 路由错误可被人工重新分派 |
反过来，凡是判断依据散落在人脑里、结果需要长周期才能验证、或者错误会造成不可逆后果的工作，都不适合放在首批。这也是为什么 Thrive 的步骤三才敢碰端点处置——它需要先通过 DEX 拿到实时可见性，让「能不能远程处置」这个判断变得可核验。
六步打法
| 步骤 | 动作 | 优先级 |
|---|---|---|
| 选一个高频入口 | 挑工单量最大、分类规则最清晰的一类的入口先做，不要全量铺开 | P0 |
| 先统一数据模型 | 把工单、资产、知识库与历史处理记录放到同一底座上，这是智能体的判断依据 | P0 |
| 先自动化路由与分诊 | 收益最稳、失败可回退，先把转手次数降下来 | P0 |
| 再做文档类协助 | 解决说明、工单摘要这类文书工作，单次约 9.5 分钟的收益乘以次数很可观 | P1 |
| 统计口径先定好 | 区分已配置与活跃、区分路由与解决、区分相对值与绝对值 | P1 |
| 最后做主动触达 | 拿到端点可见性之后再转被动为主动，否则只能看到工单里的世界 | P2 |
四条避坑
| 风险 | 具体表现 | 规避方式 |
|---|---|---|
| 把已配置当活跃 | 用采购席位数计算收益，实际采纳率可能只有七成左右 | 从首日就同时统计已配置数与周活跃数，对外只用后者 |
| 顺序颠倒 | 先上智能体再补数据，分类准确率上不去，项目退回人工 | 把数据底盘作为前置验收项，不达标不进下一阶段 |
| 把路由成功率当解决率 | 路由正确不等于问题解决，两个指标差着一个处理环节 | 两类指标分开报，且都给出基线与定义 |
| 低估跨厂商集成成本 | 本案例的步骤三涉及 ServiceNow 与 TeamViewer 两套产品的打通，这类集成往往占总成本的大头却不在报价单上 | 立项时把集成工作量单列，并要求厂商给出已落地客户的集成方式与周期 |
冷静判断：能抄什么，不能抄什么
能抄的是路径与筛选标准。先统一数据模型、再上路由与分诊类自动化、最后才做主动触达，这个顺序在三个不同规模、不同行业的案例里都成立。用「高频、可结构化、可核验、可回退」四条标准筛场景，也比凭感觉挑场景可靠得多。把已配置与活跃分开统计，更是几乎零成本但能避免后续尴尬的做法。
不能抄的是数字本身。所有数值都出自 ServiceNow 与其客户的联合新闻稿，没有第三方审计，也没有基线对照：73% 的首次接触解决率没有说明是否包含智能体自主解决的情形，63% 是相对值而未给出改善前的绝对值，99.2% 的满意度没有样本量与问卷方式。此外，1.45 万小时与 9.2 万次协助未标注统计周期，2.1 万小时通过上下文判断为六个月口径但新闻稿未显式确认。本文的两项分钟级折算因此也只能作为量级参考。
还有一层需要说明的背景：同一时期 ServiceNow 也出现在其它发布中，包括 10 月 21 日宣布 Arc 个人长时运行智能体正式可用并由 NVIDIA OpenShell 强制执行其动作，以及被列入 2026 年 IDC AI 赋能 IT 服务管理软件 MarketScape 的领导者象限（报告编号 US54115226，2026 年 9 月，其中提到超过 85% 的财富 500 强在用 ServiceNow ITSM）。这些信息有助于理解本案例所处的厂商生态位，但不构成本案例数据的独立验证。
对正在评估同类项目的团队，本文的建议是把这个案例当作「路径可行性」的证据，而不是「收益可复制」的承诺。真正需要自己测的三个数是：你的工单里有多大比例属于可结构化分类、路由错误率能降到多少、以及采纳率在三个月后还剩多少。这三个数测出来，收益区间自然就清楚了。