关于CRM你可能不知道的七件事

CRM是一个经久不衰的话题，对于它也有众多讨论。产品经理在工作当中也时常会碰到，但是CRM的真面目你真的了解吗？本文从七个角度对CRM知识，并对其在工作中的实际应用展开分析，希望可以帮到对CRM有疑惑的童鞋。

CRM这个话题很古老，圈子里关于CRM的分享也很多。有从“权限设计角度”讲的、有从“线索-客户-商机”设计角度讲的、有从“数据报表”角度讲的，有从运营角度讲的、有从销售角度讲的……

这些分享都很不错，可以快速建立起知识体系，但总是觉得这些分享多是从已实现的角度做个结论性的分享、缺少从底层原理的剖析、以及为什么要这样做的探讨？

我们大家会有一个普遍的感觉是，这些文章读起来很爽，但要再达到一个高度，或者说自己下手设计或运用CRM的过程中，因不清楚底层的基本原理，机械的理解会导致如下两个问题：

1. 产品经理应该充分理解、充分提前预见、并在产品层面梳理出合理的解决方案，帮助团队化解研发风险、帮助企业提升研发效能、帮助运营部门灵活高效运用落地的，但因浅尝辄止、囫囵吞枣、机械理解、以猫画虎，不清楚底层原理，给团队挖坑多。
2. 看文章会导致我们机械的照搬市面上千篇一律CRM设计套路，而忽视了最本源的问题“我们的业务背景是什么？我们的业务生态是什么？我们的CRM诉求是什么？我们的CRM能否与现有的业务系统做融合创新，围绕我们的业务场景及核心用户在产品设计层面有新的产品策略、架构设计出来？否则，食之无味，仍之可惜！

本篇分享是基于我们SaaS平台建设中因业务需要在CRM方向的产品设计、研发建设及系统落地中踩过的坑以及持续迭代中的业务思考和产品处理策略的复盘总结，进而帮助大家达到：

• 澄清CRM的相关术语概念、底层原理，概念理清了，原理明白了，我们的知识图谱就建立起来，知识图谱有了，我们对CRM的很多未知和疑虑也就荡然无存了。
• 掌握CRM的引入策略、建设路线、架构设计、迭代建设策略等。结合一些具有代表意义的实践case（采坑、填坑打怪之路），纵向上从产品设计、研发建设两个角度从上往下看；横向上从权限设计、CRM系统设计、数据中心设计、绩效报表体系设计、ERP-OA审批体系设计、CallCenter系统设计、销售单兵作战工具设计等多维度平视来看，帮助大家在CRM设计、研发建设中少走弯路或不走弯路。
• 用好CRM这个神器，不把CRM当做花瓶，而是真正将市场团队、运营团队、客服团队、销售团队充分调度起来。以CRM工具为载体，将公司业绩目标自上而下分解，政策向下落地，数据向上汇总；通过活动投放、线索采集、线索清洗、销售攻城、后端履约交付、客服受理化解风险等节点将组织内部各作战单元串起来、跑起来；人效可视化，通过数据说话，来找出业务开拓的瓶颈点、逆向挖掘瓶颈原因及疏解之策。

阅读对象：打算引入CRM的决策者、打算开发CRM、打算重构CRM、正在开发但一知半解的产品经理。

一、 CRM的价值我们真的了解么？

阅读对象：打算引入CRM的决策者。

CRM如同空管指挥系统，帮助空勤人员谁负责哪条航道，负责人借助系统识别哪个飞机可以起飞、哪个飞机可以降落，飞机降落后及时通报地勤系统做好接驳保障等。

对于没有账户体系的非互联网企业来讲，CRM的核心价值不仅作为一个武器帮助销售拿下客户，也能帮助打造标准化作业流程、企业优化运营成本、构建企业数据中心，为企业搭建一个军事情报指挥系统。

对于有账户体系的企业来说，CRM作为企业数据中心的功能延伸，为销售人效提供增加动力。

1.1 采集-清洗线索、识别-挖掘潜在客户

对采集的线索进行快速清洗，提取有价值客户。

方便每一个销售机会的跟进情况（联系活动、报价单、签约单、服务单的演进情况），快速制定客户的跟进策略。

1.2 构建非对称压力销售武器：情报壁垒+专业知识壁垒

基于业务体系沉淀的用户数据，系统为每个用户建立全维度档案——CRM系统为企业建立了一个完整的客户信息共享数据库。

销售人员基于自己的专业知识和上述客户情报信息的全量掌握，为销售构建非对称销售武器。

1.3 销售业绩直观化、实时化

CRM系统能够自动生成销售报表，使销售业绩更直观的展示出来。

CRM系统与销售佣金管理相连接，可以清晰地、准确地、即时地掌控人效，调整销售结构域方向，在这一方面，CRM系统的价值就是能实现销售人员企业之间的双赢。

1.4 销售流程规范化、简明化

CRM系统具有促进销售流程规范、整合、优化的价值。

实施CRM系统能够改善企业的销售流程，加强对潜在客户的机会管理，让销售人员更加有针对性地把握销售业务的进展与销售策略。

CRM系统能够简捷地预测销售业绩，评估企业绩效，识别出现销售业务中有的问题和未来的趋势，通过这一功能，CRM系统体现出了提升企业的盈利能力的价值，为销售的成功提供了有力保障。

1.5 数据集成、人效比对、精细管理、成本优化、精细

CRM与企业的数据中心、ERP、第三方SEM系统无缝集成，实时数据交换，通过分析客户来源、客户贡献来比对渠道成本，优化投放方向、优化运营方向、寻找最优合作伙伴和最优运营策略。

CRM与ERP数据协同，将销售、库存、客服、退货等综合起来管理，降低了经营成本，提高企业的经济效益。

CRM系统的价值概括起来就是：

CRM系统能够为企业构建一整套以客户为中心的有关客户、销售、服务与支持信息的数据库，帮助企业优化管理渠道和前线业务流程，比如，市场营销、销售、产品的服务与支持、呼叫中心等。

CRM系统还能深层次分析和挖掘最有价值的客户、新的市场和潜在的客户，创造业务良机，提升客户忠信度，提升企业销售效益。

二、CRM业务知识解构、产品架构设计策略

2.1 CRM必须理清知识点1：市场、运营、电销、外呼、销售的逻辑关系

不同团队、不同行业有不同的组织架构，对于大型企业来讲，泛业务团队有如下几个兵种，即“市场团队”、“运营团队”、“电销团队”、“网销团队”、“销售团队”、“售后客服团队”。

市场团队：

工作边界：以投放广告、采集线索为主攻方向，譬如SEM、硬广投放、地推活动、会销等。

管理重心：活动成本、ROI转化率、线索质量。

运营团队：

工作边界：设计运营策略激活休眠用户、完成新用户转化、提升老用户客单价及复购率等。

管理重心：转化率、客单价、复购率。

电销团队：

工作边界：对市场、运营交办的外呼任务进行地毯式外呼，过滤无效线索、提取有价值线索、诱导激发客户的需求意向、直接成交或移交给销售团队进行线下深度解除。

管理重心：拨打量、接通率、转化率、客户评价等。

备注：机器人电销属于电销的子分支，时间允许单独成篇与大家分享电销机器人的设计原理。

销售团队：

工作边界：基于系统数据、专业知识通过电话、拜访、邀约、现场演示等方式对线索或意向客户进行销售推进，挖掘商机，把客户从意向带到成交阶段。

管理重心：跟进量、邀约量、签单量、邀约率、签约率、回款率（坏账率）。

客服团队：

工作边界：接听客户呼入电话，受理客户诉求，视情况转给销售或售后。

管理重心：接听量、用户评价、工单量、工单闭环量。

我们可以用个例子来描述上面几个团队的协作关系。

• 市场团队类似宣传部，执行的是心理战，进行摇旗呐喊赞人气、蓄客；
• 电销团队类似轰炸机，执行的地毯式轰炸任务，为地面部队进场打扫战场；
• 销售团队类似特种兵，执行的巷战，一个敌人、一个街头、一个阵地的定制攻击；
• 运营团队类似战后管理，执行的繁荣建设，通过规则玩法将人民驯化、安居乐业、生态经济繁荣。

现实中，一般有如下几种组合：

• 小型团队：销售团队
• 中小型团队：电销团队+销售团队
• 中小型团队：市场团队+销售团队
• 中型团队：市场团队+运营团队+销售团队
• 中型团队：网销团队+电销团队+销售团队
• 中大型团队：市场团队+运营团队+网销团队+销售团队
• 大型团队：市场团队+运营团队+网销团队+电销团队+销售团队

备注：除极个别小企业外，售后团队都有，只不过某些组织的售后客服团队与电销网销或销售团队是一套人马，两块牌子而已。

针对不同的角色，不同的使用场景，CRM平台分别提供不同的工具——某些工具某些程度上可以不计入CRM，譬如我们平台的订单工具、日程工具、消息工具、数据报表工具，这些工具是在CRM项目立项前已存在的，只不过是后期CRM项目立项时，进行了系统整合。

由于CRM系统主要服务销售，我们的CRM设计重心围绕“销售管理”、“销售执行”两条线进行。基于销售转化漏斗，我们在不同的节点开发了不同的工具矩阵来服务“销售执行”、“销售管理”：

2.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端客户多联系方式产品设计逻辑、字段策略如下：

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

2.5.3 B端客户添加联系方式产品设计逻辑、字段策略如下：

2.5.4 以用户为中心的联系人穿透产品逻辑、字段策略如下：

2.5.5 以联系人为中心的列表总览产品逻辑、字段策略如下：

大家可以看出同一联系人可以重复出现，只是挂靠客户不同。

三、超大复杂组织权限的产品架构设计策略

由于我们的CRM系统是在我们SaaS平台基础上开发建设，故我们的CRM系统在权限这块基本无建设压力，下面就我们的SaaS系统的权限架构设计同大家分享一下。

在分享之前，大家先看如下几个场景，通过如下几个场景的业务需求将大家带入“高复杂权限架构设计”的解构之策、破解之道：

上面的问题看似很吓人，实则纸老虎。我们通过抽象解构、上述问题就很简单了，说明如下：

3.1 横向解构

入口层：也即页面权限，能否进入这个页面；

操作层：也即“查看权“、”操作权”；

边界层：也即可看可操作的数据边界。

3.2 纵向解构

脱敏层：某些元素对我脱敏，对他不脱敏；某些元素对他脱敏，对我不脱敏；

审批层：某些业务链路需要我审批，某些业务链路不需要我审批；

时序层：某些数据某时期能看，过了某时期（节点）我不能看了。

3.3 解决方案——引入角色概念

• 角色，控制页面入口，拥有该角色，也即拥有页面的门票进入权；
• 角色，控制职责，拥有该角色，即拥某个业务链路的审批权；
• 角色，一个人可以有拥有多个角色；
• 员工继承职位上的所有角色，职位上的角色从部门选，部门上的角色从角色池选（防止员工角色超过，通过职位、部门来调整角色的增加和减少）；
• 一个员工可以出现在多个组织中，一个员工的权限=∑组织数据边界+∑角色入口边界。

3.4 实务采坑及产品的打怪升级策略

坑1：权限体系规划中总部的职能岗未挂入虚拟公司与实务中职能岗也做单子的数据统计漏洞。

产品解决策略：将历史数据统一签入到新设立的总部虚拟公司中。

坑2：CRM模块的权限管控体系是基于我们的SaaS-ERP平台，而SaaS平台的数据边界是基于组织管理，后期公司成立事业部，出现A公司的运营部同步管理B公司的CRM，以及员工A同时管理B,C两个团队。后期权限升级为支持基于员工的跨组织数据边界复权，但当某组织下面新增子部门、子团队时，已复权的员工看不到新增子部门子团队的数据，必须手动再次赋权。

产品解决策略：创建子公司、部门、团队时自动触发复权引擎进行复权更新。

坑3：前面提到，我们的脱敏场景涉及（手机号、身份证、银行卡、余额、订单、地址、证件资料等），早期我们通过一个角色编码来控制，是否可见敏感信息，实务中不同岗位，订单不同阶段对敏感信息的控制是不同的，也即会有X(场景)*Y（角色）*Z（时间轴）种组合。

产品解决策略：我们通过扩增“脱敏角色编码”+“业务场景调用脱敏API”来快捷响应业务多变的需求。

坑4：当我们用上述方案时，随着时间推移，人员调岗等，我们不清楚权限的分布，不清楚某个角色都配给哪些人力。

产品解决策略：角色列表增加逆向查询挂靠员工、强制解除角色、恢复默认角色。

四、数据中心-CRM报表-联动作业产品架构设计策略

4.1 数据中心 VS CRM

以CRM工具为载体，将公司业绩目标自上而下分解，政策有上向下落地，数据有下向上汇总是销售管理的核心原则。一个好的CRM不光需要有业绩报表、业绩漏斗，还需要将业务体系的数据与CRM平台打通，将隔离的数据封装为生产力工具，形成业务闭环。

数据中心的建设围绕“泛运营”设计，强调规律、趋势提取及策略设计和链路优化，侧重宏观转化。

CRM的建设重心是围绕“泛销售”进行，强调逐一分层推进，侧重微观攻取。两个团队从两个方向对用户进行围剿，两个团队的协同关系可通过下图来理解：

技术建设上，如果已有数据中心，那我们的CRM系统的建设可以做的更接地气、更深入，而非像传统CRM那样只是单纯的客户基本信息、订单信息、线索质量、转化率、业绩考核，譬如我们的系统基于我们的数据中心，在CRM系统的建设山做了如下创新：

• 客户全情报信息：风险偏好、投资偏好、投资规律等客户交易行为数据、大数据征信数据等；
• 业绩设计更细腻：成单率与后期的坏账率、逾期率挂靠，为“虚假业绩”上紧箍咒；
• 人效分析更细腻：成单率与财务成本挂靠，客户的投资行为与每次交易的红包成本联动分析，透视员工开发、维系客户的成本控制能力。

4.2 CRM业绩设置系统

业绩设置的产品设计，只要从如下几个维度下手考虑，基本可以满足所有业务场景：

• 设计原则1：组织链条自上而下分解目标；
• 设计原则2：时间链条：先年再季度再月度，最小到周度的目标分解：
• 设计原则3：变更修正冗余考虑
• 设计原则4：修正审批制；
• 设计原则5：“实际-参照-完成度”对比查阅模式；
• 设计原则6：4大指标：成本-单量-规模-毛利指标；
• 设计原则7：3大参考：纵向历史参考、横向公司参考、内部同级参考；

篇幅原因：此处不展开讲解，回头针对业绩设置单独详细行文与大家分享。

4.3 CRM业绩报销系统

有了业绩设置，就需要对销售的业绩进行统计和告知，就需要对应的业绩查看模块，也即我们通常所说的销售漏斗。大家可能会有疑问，上面的业绩设置模块中虽然已有业绩查看（图4），为什么还需要业绩查看模块呢？

前者是给销售看的，这里是给销售管理看的，侧重点不一样。如下为我们的”CRM-数据中心”业务联动报表设计思想及可视化界面：

限于篇幅原因且圈里CRM分享文章对此都有详尽介绍，此处就不再多费笔墨。下面就我们的业绩报表创新中踩到的一些坑抽之一二与大家分享一下，一个优秀的产品经理应该具备哪些严格的逻辑思维？如有时间，我将单开一篇数据报表方面的总结与大家分享我们在这方面的一些设计思想及实践经验。

分享点1：漏斗转化率=A/B，当涉及客户重新分配时，逻辑设计策略分享：

场景1：销售同一个月内在不同团队之间流转，如何记录业绩？

逻辑策略：以日为单位进行CRM工作数据落库，以此来提取月度、季度、年度数据。

场景2：销售管理团队将客户甲从销售A转移给销售B时，A的客户是减少还是不减少呢？团队呢？

原则1：看转移原因，如果是跟进无效，A的客户不减；如果是非跟进无效，A的客户要减，无论如何B的客户都要增加；

原则2：如果A和B在同一个团队，团队内的客户基数不减少，否则也看原因，见原则1；

分享点2：漏斗转化率之场景深挖、业务吃透、概念萃取、知识解构的设计策略分享：

我们通过如下几组概念来再次看下产品经理在“场景深挖”、“业务吃透”、“概念萃取”、“知识解构”方面的能力要求，如果我们概念都弄不清，在数据报表设计的源头上就直接错了，后面再想改就伤筋动骨：

• 静态邀约数：统计周期内统计对象截止统计日末的邀约记录数。
• 动态邀约数：统计周期内统计对象截止今日的邀约记录数。
• 静态邀约率：统计周期内统计对象截止统计日末的邀约率。邀约率=静态邀约数/客户数。
• 动态邀约率：统计周期内统计对象截止今日的邀约率。邀约率=动态邀约数/客户数。
• 静态签约数：统计周期内统计对象截止统计日末签约记录数。
• 动态签约数：统计周期内统计对象 截止今日的签约记录数。
• 相对静态签约率：统计周期内统计对象截止统计日末相对静态签约率。签约率=静态签约数/静态邀约数。
• 相对动态签约率：统计周期内统计对象截止今日相对静态签约率。签约率=动态签约数/静态邀约数。
• 绝对静态签约率：统计周期内统计对象截止统计日末绝对静态签约率。签约率=静态签约数/客户数。
• 绝对动态签约率：统计周期内统计对象截止今日相对静态签约率。签约率=动态签约数/客户数。

有了上述概念，我们是否很容易的回答如下问题：某一统计周期内的邀约转化率如何计算？

场景1：统计周期内新增客户在统计周期内完成转化；

场景2：统计周期内累计转化量/周期内客户总量；

五、超大复杂组织业绩提成系统：产品架构设计策略

提成系统属于业绩提成模块的子场景，但如果想做好，十分考验产品经理的功底。

由于我们的业务涉及理财团队、贷款团队、外联团队、用户邀请体系等不同返佣结算场景。同时贷款和理财两个业务场景不像传统行业譬如卖车卖楼，一单一提成这么简单，而是随借款投资的期数动态联动，由此会把提成系统的问题的复杂度指数倍放大，如果产品经理不深入了解业务，业务解构能力不强、逻辑思维不扎实，就会给技术团队挖大坑。

5.1 业务场景解构

• 线上业绩实时产生、线下业绩非实时产生；
• 我们的业务是贷款、理财场景，比传统行业的提成规则复杂——每笔订单的提成不是一次性发放，而是随用户的贷款期限/理财期限，按月计提、按月发放，如果用户提前还款或提前退出理财，提成系统需要终止；
• 员工离职，原客户交给新客户经理，提成计算规则如何来？
• 某天领导一拍脑袋，提成规则要变化，系统如何灵活应对？
• 某个业务违规，原计划的提成要即刻终止，如何应对？
• 业务有4大类团队，分别是销售团队、电销团队、集团全员返佣体系、外联客户返佣体系，这4套体系的提成规则都不一样？
• 处于避税考虑，提成既有线下发放，又有线上发放，系统该如何支持（注意账务、财务体系的账务需要联动）？
• 公司层面，希望提成能在体系内循环，走线上发放如何与体系内的理财业务联动且员工不反感？
• 员工提成生效后、团队提成、公司提成都生效后，当发现某笔业务违规时，整链条的提成调整策略及产品架构解决方案是什么？

限于篇幅原因，此处不再累述，回头单独整理向大家分享。

5.2 业务需求抽象

• 普通员工（类似业务员）：只享受自己客户的提成；
• 团队负责人：享受自己直接的客户提成，以及该团队下所有【普通员工】所有客户的提成（又名为管理奖）；
• 部门负责人：享受自己直接的客户提成，以及该部门下所有【普通员工、团队负责人】所有客户的提成；
• 公司负责人：享受自己直接的客户提成，以及该公司下所有【普通员工、团队负责人、部门负责人】所有客户的提成奖；
• 外联团队自己开发的客户，返佣走“点差模式”，点差有外联经纪人自行加点，返佣分一次性返佣和动态按期资产净值返佣；
• 外联团队邀请的一度下线代理人，返佣走内部团队负责人的团提模式，团提系数单独设定，支持一人一系数；
• 平台用户邀请的一度客户，返佣走平台邀请模式：固定金额法、业绩系数法，具体规则有运营团队随市场变化设定。

相关产品设计底稿：

六、SCRM-销售单兵-移动作战平台：产品架构设计策略

基于我们的行业特点（贷款行业特有的渠道销售场景），考虑到我们的销售以外勤、串同行、线下作业为主，我们在外勤销售开发了三个小程序矩阵，分别是“移动CRM”、“喜客小站”、“喜客电子名片”。

备注：处于敏捷开发考虑，“喜客电子名片”与“喜客小站”逻辑独立，入口上暂未从喜客小站分拆独立。

“喜客小站”电子名片工具主要覆盖如下四个场景：内容、获客、数据、客户管理，解决销售朋友圈后的流量闭环和精细化经营问题。至此我们为销售提供了如下单兵套装：

• 高质量的线索：带有雷达探针的市场活动+CallCenter清洗数据；
• 全情报雷达：基于数据中心的客户全维度信息提取及用户画像；
• 转化推进器：CRM跟进管理工具，如跟进工具、提醒工具、拜访工具、知识库工具、合同工具等；
• 私域流量工具：内容生产+朋友圈安装雷达+数据魔方+CRM互通；

6.1 在系统架构设计上，我们做了如下两个策略

策略1：概念解构、链路梳理

业务梳理1：我们的业务既有理财又有贷款，既有线上理财、又有线下理财，三者之间存在交差转化场景，并且这种交差转化是通过销售撮合完成的。而我们的销售受限与公司的管理要求，必须在CRM系统上完成客户的跟进维护，业绩设置、业绩透视及提成结算，而销售自己又用自己的朋友圈做产品推广和知识普及。

我们可以从上述业务背景中提取出三组概念：用户（平台场景）、客户（业务场景）、粉丝（朋友圈场景）概念。

通过萃取这些底层概念，盘活销售私域流量的方法就非常清晰了：即我们如果想做客户，必须扩大我们的用户，扩大用户有两个方向：一是存量用户的行为识别（把朋友圈装上眼镜），而是增量用户的扩大（通过二维码来将将销售线下的推广流量转移到线上）。

策略2：SAAS架构

如果用户的登录手机号是SaaS内部在职员工，系统自动将其路由为SaaS-CRM平台的权限，产生的数据进入组织内循环，一旦离职，数据留给组织。

如果登录账号是自然人，系统自动为其开通自然人账户，如果某天该用户进入某个组织上班，而该组织恰好也用了我们的SaaS系统的CRM功能，基于时间维度，历史数据依旧归私有，新发生数据看用户走哪个路由逻辑。

策略3：工具矩阵

电子名片工具可以与CRM独立使用，也可以合并使用，数据互通依赖客户授权手机号做自动匹配，通过自带“SNS层面的数据魔方”，方便销售对私域流量进行精细化经营，并最终将客户数据及客户转化关系推进到“传统CRM”概念层级管理。

6.2 移动CRM工具

部分场景：

6.3 电子名片、内容工具、数据魔方

部分场景图：

七、SaaS平台下的CRM柔性开发、实践复盘

我们不是专业的CRM厂商，CRM系统并非我们的主业，我们的CRM平台建设是在我们的理财平台和SaaS-ERP信贷审批平台建设中因业务需要而设的一个分支。

建设之初并未将其提升到战略角度，投入重兵力建设，而是根据业务需要，以小团队、敏捷式的策略，进行分段梯度建设。

与专业CRM厂商相比，在易用性方面、在配置扩展方面又不少需要改进地方，但在业务的理解、CRM系统与ERP、OA、数据中心的深度整合上，我们有自己的系统设计和考虑，并且这些考虑和解决方案都很接地气，是CRM系统从千篇一律到专业赋能进化的一种产品致敬！

7.1 建设历程

阶段1：数据中心：用户数据、业务数据、红包数据、交易数据等业务报表等；

阶段2：贷款端CRM（贷款场景）：客户管理-跟进管理-公海-转移等；

阶段3：CRM-CallCenter：新增坐席设计、接入第三方CallCenter、来电弹屏、群呼配套工具等；

阶段4：CRM-业绩报表：业绩设置-业绩报表-提成审批等；

阶段5：理财端CRM（理财场景/B端场景）：与贷款业务场景不同，相关词典库不一致、客户用户业务打通等；

阶段6：移动端CRM：移动平台、日程管理、任务管理、消息管理等；

阶段7：销售私域流量工具：电子名片工具、数据魔方等。

7.2 复盘之缺点

• 大家都未做过CRM，除了缺经验外，我们的CRM承载的期望和支撑的业务场景缺非常庞大，整个项目全凭产品的底层硬功夫支撑，过程中产品团队吃苦很大（成长很多），当然也采了不少坑。
• 我们的CRM非一般的复杂，不少场景虽然想透了，策略也有了，但研发资源拿不出，方案被迫做缩减，产品前期做了不少妥协，有时候很无奈，时间和资源不允许，只能做方案瘦身——不过我很享受这个过程，B端业务和C端业务不一样，考虑全的瘦身和不考虑的简化完全是两个概念。
• 早期版本中未将客户状态与商机分拆，导致客户在循环业务体系下的状态处理比较被动。
• 由于缺乏经验，未能在一开始在产品架构层面规划客户场景以及与之相配套的“状态词典库”、“产品词典库”、“来源词典库”、“等级词典库”等相关词典的自动化配置。

7.3 复盘之优点

• 相比市面上可花钱购买的CRM，我们的CRM除了在交互上弱以外，实用性和业务支持能力更强。
• 相比市面上可花钱购买的CRM，公司的数据更安全。
• 敏捷开发，效率高，成本低，由于我们底层搭的好，很多模块是可以服用的，如：权限模块、订单模块、回款模块、任务管理模块、消息通知模块等。
• 能够快速满足业务需求、每个版本大概投入3人（PM-后端-测试），2周开发、1周测试，6、7期时投入前端开发工程师。
• 副产物复用，如：日程管理、绩效考核表、成本分析表、私域流量工具（可脱离SaaS账户体系独立使用）、列表定制、搜素定制等新交互引入。
• 人才锻炼和知识沉淀及技能提升——可能我们的交互很low，但我们的产品业务逻辑梳理、深层问题剖析、概念解构萃取、逻辑策略设计、产品架构处理、敏捷迭代打法等一系列想法和知识体系得到实践的正向检验和有效提升。

最后向大家分享一下我们平台的CRM全系知识图谱，图片太大，只能单独下载。

链接:https://pan.baidu.com/s/1GC27ZJNVZxEuNnZau2Hcqw 密码:xvv8

 

作者：九天牧人，个人微信unifarm

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

题图来自 Unsplash，基于 CC0 协议