CRM必须理清知识点2：用户、客户的逻辑关系

 CRM必须理清知识点2：用户、客户的逻辑关系

互联网讲用户，CRM讲客户，运营讲用户，销售讲客户，不同场景有不同的叫法有什么特殊的考虑呢？如果我们没有系统，直接买个CRM系统，很好办，用户，客户无所谓，CRM通吃。如果我们是一家互联网公司，突然某天老板说了，我们要建一个CRM系统，如果不深入吃透这两个概念，我们会踩不少坑。

譬如：某个用户是系统已有的用户，又被市场团队外采到，CRM系统如果未考虑与系统的用户融合的话，销售在推进中就很容易被用户说：“你们家有毛病，我已是你们会员了，还老给我打电话推销入会？”

处于阅读体验考虑，下面用表格方式向大家呈现：

2.2.3 产品设计应对策略

策略1：CRM的客户表增加用户标识，当是用户时，在CRM系统中呈现用户在平台的必要行为数据；

策略2：用户数据自动实时向CRM数据表同步（同步到特定账户头上，如销售总监头上，销售总监进行调度分配）；

策略3：用户表向CRM表做自动同步时，如果命中CRM已有客户时，做自动绑定；

策略4：外采线索，手动单条录入客户时，如果命中用户表，做数据自动提取；

策略5：外采线索，手动单条录入客户时，如果命中用户已被其它销售占用，提醒禁止录入；

策略6：外采线索，手动单条录入客户时，如果命中用户未被其它销售占用，提醒移入自己名下；

策略7：外采线索，批量导入客户时，如果命中用户，强制跳过；

策略8：外采线索，百度等SEM通过API自动同步数据时，如果命中用户，强制跳过；

2.3 CRM必须理清知识点3：线索、商机、客户的逻辑关系

首先用我总结的一个表来把几组概念放到一起，方便大家有个整体盘感。

熟背上表是否代表我们完全理解“线索、商机、客户、合同”的关系了呢？不，尤其是作为产品经理的我们，还必须掌握如下几个背景知识点：

其一就是公司的组织架构中是否有运营、销售的强分工概念。

其二就是销售业务链路是否很复杂，有没有必要对“线索、商机、客户”多节点细化管理。

简易业务场景中，“线索、商机、客户”三组概念可以合并到“客户”概念中，“合同、订单”可以合并到“订单”概念中。用一个概念管理的好处是：培训成本低、操作成本低、市场节奏快、管理成本低。

复杂业务场景中，组织分工明确的场景中，就需要精细化管理了，通过精细化管理分别考核不同组织的战绩，各个组织在专业方向上猛攻，通过团队协同拿结果。

针对这种情况，我们在CRM的架构设计时，可以通过如下策略来满足不同的业务场景：

• 策略1：线索和商机是选配，可以启用也可以不启用——走下述策略2、策略3；
• 策略2：“线索-客户-商机”三者之间“互挂”——穿透管理设计策略；
• 策略3：“合同”和“订单”进行“互挂”——穿透管理设计策略；
• 策略4：订单复用“工单”的OA任务流引擎。

其三就是我们需要了解“线索、商机、客户”底层对应的业务原理。

业务开发中：营销部门去发现、寻找、吸引敌人，销售部门负责歼灭敌人。通俗点讲就是营销部门负责找客户，销售部门负责打单拿下客户。

大多数的公司没有对线索做细分，把只要通过各种渠道进来的线索统统归纳到一起，然后再按既定规则分配给销售去处理，在一定的销售周期内再去考核销售的转化效率。这种考核的方式最大问题是胡子眉毛一把抓，很难从转化率层面发现问题的根本。销售和营销会扯皮，销售老大说线索质量太差，营销老大说销售执行力差。

如果我们把线索和商机拆的更细，通过更小粒度的定义来做精细化管理，这个矛盾就会小很多，人效也会更优，具体如下：

2.3.1 线索量

所谓线索要满足几个要素，比如对象、联系方式、需求属性、线索来源等。从销售角度，希望把线索分成如下几类：

2.3.2 商机量

所谓商机要满足几个要素，比如刚性需求、时间、预算、负责人等。

从销售的角度希望把商机分成两大类，一类叫做方案类商机，一类叫做投标类商机。

2.3.3 转化率

如果说线索决定销售具体动作，那么商机重点就要考虑成功率和资源投入情况了。

2.3.3.1 线索—商机转化率

由于前面把线索做出了细分，不同类线索转化时长以及时效性有明显的趋势规律，我们可以通过“线索—商机转化率”来确定线索的质量、评判市场部门的ROI。

2.3.3.2 商机—订单转化率

这个指标比“线索-订单转化率”更能科学的反馈销售的执行能力和人效价值。

2.4 CRM必须理清知识点4：合同、订单、工单的逻辑关系

老规矩，依旧用我总结的一个表来把几组概念放到一起，方便大家有个整体盘感。

这三组概念比较简单，不化过多笔墨累述。只是，我们在产品架构设计时，需要充分清楚如下逻辑关系链，否则会掉坑里：

• 一个订单可以有多个合同、一个合同也可以有多个订单——互挂设计理念；
• 合同有周期概念，合同到期会触发后续跟进，譬如与消息系统互通；
• 如果有合同，需要有配套的合同影像管理，否则将来合同模块意义不大；

备注：业务简单场景用一个即可，业务复杂场景建议拆开使用。

2.5 CRM必须理清知识点5：联系人、联系方式的逻辑关系

依旧老规矩，用我总结的一个表来把2组概念放到一起，方便大家有个整体盘感。

这2组概念比较简单，不化过多笔墨累述。只是，我们在产品架构设计时，需要充分清楚如下逻辑关系链：

• 一个客户可以有多个联系人；
• 一个联系人可以出现在多个客户名下；
• 联系人的名字、电话均允许重复——系统提供彼此的穿透透视链条；
• 不同客户的主备联系方式可以重复，系统提供查重、提醒功能；
• 人名、电话、身份证号均不可作为主键进行逻辑传导，而要用“表id”进行逻辑穿透；

2.5.1 C端客户多联系方式产品设计逻辑、字段策略如下：