CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇)

摘要

昨天我们给大家分享了,CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(上篇)今天接着给大家分享下篇,请大家那好笔记。我们要开始啦!!!

昨天我们给大家分享了,CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(上篇)

今天接着给大家分享下篇,请大家那好笔记。我们要开始啦!!!

 

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

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

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

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第1张

 

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第3张

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第5张

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第7张

 

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

 

  3.1 横向解构

  入口层:也即页面权限,能否进入这个页面;

  操作层:也即“查看权“、”操作权”;

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

 

  3.2 纵向解构

  脱敏层:某些元素对我脱敏,对他不脱敏;某些元素对他脱敏,对我不脱敏;

  审批层:某些业务链路需要我审批,某些业务链路不需要我审批;

  时序层:某些数据某时期能看,过了某时期(节点)我不能看了。

 

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

  角色,控制页面入口,拥有该角色,也即拥有页面的门票进入权;

  角色,控制职责,拥有该角色,即拥某个业务链路的审批权;

  角色,一个人可以有拥有多个角色;

 

  员工继承职位上的所有角色,职位上的角色从部门选,部门上的角色从角色池选(防止员工角色超过,通过职位、部门来调整角色的增加和减少);

 

  一个员工可以出现在多个组织中,一个员工的权限=∑组织数据边界+∑角色入口边界。

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第9张

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第11张

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

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

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

 

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

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

 

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

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

 

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第13张

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

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

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

 

  4.1 数据中心 VS CRM

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

 

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第15张

 

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

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

 

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第17张

 

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

 

  客户全情报信息:风险偏好、投资偏好、投资规律等客户交易行为数据、大数据征信数据等;

  业绩设计更细腻:成单率与后期的坏账率、逾期率挂靠,为“虚假业绩”上紧箍咒;

  人效分析更细腻:成单率与财务成本挂靠,客户的投资行为与每次交易的红包成本联动分析,透视员工开发、维系客户的成本控制能力。

 

  4.2 CRM业绩设置系统

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

  设计原则1:组织链条自上而下分解目标;

  设计原则2:时间链条:先年再季度再月度,最小到周度的目标分解:

  设计原则3:变更修正冗余考虑

  设计原则4:修正审批制;

  设计原则5:“实际-参照-完成度”对比查阅模式;

  设计原则6:4大指标:成本-单量-规模-毛利指标;

  设计原则7:3大参考:纵向历史参考、横向公司参考、内部同级参考;

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

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第19张

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第21张

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第23张

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第25张

  4.3 CRM业绩报销系统

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

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

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第27张 CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第28张

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第31张

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第33张

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

 

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

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

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

 

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

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

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

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

 

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

 

  静态邀约数:统计周期内统计对象截止统计日末的邀约记录数。

  动态邀约数:统计周期内统计对象截止今日的邀约记录数。

  静态邀约率:统计周期内统计对象截止统计日末的邀约率。邀约率=静态邀约数/客户数。

  动态邀约率:统计周期内统计对象截止今日的邀约率。邀约率=动态邀约数/客户数。

  静态签约数:统计周期内统计对象截止统计日末签约记录数。

  动态签约数:统计周期内统计对象 截止今日的签约记录数。

  相对静态签约率:统计周期内统计对象截止统计日末相对静态签约率。签约率=静态签约数/静态邀约数。

  相对动态签约率:统计周期内统计对象截止今日相对静态签约率。签约率=动态签约数/静态邀约数。

  绝对静态签约率:统计周期内统计对象截止统计日末绝对静态签约率。签约率=静态签约数/客户数。

  绝对动态签约率:统计周期内统计对象截止今日相对静态签约率。签约率=动态签约数/客户数。

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

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

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

 

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第35张

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第37张

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第39张

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

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

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

 

  5.1 业务场景解构

  线上业绩实时产生、线下业绩非实时产生;

  我们的业务是贷款、理财场景,比传统行业的提成规则复杂——每笔订单的提成不是一次性发放,而是随用户的贷款期限/理财期限,按月计提、按月发放,如果用户提前还款或提前退出理财,提成系统需要终止;

 

  员工离职,原客户交给新客户经理,提成计算规则如何来?

  某天领导一拍脑袋,提成规则要变化,系统如何灵活应对?

  某个业务违规,原计划的提成要即刻终止,如何应对?

 

  业务有4大类团队,分别是销售团队、电销团队、集团全员返佣体系、外联客户返佣体系,这4套体系的提成规则都不一样?

 

  处于避税考虑,提成既有线下发放,又有线上发放,系统该如何支持(注意账务、财务体系的账务需要联动)?

 

  公司层面,希望提成能在体系内循环,走线上发放如何与体系内的理财业务联动且员工不反感?

  员工提成生效后、团队提成、公司提成都生效后,当发现某笔业务违规时,整链条的提成调整策略及产品架构解决方案是什么?

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

 

  5.2 业务需求抽象

  普通员工(类似业务员):只享受自己客户的提成;

  团队负责人:享受自己直接的客户提成,以及该团队下所有【普通员工】所有客户的提成(又名为管理奖);

  部门负责人:享受自己直接的客户提成,以及该部门下所有【普通员工、团队负责人】所有客户的提成;

  公司负责人:享受自己直接的客户提成,以及该公司下所有【普通员工、团队负责人、部门负责人】所有客户的提成奖;

  外联团队自己开发的客户,返佣走“点差模式”,点差有外联经纪人自行加点,返佣分一次性返佣和动态按期资产净值返佣;

  外联团队邀请的一度下线代理人,返佣走内部团队负责人的团提模式,团提系数单独设定,支持一人一系数;

  平台用户邀请的一度客户,返佣走平台邀请模式:固定金额法、业绩系数法,具体规则有运营团队随市场变化设定。

 

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第41张

 

相关产品设计底稿:

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第43张

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第45张

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第47张

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第49张

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第51张

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

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

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

 

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

  高质量的线索:带有雷达探针的市场活动+CallCenter清洗数据;

  全情报雷达:基于数据中心的客户全维度信息提取及用户画像;

  转化推进器:CRM跟进管理工具,如跟进工具、提醒工具、拜访工具、知识库工具、合同工具等;

  私域流量工具:内容生产+朋友圈安装雷达+数据魔方+CRM互通;

 

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第53张

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

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

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

 

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

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

 

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第55张

  策略2:SAAS架构

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

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

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第57张

 

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第59张

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第61张

  策略3:工具矩阵

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

 

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第63张

  6.2 移动CRM工具

 

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第65张

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

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第67张

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第69张

  七、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端业务不一样,考虑全的瘦身和不考虑的简化完全是两个概念。

  早期版本中未将客户状态与商机分拆,导致客户在循环业务体系下的状态处理比较被动。

  由于缺乏经验,未能在一开始在产品架构层面规划客户场景以及与之相配套的“状态词典库”、“产品词典库”、“来源词典库”、“等级词典库”等相关词典的自动化配置。

CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享(下篇) 第71张

 

  7.3 复盘之优点

  相比市面上可花钱购买的CRM,我们的CRM除了在交互上弱以外,实用性和业务支持能力更强。

  相比市面上可花钱购买的CRM,公司的数据更安全。

  敏捷开发,效率高,成本低,由于我们底层搭的好,很多模块是可以服用的,如:权限模块、订单模块、回款模块、任务管理模块、消息通知模块等。

  能够快速满足业务需求、每个版本大概投入3人(PM-后端-测试),2周开发、1周测试,6、7期时投入前端开发工程师。

  副产物复用,如:日程管理、绩效考核表、成本分析表、私域流量工具(可脱离SaaS账户体系独立使用)、列表定制、搜素定制等新交互引入。

  人才锻炼和知识沉淀及技能提升——可能我们的交互很low,但我们的产品业务逻辑梳理、深层问题剖析、概念解构萃取、逻辑策略设计、产品架构处理、敏捷迭代打法等一系列想法和知识体系得到实践的正向检验和有效提升。

 

最后:内容到这里接结束了,如果大家喜欢欢迎大家分享一下或者点个赞哦!到是打赏一下就更好啦  哈哈