SDR团队在SaaS企业中能够连接市场和销售，拓展公司的业务体系，大热的SDR究竟该如何根据公司实际情况进行管理呢？

今年以来，由CMO技能下沉引发了很多讨论，其中“要更直接地为业务绩效负责”成为主流声音。

而以此为前提，B2B企业（尤其是SaaS企业）市场部的组织职能也自然需要进一步延展，于是链接市场与销售的SDR(Sales Development Representative)职位一下子火了。

2016年还在北森时，在梳理整个营销体系与销售体系的协同机制时，自然涉及到了要重构公司的销售拓展体系。为了少走弯路，我们做了很多研究，包括专门邀请Salesforce新加坡的SDR负责人来交流。再后来我们在苏州重建了一个14人的SDR团队，我称之为SDC(Sales Development Center)。

对于这个团队从建立到后期管理进化，有一些自己的体会和心得，所以，今天我们就来聊聊关于SDC管理的一些内容。摸索前行的路上，需要不同观点的相互碰撞，希望我们的一手经历和思考也能对大家有一些启发。

一、Why：我的企业需要SDR团队吗？

为什么开始永远比如何开始更重要？

我们先来说一下，为什么以及在什么情况下我们的企业需要SDR的角色？

彼时，当我们梳理了“认知-流量-线索-MQL-SQL-商机-成交-增购复购/转介绍”的全链营销漏斗之后，发现按照之前的流程，市场部门仅负责到输出线索为止，而销售团队却希望接收的线索能够立即创建商机。

因此，在线索和商机之间的环节就出现了断点。这个断点到底是由市场向后延伸，还是销售向前延伸，自然要考虑ROI的问题，也就需要思考如下几个问题：

• 从公司整体来看，销售体系是缺线索“喂不饱”？还是线索保有量不错，但商机质量不高？
• 从线索到商机之间的培育和挖掘到底是由销售一对一来做效率更高？还是规模化效率更高？
• 企业里是否充分部署了Martech工具，以满足提供复杂产品/服务的B2B企业的商机培育？

因为当时我们对前两个问题的答案都是后面一种情况，于是毫无疑问，SDR这个工作就决定放到市场体系。

同时，又因为当时我们的数字营销体系正在搭建过程中，除了前端的SEM统计分析工具和网站UBA及A/B测试工具，中间非常重要的营销自动化系统还没有上线，因此对于第三个问题的回答也自然是否定的。

但退一步讲，2016年的那个时间点，Martech工具在国内市场的规模还相当有限，而国外比较成熟的市场上，就算MA系统上线，也不能够完全替代人工商机培育工作。

所以，综合分析下来，我们最终决定建立一支专业的团队，通俗来讲就是靠人力来弥补工具的不足，SDR团队于是应运而生。

上面之所以对为什么建立SDR团队的过程做了详细回溯，是因为在那之后两年的管理中，深切体会到这支团队“建立容易管理难”。所以，也真诚地建议在建立团队之前，还是要经过深入的思考。

为了便于大家考虑SDR团队在一般意义上的必要性以及在不同企业中的定位，我尝试着根据之前的实际经验，画了一张图表。

通俗地讲，一家B2B企业本身产品和业务复杂程度越高、市场体系用于线索培育和商机挖掘的Martech工具完善度越低，SDR团队就越有存在的必要性，且他们要承担的职责越是以商机的挖掘和培育为主；反之，如果业务不复杂，Martech培育工具（MA）又很成熟，理论上就没有费时费力建立SDR团队的必要。

二、How：SDR团队的几个管理难点

SDR团队不管规模有多大，它承上启下的角色定位以及价值呈现的间接性特点，就决定了其管理的难度。

因此如何确认绩效、如何激励以及如何保留和发展都成为管理中的核心挑战。

下面来分享一下我们当时的实践，当然更重要的是背后的思考逻辑：

1. 核心考核什么绩效指标&谁来当裁判？

“考核什么，员工就会做什么”，这是一个不言自明的道理。

既然当时我们在设立SDR团队的时候是为了输出更有价值，即更接近商机的合格线索，从而能够使销售体系的时间价值最大化，那么我们自然就对SDR团队考核了商机这个指标，而这样严格的绩效指标也为了确保SDR团队在体系中的业务价值（更接近业务指标）。

注：具体考核的指标停留在营销漏斗的哪个环节上，每家企业都要看内部pipeline的充沛程度，以及站在整个公司的立场，销售体系的诉求是缺线索量、还是更缺质量，就如第一部分内容里我们思考的第一个问题。

接下来的问题就是谁来做裁判？

既然一直以来销售总爱以“市场提供的线索质量不高”来给自己的业绩差找借口，那SDR转出的商机线索就由销售来判定。

但把绩效的命运放在销售手里，SDR小伙伴们也会有担心啊。为了确保“商机”绩效达标，SDR们很可能会有两种表现：甩锅，抱怨销售跟进不力；协同销售作弊（“贿赂”销售创建商机）。

为了规避这一系列问题，就需要配套一点小机制来约束两个体系，并牵引他们通过良性的通力协作来最优化双方的业绩：

• 反馈时间：SDR输出给销售体系的MQL，48小时之内销售必须在CRM里操作，如果接受即视为SQL；如果经过SDR友好跟进，任何一个销售连续出现两次不能及时处理的情况，就会丧失一个月内接受市场MQL的资格。
• 商机标准：销售在接受SQL之后，在30天内（后通过统计数据，调整到了45天）创建商机且在两周内无故撤销商机者，才记为SDR的业绩。以此来激励SDR们既不会过度把商机挖掘的责任寄希望在销售身上，尽量输出接近商机的MQL，也能够不把商机挖掘的全部责任都放到SDR身上（毕竟业务专业性高的时候，新成立的SDR团队在复杂商机的把握上不如销售们专业和高效）。与此同时，还能避免两个团队协同作弊。
• 分配原则：可以接受市场MQL的销售，由销售管理部（或运管部）根据销售体系的业绩达成率，每月提供名单给到SDR团队，SDR团队按照销售的部门分布，来平均轮流分配线索，以避免SDR们出于人情原因出现分配的偏颇。

2.怎样的薪资结构，对SDR更有激励性？

前面说到当时在北森我们把“商机”作为SDR的核心绩效指标，但由于我们的业务周期比较长，商机的认定本身也需要一定的时间，所以基于这个指标的考核对于SDR们注定是个中期的激励效果。

但是因为SDR们工作的实质并没有那么“有趣”，也不似销售的业绩那么直接，所以这个团队的报酬体系中必须平衡一下短中长期的回报，才能够更有效地激励大家。

于是我们对于新兴的SDR团队设计了如下的激励体系：

1）短期激励：奖励突出的行为，做月度单项奖

比如，刚入职的SDR一般需要两个月左右的培训和演练的时间，这个期间无法进行业绩考核，但是我们设置了和学习以及Roleplay相关的单项奖，奖金额度不大，但重在激励大家进入到一个积极的状态。

2）中期激励：考核行为指标+商机指标，按季度计算绩效奖金

根据我们的平均成交周期，我们认为按照季度考核SDR的业绩是比较合理的。但因为商机的创建动作并不在SDR自己手中，为了避免阶段性的被动等待，我们把SDR的通话时长、接触客户数量等行为指标也纳入到绩效计算当中，占到了一定比重。

3）长期激励：销售收入的小比例分成，按年度计算额外奖金

同样的商机数量，其价值一定是不同的，如何让输出更高质量商机的SDR能够受到更多的激励？

我们决定从商机输出后最终成交的业绩中拿出来一个比较小的比重，在年底对SDR们进行一个额外的奖励。这样的长短期综合下来，我们基本上确定了激励体系的长效性，以及牵引了SDR们对于数量和质量的双重关注。

3. 有点“尴尬”的SDR职位，未来的发展方向在哪里？

这里提到尴尬，绝不是因为对于SDR这个职位有任何歧视。相反，在当下这个阶段，SDR团队对于很多企业的价值是非常显著的，而SDR的能力模型以及相应的薪资待遇也是可以不亚于销售的。

但之前与国外同行交流时，对比中不难发现，中国B2B SaaS行业正处于快速发展的阶段，各个职能的人才都处于供不应求的局面。

因此，同样的年轻高潜付出同样的时间和努力，在销售体系中很有可能拿到更高的收入以及看到更确定的职业未来。

说白了，选择太多的时候，做SDR这个尚在摸索的职位就意味着更高的机会成本。

对此，但凡管理SDR团队超过一年以上的同行都不难发现，这个岗位人难招，招到了也难保留，一个SDR的平均留任时间即使在国际上也不过12-18个月，在我自己的实际经验中，也没有高于这个数字。也因此，在招聘初期，就要清楚地规划出SDR们的职业发展方向是非常重要的。

之前吴昊老师的文章里也提到了，业内大家普遍的观点大致有三个方向：在SDR体系里持续发展，直到成为管理者；转岗做销售；转为服务（包括客户成功服务）。

我们自己的团队曾经试过不同的SDR的能力画像，最终发现，SDR的能力素质更加接近销售的高潜。

所以，在招聘的时候，我们就开诚布公地跟候选人说，我们开放地为大家提供未来的职业机会，其中更会支持大家去做销售，但在那之前，在SDR团队里历练两年会是非常有价值的过渡。

实际中我们也确实是这样做的，而我们的SDC在两年中也先后为销售体系输送了多位出色的销售。

三、实践场景探讨

管理不是数学，有科学的部分也有很多艺术的成分。因此，我们同样很难用一个公式就解决所有SDR团队的管理问题，在不同企业的不同阶段，我们总会遇到一些或共性或个性的实际问题，需要不断去思考和解决。

具体的方法总会千差万别，但如果能够找出一些共性的处理原则就是更有价值的经验。

在整理这篇文章的过程中，我们在社群中看到同行提出了另外一些非常具体的问题，在这里我们也分享一下面对不同情境时，我们的一些处理原则，以及有些情况是如何可以避免成为一种我们必须去面对的管理情境的。

大型企业的关键决策人一般不会是单线，而是有 HR/IT/运营/制造等多个条线，这些条线一般会通过不同途径去接触，销售、SDR、市场培育等会一起来推动。下面假定了三个场景：

场景一：

SDR邀约了HRD，销售去拜访，结果没有项目；几个月后HRD参加了某场活动或者线上找到我们，想做项目；那么这种的商机来源是SDR，还是活动？

场景二：

ITD（ITD=IT总监）线上找到我们，说想来做项目，安排HRD一起来推动，结果没有立项起来，ITD离职了；SDR接着维护这个客户，一个月后HRD起来把项目立起来了，这个商机来源怎么算？

针对这两个场景：

首先我们要问一下，区分这个商机来源的目的是什么，是为了核定不同团队的绩效，还是为了数据分析进而去优化我们的商机培育策略？

如果是出于业绩核定的需要，在我们之前的管理实践中，由于我们是把SDR放在了营销漏斗中的一个环节——商机线索的输出环节，即全渠道的市场线索都会先进入到统一的市场线索库（MA系统中）进行培育和打分。

而SDR们是在这一营销自动化系统（MA）的协助下，统一对打分较高接近输出标准的线索进行qualify和进一步的商机挖掘，因此考核SDR们的商机业绩目标其实就是整个市场团队的业绩目标。

简言之，市场部的各个团队实际上是为了一个共同的目标在流程上进行分工协作，因此从核定业绩的角度，我们并不需要去详细区分商机出现的时间点是在SDR沟通中还是活动后（从整个市场职能来看，SDR和活动、系统中的内容本来就都是线索培育和商机挖掘的手段），是ITD找上我们的，还是HRD找过来的。

只要线索是集中经过了市场的培育包括SDR的挖掘最终建立商机，就会记到SDR团队的业绩中（实际中，Inbound商机和Outbound商机我们给予SDR的奖金数额是不同的，前者低一些，因为SDR付出的努力相对更少一些），而那个特定的客户是由哪个SDR分管，这个商机也会相应地记到哪个SDR的业绩当中（只是，如果哪个SDR经常出现这样的情况，我们就会反过来关注ta的能力与其他SDR比是存在怎样的GAP以及需要给出怎样的培训和辅导等）。

当然，我们这样的做法并不意味着完美，只是在管理实践中我们不得不思考ROI的问题，即如果为了追究那一个商机的来源所付出的管理精力，对于整个公司而言并不会创造出任何新的价值，有的时候该简化的也就简化了。

在我们的业务逻辑中，相比商机来源，我们会严格标记最初的线索来源渠道，用以日后优化我们的线索获取策略。

当然，各个团队除了核心商机业绩目标之外，还有其他的业务目标，我们都在OKR体系中进行了个性化的设计，不同团队因为在整个获客和培育的漏斗中起到的作用不同，他们的薪资结构和激励制度也有相应的差异。

场景三：

SDR邀约了ITD，销售拜访了，但是ITD不置可否；两周后某个伙伴说这家客户有机会，介绍的还是这个ITD，还真有项目，这种商机来源怎么算？

针对这个场景，由于涉及到了内部团队和外部合作伙伴的绩效确认及相应的利益，当然需要更加清楚地界定。

北森之前没有外部渠道伙伴，但就我之前的销售管理经验而言，这会涉及到系统的商机报备制度。一般而言，我们既会确保第一触点人的利益，也会保护真正商机挖掘者的利益。

因此，需要在制度中明确规定，如果合作伙伴带来的商机是SDR在培育的线索，合作伙伴能拿到的佣金会是正常情况下的一定比例而不是全部，这一原则也同样适用于SDR。

四、Trend：个人的终极目标——SDR能够被取代

不管是看过往我们自己的实践，还是同行们在管理中遇到的其他个性化的业务场景，我们都不难体会到SDR团队管理的实际难度。

再考虑到现实的ROI，我一直悄悄地期待：什么时候能够用其他工具和方法，逐渐替代SDR们，让小伙伴们不尴尬、企业也可以省去为一支小规模团队而耗费大量管理资源和精力的现状呢？

其实从2017年开始，我就在思考以后如何通过软件和工具的力量逐渐替换掉SDR团队。

从营销技术的发展趋势上看，在SaaS企业的数字营销体系中，随着自动化工具及AI技术在线索培育、商机挖掘、潜客沟通等场景中的应用越来越成熟。

只要拥有足够的数据历练，我坚信不管我们的实际业务有多复杂，从市场体系（MA）输出到销售体系（进入CRM）的线索质量也一定会越来越符合销售们实际的期待和需求。到那个时候，我希望销售高潜的小伙伴可以更加直接进入到销售体系，在工具的辅助下进行更加有效率的销售过程管理。

最后，管理的情境很难被穷尽，我们这篇旨在探讨一些关键问题的文章也不可能把SDR团队的管理难题都覆盖到。更挑战的是，对于一个还在成长发展的事物，没有谁敢说还没有经过足够长时间和数据检验的经验就是最佳实践。

我们以上的所有分享也只是我们的尝试和背后的一些思考，所以也不敢称之为最佳实践。

更多个性化的场景和相应的实践，还需要同行们一起来持续探索。

最后的最后，期待与大家有更多的探讨和交流！想必大家都在为了最后一个季度冲刺吧，一起加油吧！

作者：高燕；公众号：乱炖营销（ID：Luandunyingxiao），B2B营销就该简单美好，有趣有效

本文由 @高燕 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议