Pillar article

无人谈论的联合销售归因难题

2025年10月25日7 min read

无人谈论的联合销售归因难题

问一位联盟经理,上个季度合作伙伴到底影响了多少收入。你会得到两种答案中的一种:一个财务部门没人相信的自信数字,或者一个耸肩。这两种反应其实来自同一个根源。联合销售归因,也就是公平地为合作伙伴在一笔交易中所扮演的角色论功行赏的能力,在大多数 B2B 收入组织中都是失灵的,而且很少有人愿意在会议上把这一点说出来。

之所以没人愿意提,是因为归因是一个政治问题。当一笔交易成交时,AE 想要拿到提成。合作伙伴想要能够证明他们在你的生态系统中投入的时间是值得的功劳。联盟团队想要一个能证明这个职能值得增加人手的数字。每个人都有理由声称这笔交易归自己,而 CRM 从来就不是为了充当裁判而设计的。于是这个问题最终靠一张电子表格、一些直觉判断,以及一场让所有人都有点不爽的季度谈判来解决。

CRM 看不见合作伙伴

CRM 的设计初衷,是围绕"一个卖家、一个买家、一个商机"展开的。这对直销来说完全没问题。但一旦第三方介入,引荐了这个客户、帮忙预热了关键决策人、在你和竞争对手之间为你说了好话,或者出席了最终的报价会议,这套体系就开始失灵了。

商机对象上通常会有一个"合作伙伴"字段。它是一个单选下拉框,销售代表只有想起来的时候才会填,而这种情况并不常见。它没有办法表示两个合作伙伴都接触过这笔交易、一个负责获客而另一个协助促成成交,也没办法表示一个合作伙伴施加了影响、却从未出现在任何一次记录在案的通话中。这个数据模型里根本没有"共享功劳"这个概念的词汇,于是功劳就这样凭空消失了。关于这一点,我们在为什么合作伙伴来源的收入在大多数 CRM 中是不可见的一文中写得更详细。

往下游看,这个问题代价高昂。如果合作伙伴影响的 Pipeline 没有被记录在系统之中,那么每一份仪表盘、每一份董事会材料、每一次预算讨论,都会低估生态系统实际做出的贡献。相关项目会因为"看起来没用"而被砍掉,而不是因为它们真的没用,只是没人能看见它们的成效。

它在两个方向上都会失灵

归因失灵并不只是偏向一个方向。通常一家公司会同时存在"计功过多"和"计功不足"两种情况。

计功过多,是指所有接触过一笔交易的人都声称这笔交易全部归自己。把联盟团队报的"合作伙伴来源"、AE 报的"自主开发",以及需求生成部门报的"市场影响"加在一起,总数往往远远超过实际的成单业绩。财务部门注意到了这一点。然后财务部门就不再信任任何这些数字,并开始悄悄地对合作伙伴团队上报的一切数据打折扣。

计功不足则更糟,而且更难被发现。一个合作伙伴在交易成交的十八个月前做了一次热情的引荐。等到这笔收入真正落地时,这次接触早已被淹没在五十条记录在案的活动之下,合作伙伴什么也没得到。那个真正打开大门的关系,在纸面上看起来就像什么都没做过一样。这样的情况发生几次之后,你最好的合作伙伴就会不再给你介绍交易了。他们也不会告诉你原因。

很大一部分困惑,来自于把"促成一笔交易的获客来源"和"影响一笔交易"当作同一个指标来对待。它们并不是同一回事,把它们混为一谈来衡量,会让两者都失真。我们建议阅读如何衡量被影响与被获客来源的合作伙伴收入,把它们当作两个独立的、各自成立的业务动作来运营。

时机与交接会切断追溯链条

归因是一个数据模型问题,但同时也是一个时序问题。合作伙伴的参与很少发生在某一个干净利落的时间点。一次引荐进来,在队列里排队等待,被分配给某位销售代表,逐渐冷却,又被另一个合作伙伴重新激活,最终才转化成交。每一次这样的转手,都是追溯链条可能断裂的地方。

而交接环节,正是链条最常断裂的地方。当一个合作伙伴把一条线索交给你的销售团队时,其中的上下文,比如谁是关键决策人、是什么痛点引发了这次对话、合作伙伴之前已经承诺了什么,往往只存在于一封邮件或一个 Slack 对话串里,而这些信息永远不会进入 CRM。这个商机会被重新创建,不带任何来源信息,而合作伙伴的痕迹,在这笔交易真正开始推进之前就已经消失了。这种情况发生得如此频繁,以至于我们为它专门写了一篇文章:为什么合作关系会在交接环节卡壳,以及如何解决。

多方参与的交易会让这一切变得更糟。当一笔超大规模云服务商市场交易、一个系统集成实施伙伴,以及一个独立软件供应商(ISV)集成同时接触同一个商机时,一个下拉框根本无能为力。你需要的是真正的多方交易归因模型,需要提前商定好,而不是一个从来没人真正同意过的"首触为王"的默认规则。

真正的解决方案是什么样的

一个更大的仪表盘解决不了这个问题。大多数组织缺失的是三样东西。

第一,是一个允许一笔交易存在多方参与的数据模型。功劳需要能够以角色的形式表达(获客来源、施加影响、联合促成、履约交付),并附带时间戳,而不是一个单一的所有者字段。在底层的数据模型支持共享功劳之前,上层的任何报表都无法还原出真实发生的情况。

第二,是在事情发生的当下就捕捉信号。合作伙伴的接触必须在引荐发生或联合销售通话进行的那一刻就被记录下来,而不是几个月后再靠某个人的记忆去重建。这意味着要为合作伙伴参与的实际时刻搭建数据基础设施,而不是寄希望于销售代表在季度末回头补填字段。他们不会这么做的。

第三,是一套提前商定好的归因政策。联盟负责人能做的最有价值的事情之一,可能就是在季度开始之前,趁着大家都还心平气和、也没有任何提成压在这个答案上的时候,把功劳分配的规则谈妥。首触、多触、加权,具体采用哪种模型其实没那么重要,重要的是所有人都提前对它达成了一致。

这三件事的本质,都是要把 CRM、合作伙伴门户、市场平台,以及对话实际发生的各种工具中的信号连接起来,让功劳真正反映实际发生的情况。为收入编排而构建的平台,会把归因当作一个持续的、多方参与的数据问题来处理,而不是成交时才去填的一个字段。以我们的经验来看,这是让这些数字最终能够对得上账的唯一方法。

关键要点

  • CRM 中"一个卖家对应一笔交易"的模型,无法表达合作伙伴影响的收入,于是功劳就这样悄悄消失了。
  • 大多数公司同时存在计功过多和计功不足的情况。前者会失去财务部门的信任,后者则会失去你最好的合作伙伴。
  • 交接环节和漫长的时间间隔,是追溯链条最常断裂的地方,多方参与的交易则会让情况更糟。
  • 获客来源和施加影响是两种不同的业务动作。要分开衡量。
  • 解决方案是一个多方参与的数据模型、在事情发生当下就进行的信号捕捉,以及在季度开始前就商定好的功劳分配规则。在旧模型上套一个更漂亮的仪表盘,解决不了这个问题。

解决了归因问题,内部关于功劳的争执基本上就会消失,但更大的收获,是能够清楚地看到收入究竟从哪里来,从而把资源投向真正该投的地方。如果你正在重新思考合作伙伴信号如何在你的收入引擎中流动,Revnewo 的方法能把这些接触点串联成一幅你可以在财务部门面前站得住脚的完整图景。

See revenue orchestration in action

Unify your revenue data, signals, and plays on one AI-native platform.