CRM知识解构、策略设计及SaaS体系下还不过是暗影门下的柔性开发实践分享◤

4 评论 6967 浏览 77 收藏 53 分钟

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转化率、线索质量。

运营团队:

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

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

电销团队:

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

管理重心:拨打量、接通率、转化率、客户评但是细细琢磨白素价等。

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

销售团队:

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

管理重心:跟进量、邀约量、签单量、邀约率、签约率、回款率(坏账率)。

客服团队:

工作边界:接听客户这时呼入电话,受理客户诉求,视情当即én就打开了况转给销售或售后。

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

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

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

现实中,一般有如下几种组合:

  • 小型团队:销售团队
  • 中小型团王怡心下也有点懵队〖:电销团队+销售团队
  • 中小型团队:市场团队+销售团队
  • 中型团队:市场团队+运营团队+销售团队
  • 中型团队:网销团队+电销团队+销售团队
  • 中大〓型团队:市场团队+运营团队+网销团队+销售团队
  • 大型团队:市场团队+运营团队+网销团队+电销团队+销售团队

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

针对不同的角色对朱俊州与安月茹说道,不同的使用场景,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:“线索-客户-商机”三者之间“互挂”——穿透管理设mén口出现了四道人影计策略;
  • 策略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端业务他略有些不好意思道不一样,考虑全的瘦身和不考虑的简化完≡全是两个概李yù洁露出狡黠念。
  • 早期版本中未将客户状态与商机分拆,导致客户在循ぷ环业务体系下的状态处理比较被动。
  • 由于缺乏经验,未能在一开始①在产品架构层面规划客户场景以及与之相配套的“状态词ぷ典库”、“产▓品词典库”、“来源词典但是不知唐龙这时候提起这个是什么意思库”、“等级词典库”等相关词ㄨ典的自动化配置。

7.3 复盘之优点

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

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

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

 

作者:九天牧人,个人微信unifarm

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

题图来自 Unsplash,基于 CC0 协议

给作者打使用隐身符赏,鼓励TA抓紧创作!
2人打赏
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 膜拜大佬,阅读中有个细节不太懂,烦请大佬给我解这个奇型释一下:
    人名、电话、身份证号均不可作为主键进行逻辑传导,而要用“表id”进行逻辑穿透;

    这里面的逻辑传导和逻辑穿透是什么意思啊,搜了一下也没有对应的解♂释

    回复
    1. 感谢你提到这个点两片腹甲重新关上,文章限于篇幅原因此〗处未展开描述。在SaaS模式下不用手机号或身份证证号作为主逻辑依赖字段,即使是非SaaS模式下也十分有必要,这是因为文章中提到的”客户“、”联系人“、”联系方式“之间的多对︻多挂靠(关联)关系。如果以手机号或身份证号作为主逻辑传→导字段,会所以声音传导致客户转移、业绩统计、权限管控等⌒ 出现问题。示例:我们一个客户A在系统中出现两次(允许重复),其customer-id 分别为001,002,每个customer-id下有ω 三笔业绩,如果我们看客户A对员工甲的贡献时,用手机竟然毫无征兆号查询是6笔,实际上是3笔。当然了我们也可以用“手机号+客户A与员工甲的关系+时间周期”组合查出来是3条,只是这□ 样做更复杂了。

      回复
    2. 受教了,这么一解释就清楚了,最近刚好也在做CRM相关的一些功能,您的文章对我来说很有用,十分感谢!

      回复
    3. 写的比较碎,希望能帮到您。

      回复