如何从0-1打造完好的CRM产品

将来商业都是要围绕着人展开的，广义的讲所有业务的产品都可以纳入CRM，CRM将是各大平台或商家适应将来商业环境的根底标配。

什么是CRM


CRM管理又称客户关系管理，我们用对象思维解释一下：实体是公司或企业，对象是客户，手腕是结果管理和过程管理，目的是转化，结合管理的定义（规范化和流程化）整合成一句话就是对客户全生命周期管理笼统特点，以赋能管理手腕扩大管理才干边境和进步管理效能。

当前业内CRM分个方向：

第一是O2O销售管理内，一般内部使用偏管理；第二是如电商后台客户资源管理类，会有客户管理，会员系统，自动化营销系统等，偏分析和运营类。

将来商业都是要围绕着人展开的，广义的讲所有业务的产品都可以纳入CRM，CRM将是各大平台或商家适应将来商业环境的根底标配。

虽然市场的消费水平不时提升，各种触达渠道数不胜数，但是没有对客户精细化的运营，只是不时的讲产品，效劳推送给用户的转化是极其惨淡的。

对产品和用户的精耕细作尤为重要，单纯采用流量破绽的流量思维在当下也显得有些不够用，需要更灵敏的标签系统，会员系统，超级会员等不时完善用户画像，通过用户阅读行为数据，购置数据，收藏加车的行为停止汇总，沉淀数据池。

不同纬度的数据聚集成数据集市，用地域值，时间值和模型值将数据池中的数据抽离出来赋能给应用停止高效的转化。

那么CRM的作用在哪？数据采集方式，数据格式化，对用户和产品效劳分析后输出模型值赋能给各个应用，提升转化效率的作用。

CRM属于前台还是后台


首先CRM产品一定属于业务线产品，不能单纯的用前台，中台和后台的系统架构思路停止区隔，因为一个优秀的CRM产品都是业务型产品，通过业务架构思维指导产品设计，所以对产品的展示形态没有前台那么高的要求；（但还是要比后台要求高）

CRM又不像CMS，ERP，MQ，AMS，FIS，甚至更底层的如订单履约系统等完全属于后台产品架构，不难区分的就是这类系统无论在哪构造都高度类似，会根据公司业务和战略调整但是底层模型不会有大的变化。

所以明白了吗，CRM需要你懂一些前台设计和页面交互逻辑，懂后台架构和系统交互逻辑，一切为了满足业务需求，为什么？看后面实战激动了。

不啰嗦了，进入实战

项目目的


项目目的从0-1搭建带有社群管理的CRM系统。

项目重点

没有对产品全貌想清楚，不要动手开端画原型，因为CRM重点在管理，所以各个系统模块之间的交互会比普通产品复杂的多，先想清楚你要管理什么？想清楚你要管理什么（如客户还是销售）；第二步就是你的管理手腕和抓手在哪里（是系统自动化判断还是运营支撑）；你最后要到达什么效果，也就是目的是什么（重点关注数据层能否满足）；管理方案（产品方案）。

总结：一切围绕着业务管理，针对你的目的想管理手腕，最后想清楚产品方案，看到没有，这时候都没有去想原型有什么，因为还不到时候，此时你最重要的是想清楚产品构造和数据层的设计。

本次项目系统模块：消息中心，社群管理，客户管理，海域管理，客户跟进。（下一篇会讲管理思路和实战设计内容）

产品构造之概念模型


使用工具：UML。

（内容停止小部分脱敏）

概念模型的核心思路是在确认产品架构（架构图）后，梳理各模块之间的关联关系，系统交互方式和数据构造层的作用。

梳理概念模型的时，首先确认我们有哪个系统模块，确认每个模块的拆分合并的意义，每个模块内的数据字段的含义是什么？为什么要有这个字段用来干什么？然后看整个流程是否已经可以跑通，不存在数据断层和数据冗余的问题即可。

最后就是开端删改，为什么？

因为概念模型会让你想的大而全，是否有没必要的模块和流程的其中，流程能否停止优化，简化流程。

发现没有？没出原型的时候你已经可以考虑优化方案，流程优化的东西了，当你自己在这个阶段都优化完，考虑全了，后续产出的东西你还怕被喷被返工吗？ 不存在的。

概念模型梳理完成后开端进入USERCASE阶段。

产品数据权限之USERCASE


画USERCASE原因是CRM会为多种角色使用的场景（权限系统参考RBAC模型），所以各角色的数据权限需要考虑到位，比如BD能看到什么能用什么功能，BDM／CM能看到什么能用什么功能，甚至财务人员，运营人员等等都需要提早考虑到位。

为了能明晰的表达这之间的管理使用USERCASE最为方便。

USERCASE的核心作用帮你梳理业务边境，在这个阶段每个功能给谁用不给谁用，每个数据给谁展示，展示多少有控制，不给谁展示，为什么不展示等都要去考虑到位，并且给自己一个说的过去的业务理由。

产品使用之业务流程图


CRM这类产品一定要画业务流程图！！！功能流程图可以不画，画了也是放在详细介绍中。

业务流程图使用泳道图来画，因为涉及到多角色多节点多状态（除了泳道图你能用别的办法画清楚请教我）。

泳道图顾名思义形状像一条条泳道一样的流程图，一般我顶部标头用角色或前后台区分，左部标头用功能或者状态区分，见图：

这是一张涉及多角色管理，但是流程比较简单的优惠卷发放业务流程图，目的主要就是为了停止资产单品管理（优惠卷也是资产）。

产品视觉之原型图


这个阶段可以开端动手画原型图了，看着你的概念模型，USERCASE和流程图，假设能把原型图画错那是我输了。

产品描绘之功能清单


我们输出PRD（需求文档）前的一步是输出FRD，就是上面几个模块加上功能清单就是一份完好的FRD。

功能清单主要写功能模块，功能名称，功能描绘，优先级（P0,P1）和PD，只要描绘清楚你要做一个什么样的功能，非常详细的内容建议放在需求描绘中去写，当然某个功能是特别需要主要的，或者这个项目特别的玩法数据权限内容可以详细描绘在功能清单（方案闪光点）。

因为可以勾引开发哟，让开发很兴奋和期待下一段的项目降临（这对你的项目能否圆满完成有重要意义）。

产品立项之KICK OFF


手里有完好的FRD文档，这时候可以拿着你的FRD去找开发和leader去评估，因为你要做什么思路和样子已经很清楚了。

主要告诉开发FRD里的相关内容，开发评估能否实现（一般没问题，但还是怕有人脑洞大开），最重要的是确认评审时间（看你写详细需求需要多久和开发被释放时间）和开发人员配置，这就是项目kick off阶段。

kick off后建一个项目群（一般钉钉）把相关开发来进来，写邮件确认下次评审时间，同步FRD文档，开端正式写需求文档，到确认的时间点正常评审即可。

为什么kick off阶段就要建群？

因为项目有很多不可控因素，假设你的主开发因为其它项目被耽搁无法抽身需要提早告知你，你才干提早和项目经理报备想处置办法（拉他人或者延后），群就是一个高效的信息同步渠道，同时也让所有参与者都明确自己下一段时间要干什么，日常工作中能根据自己当前的情况即便反响。

产品文档之需求文档


这其实没什么说的，FRD+详细描绘就是需求文档。每个人有自己的描绘方式，只要表达清楚即可。

总结


本文完全实战内容，适用各个大厂（当然大厂有产品内部评审甚至更多流程），但是一个产品的个人修养部分也是较为全面，希望同僚共同进步，如有表达，理解错误请及时指正。

作者：凤梨，CRM产品经理，CRM产品规划及设计，完成产品实现。

本文由 @凤梨 原创发布于人人都是产品经理。未经容许，制止借鉴

题图来自Unsplash，基于CC0协议

转发了

转发了

打造CRM产品

转发了

转发了

转发了

转发了

转发了

mark