BCG与McKinsey：把业务改造写进系统

销售人员收到更多推荐，未必卖得更好；客服增加一个语音Agent，未必解决更多客户问题。业务改造的难处，是技术改变以后，原来的决定、动作和协作怎样重新接起来。

BCG与McKinsey的公开案例分别提供了销售推荐和电信客服两种入口。材料由实施方发布，能观察其公开的建设方法，不能凭品牌或案例页面认定因果收益。本章不把所有咨询项目改称FDE，而是比较它们与现场共同工程重叠的部分。

Caldic：销售推荐首先要进入销售动作

BCG介绍，全球原料及特种化学品分销商Caldic与BCG及BCG X共建销售推荐应用，结合企业内外数据、AI及生成式AI、简单界面与客户价值，并配套销售人员培训。页面没有披露足以独立复算的经营结果，本书不采用其速度或利润宣传。¹

这里可观察的分工，是业务经验进入应用建设，而不是只在开发前给一份战略报告。推荐为什么适合这位客户，销售人员收到后该做什么，客户回应后下一次推荐怎样改变，属于同一条工作链。

为了检查这种链条，可以设计以下教学试验，不能视为Caldic已公开的操作。给销售人员一组真实且经授权的客户记录，包含停止采购、价格约束和供货不足。让团队标出哪些推荐值得联系、哪些必须先核对库存、哪些不应出现。把“没有采取推荐”的理由保存下来，区分系统错误、资料缺失、销售判断与客户选择。

如果拒绝原因总是缺货，先改供货数据与筛选条件，未必需要换模型；如果推荐合理但没人执行，要检查任务分派和激励；如果销售人员只是照单全收，短期采用率也不能替代质量证明。业务咨询要能改变这些条件，技术团队要把改变落实成可测试的行为。

KPN：一通电话连接了哪些决定

McKinsey与QuantumBlack的KPN案例，把匿名化通话用于识别常见需求，再连接核心电信系统、开展用户体验测试和人机评价。文中还区分适合自动处理的事务与需要人工关怀的敏感情境。²

这比把电话全文交给模型回答多了一步：先确定哪些请求值得进入自动流程。核验身份、查询订单、改预约与排查故障，即使都出现在同一通电话里，也需要不同的记录和动作。语音理解只负责其中一部分；身份无效、系统超时或客户中途改变要求，都需要明确的后续路径。

KPN案例描述每日检查最多100通真实电话，上午讨论反馈、下午调整、晚上发布。这个数量是案例中的检查上限，不是整个呼叫中心规模或样本充分性的证明。文中10%—20%的客服互动由Agent处理，是2027年的目标，不能提前记成已实现的成绩。²

日常改进的价值，也不能仅由更新频率衡量。若只看已成功通话，会漏掉转人工后的负担；若只记录Agent挂断前的时间，会把之后的重复解释藏起来。客户在电话中完成了什么、人工是否需要重新核验、核心系统有没有正确更新，应当分别观察。

业务负责人必须参与哪些审查

两种案例分别从推荐和服务进入日常工作，但都无法由工程师独自回答“怎样算有用”。销售负责人要判断推荐是否适合当前客户关系，客服负责人要判断哪些情境应交给人。系统团队则负责证明这些决定已经进入代码、数据与权限。

本书建议把审查分成三个有衔接的动作。业务人员先解释一个真实请求的正确处理；工程团队用同一请求展示系统轨迹；另一位业务人员检查结果能否接入下一步工作。发现问题时要指出它落在哪一层：理解错、资料错、规则未实现，还是动作未完成。否则会议容易变成“回答还不够聪明”，团队也不知道下一次改什么。

评价也应允许业务假设被推翻。推荐应用若只是重复销售早已知道的机会，可以缩小投入；自动客服若在低风险事务中有效，却不能处理敏感情况，可以保留人工分工。缩小边界是可能的验收结果，不必把每个试点都推成全面自动化。

顾问撤离后，谁能继续改

这类合作最容易留下两种不同资产：一套能运行的系统，以及业务团队解释问题和改变系统的能力。前者上线很容易被看到，后者需要实际演练。

沿本章两类工作作一次接手演练：请销售团队解释一类新的拒绝理由，或请客服团队定义一种必须转人的新情境，再看内部工程能否把决定改进系统并验证。业务解释权与工程修改能力缺一不可，也不要求客户能够修改供应商的底层模型。一般交接与退出过程见采用与接手、边界与退出；培训出席仍不能代替实际演练。

BCG X与QuantumBlack的名称，提示咨询公司内部也可能具备设计与工程能力；具体项目仍要检查实际参与者。经营建议能否进入系统，系统变化能否被经营者理解，决定了共同工程是否真正缩短了从想法到使用的距离。