合并之后：Sirva 如何把两套服务系统收敛为一个平台

合并造出了规模，也造出了两套互不相通的工作方式

Sirva 是全球最大的搬迁与流动性服务提供商之一，帮助企业把员工送到 190 多个国家。它的业务范围不只是搬家具：家居物品运输、目的地服务、跨文化语言培训都在服务清单里，客户是全球一些最大的企业。规模足够说明它承接的复杂度——每年搬迁超过 100,000 名员工，处理超过 175,000 次搬家。

这个体量来自一次合并。今天的 Sirva 由 Sirva 与 BGRS 两家老牌流动性服务商合并而成，合并带来规模，也带来把系统拼在一起的难题。原 BGRS 组织在 Zendesk 上运行了七年，有结构化的案件跟踪和 SLA 可见性；原 Sirva 的搬迁顾问主要通过 Outlook 与客户沟通，组织内还散落着其他 CRM。

结果是同一家公司里存在两种服务模型，运作逻辑从根上不一样。管理层要一致地追踪响应时间、衡量 SLA 表现，或者评估家居物品运输、目的地支持、语言培训这些不同服务线上的投入，都需要额外动作。跟踪一次交互、度量一次表现、量化一份工作负荷，都要走好几步。

电话侧并非空白——RingCentral 已经在用，但组织自己判断，要准确衡量通话量、接通率和回复质量，手上的数据还不够扎实。缺一个统一系统，全局视角就一直是个待办事项，而不是一张能看的报表。

决策冲突不是"CRM 不好用"，而是"够用但不够远"

值得注意的是，Sirva 换平台的理由并不是现有系统坏了。运营副总裁 Ricardo Baez 的表述很克制：他们未必对既有 CRM 不满意，但需要的东西超出了它能提供的范围——一个能统一运营、提供 AI 驱动洞察、并在全球所有服务线上扩展的平台。

这句话决定了项目的性质。如果起点是"系统故障"，那么合理动作是修补和补数据；如果起点是"能力上限"，那么动作就变成换底座。Sirva 选了后者，管理层的优先级被明确列为技术、速度、创新和洞察，在分析了自身技术栈和长期目标之后，决定转向 Dynamics，理由是它更好地支撑合并后的整体业务运作。

技术选择上，Dynamics 365 Contact Center 相比既有 CRM 提供了更大的集成灵活性，能原生连接 Power BI、Power Apps 和更广的 Microsoft 生态。统一平台的技术组合包括 Dynamics 365 Contact Center、Copilot Studio、Power Apps 和 Power Automate。首席技术官 Joe Genautis 把这次变化描述为对交付方式的重塑：把人、全渠道互动、实时数据和 AI 驱动洞察连起来。

顺序在这里很关键。AI agents 与 Copilot Studio 是与平台部署同时推进的，但它们服务的对象是搬迁顾问，而不是替代平台本身要解决的可见性问题。先有统一的案件与交互数据，助手才有可用的上下文。

先迁一个团队三类服务，再谈全组织铺开

迁移不是从全球一起切换开始的。Sirva 先在自己的 Microsoft 搬迁服务团队上部署新生态，这个团队大约 40 到 50 名顾问，负责为 Microsoft 员工在全球范围内管理搬迁。从作出迁移决定到该团队在 Dynamics 365 Contact Center 上线，大约 90 天。

首批 rollout 刻意覆盖了三类不同的服务形态，而不是挑最简单的一类：顾问直接管理搬迁的一对一模式；通过 Sirva 全球流动性卓越中心服务 Microsoft 内部 HR 与人才招聘等相关方的一对多模式；以及一支设在印度的国内搬迁团队。一次试点同时压到三种协作结构上，暴露的问题比单一场景更完整。此后 Sirva 才把更多团队迁到平台上。

过渡设计上有个明确取向：对已经习惯 CRM 工作流的成员要保持熟悉感，同时为业务中其他区域引入更结构化的运作方式。原 BGRS 侧的顾问本来就有案件流程习惯，原 Sirva 侧从 Outlook 沟通转向结构化案件，改变幅度更大——这两类人的迁移成本本就不一样。

人机分工被 Baez 说得很直接：他们实施的任何东西都不会把搬迁顾问移出流程，agents 是顾问的助手。落到具体功能上，客户在 Connect+ 门户提问时，系统能识别其适用的政策并即时响应——这是既有 CRM 做不到的动作；顾问侧则拿到案件摘要、交互要点和结构化工作流。

采用的控制手段有两层。内部一层是 AI Hive，一个放着最佳实践、知识文章和整理过的提示词的内网中心，用来支撑跨团队的结构化采用。客户一层是授权门槛：搬迁数据可能包含薪资、护照和移民信息，因此客户采用相关技术需要主动 opt-in。这意味着能力上线不等于全客户可用，推广节奏由客户同意决定。

至于质量验证和异常回退，官方材料未披露正式的验收门槛、准确性测试方法与回退机制。已披露的相关动作是一个仍在开发中的自定义 agent，它对照客户政策审查搬迁顾问的回复以衡量准确性，并通过自动化仪表板呈现质量指标——但这属于开发中的能力，不是已经在跑的质量控制流程。

两个结果数字分别在说什么

官方结果卡给出两项：平台在不到 4 个月内上线，以及组织已有 100% 运行在单一平台上。这两个数字都要按原口径读。

"不到 4 个月"指的是 Dynamics 365 Contact Center 在全球运营范围内部署上线的周期，与之前提到的首批团队约 90 天上线不是同一个刻度：一个是全球部署窗口，一个是首个团队从决策到上线的时间。官方材料未披露各地区的分批日期、上线判定标准，也未披露遗留系统的下线范围。

"100%"是覆盖口径，指整个 Sirva 组织在同一个服务平台上运营，正文里的对应表述是顾问现在手边就有案件摘要、交互要点和结构化工作流。它说明的是平台归属，不是使用强度——活跃使用率、各团队实际采用深度都未披露。

还有一类数字容易被误读。Sirva 的年度搬迁与搬家规模是业务体量的背景，用来说明平台要承载多大的服务量，它既不是这次项目产生的成果，也不是 AI 处理的工作量。同理，管理层现在获得的 SLA、工作负荷与客户服务可见性是能力描述；具体到 SLA 达成率、响应时间、接通率、案件处理时长和回复质量各变化多少，官方均未给出数值。

顾问生产力这一项也停在定性层面。官方表述是 AI agents 用于提升搬迁顾问生产力，没有给出度量定义，也没有说明是否计入人工复核、升级和异常处理所占的时间。在没有基线和定义的情况下，把它当作已量化的效率成果会超出证据范围。

这套做法能迁到哪里，前提是什么

可迁移的部分是顺序，而不是工具清单。Sirva 的路径是先把分散的服务系统收敛成一个底座，再往上放助手能力；如果一家公司的可见性问题源于系统割裂，先上 AI 只会让分散的数据产生分散的输出。这条顺序的前提是组织愿意接受平台层的更换成本，并且业务侧有人主导——这里的主导来自运营与技术管理层，不是纯 IT 项目。

助手定位那条边界值得直接借用。把 AI 明确写成"顾问的助手、不把人移出流程"，在监管敏感或专业判断密集的服务里降低了采用摩擦，也让责任归属保持清楚。配套条件是两个控制手段同时存在：内部有知识与提示词的集中入口，客户侧有明确的授权门槛。缺了后者，涉及薪资、护照、移民这类数据的场景会直接卡在合规讨论上。

需要自行补齐的是度量。这个案例已公开的结果集中在上线速度与平台覆盖，服务质量、顾问生产力和成本侧都没有数值。想复现类似项目的团队，应当在启动前就定义好 SLA 达成率、响应时间、案件处理时长和回复准确率的基线与采集方式，并把人工复核与升级耗时算进生产力口径——否则项目结束时能证明的，同样只有"平台换完了"。