hackmap（谈谈我的CRM产品方法论）

运营人员的数量和工作时间往往非对应的产品经理能决定，因此CRM系统层面，产品负责人能有效提升的因素是人效。而提升人效最重要的产品方法是将业务行为数据化，再通过数据帮助运营决策。

二、定位

从业务运营的角度如何看待CRM系统？

传统的观点认为CRM就是运营人员进行业务操作和分析业务数据的系统，面向当前数字化管理、精细化运营的经营理念，以及获客成本逐渐提升的市场现状，CRM系统不单是操作和分析数据的平台，也是业务战略落地的核心要素。

此外，任何系统都是为人服务。对于业务人员的激励也是实现目标的重要一环，因此，CRM系统的定位可以归类如下：

基于上述定位，产品落地的Road Map如下：

三、落地

CRM系统的落地基于业务行为的数据化，整体流程可参考下图：

首先要说明的是，整个系统的起点和终点都来自系统外部的人。虽然产品自动化的程度日渐提升，但仍需人的参与提供基础数据，并通过系统的反馈优化决策者的想法，进而产生业务价值。

达成营收目标的前提，是运营决策者的战略思考。当CRM系统在公司业务模式里占据不可或缺的位置时，系统的价值才能更好的实现。

因此产品经理需要深入思考当前的业务模式存在哪些问题？其中哪些是收入增长的瓶颈？是否能在系统层面让瓶颈得到改善？甚至不通过系统也能改善？

产品经理需要针对此类业务问题和运营决策者达成高度共识，同时基于组织内外的资源现状梳理出可行的落地策略，Road Map的推进节奏，才能尽可能保证在后续的工作推进和迭代过程中得到各方足够的信任和支持。

策略的执行环节，可以理解为将产品方案落实在CRM系统，并推进运营方使用的过程。如果此前已有承担相应功能的系统，则需考虑新旧系统（或功能）的迁移策略。该过程至少要解决如下核心问题：

如果是从0开始搭建新系统，在各方达成共识的基础上相对而言会更好推进，同时也对产品经理的架构策划能力有更高的要求。关于搭建灵活可扩展的产品架构问题，可参考文末章节。

运营者使用CRM系统期间可能访问多个功能模块，操作者需要不停的决策并记住下一步的目标，注意力很容易失焦。

为了提升人效，让运营者聚焦业务本身而非系统操作，可以将核心业务流程抽象成“任务”，并将统一的操作入口固定为“任务列表”，将高频操作环节集合到“任务”中，在其中提供运营所需的用户信息，将原本需要在多个模块进行的分析、触达、记录等环节合并至一个“任务”中，提升人效。

每个使用者对用户的触达记录，均可作为数据源生成整个CRM系统的统计数据，结合触达后用户的行为数据变化，可以在一定程度上反映使用者的工作成效供运营决策者进行分析，进而判断当前的业务现状，帮助决策者和团队迭代战略构想。至此便形成一个基础的业务数据闭环。

细节层面，CRM系统的高频操作流程可以抽象为图中3个核心节点：

下面将根据这3个节点分别阐述对应经验。

1. 搜索用户

高频操作的第一步即查找用户。解决该问题最简单的方法是提供多维度的搜索、筛选条件。操作者通过各种搜索&筛选条件的组合寻找目标用户。这种方式类似在京东、淘宝购物，显然是低效的解决方案。

这种低效源自业务发展过程中熵增的复杂筛选项，以及重复的搜索行为。更好的解决方式是在系统层面把复杂的筛选项抽象成业务逻辑，让使用者无需搜索即可找到目标用户。基于该逻辑，可以将“搜索用户”转变为“分配用户”。

如图，操作者的行为从左侧转变为右侧循环。这样一个看似简单的变化对于提升人效而言却是本质性的改进：

关于分配逻辑，根据业务模式的不同可分为“固定业务逻辑”、“自动召回逻辑”两类。

固定业务逻辑即根据指定的分配逻辑将用户分配给不同的运营方。比如具有地域性销售&分润特征的业务，一旦涉及到渠道业绩的结算，销售线索的分配和策略调整即牵一发而动全身，甚至需要重新签订合同。

一种接受度比较高的解决方式是通过唯一的渠道链接，追踪渠道带来的线索或付费用户。

此外也可通过搭建“全局线索池”，根据不同用户的地域、行业等属性特征，分配至对应渠道的“本地线索池”。根据直营、分销、特许经营等业务模式，固定业务逻辑的分配策略不尽相同，这里不作深入讨论。

自动召回逻辑即结合用户的属性、特征，以及运营人员的属性、特征对样本数据进行召回，并将运营人员和用户进行匹配，在CRM系统中生成“任务”。

该模式解决的问题是帮助运营层管理者减少为执行人员定期重复分配任务的次数。这种自动化分配规则的核心包括：召回策略、匹配策略、频率、有效期4个方面，即：

具体的规则逻辑，需要根据自身业务和用户的特征进行数据分析及决策进行迭代，不做赘述。

基于分配逻辑，还可以为每次分配设置跟进“优先级”。即根据任务列表中用户的行为数据，将具备更高跟进价值的用户置顶或加入明显的标识，帮助操作者优先跟进更容易产生业绩的用户，降低决策成本。

2. 分析用户

越优质的用户越需要长时间的分析。

这个过程类似医生对病人的诊断。过去的中医通过“望闻问切”给病人看病，对医生的要求较高，其次对医生的时间利用效率低，且由于主观因素影响过大，不同医生对同一症状的判断也不容易达成一致。

现代医学把诊断和治病分开，把诊断通过机器（CT、B超、X光等）和护士完成，结果非常精确。让医生的时间聚焦在根据诊断数据治病。对于简单的诊断结果，比如日常的发烧感冒，甚至普通人就能自行处理。

借鉴现代医学的诊断思路，在客户分析层面，产品经理可以根据帕累托定律（二八法则）将已经验证的有效分析过程产品化，提升运营人效。

用户分析产品化的第一步，是将复杂的用户属性和行为数据通过图、表的形式进行标准化展示，实现信息的可视化。通过基本的培训，运营者即可通过标准的分析方法解决常见问题，提升任务处理效率。

基于可视化的用户数据，系统可以将已验证的有效分析方法模块化，如“流失用户分析”、“付费用户分析”、“用户行为分析”，帮助运营者定位当前用户存在的问题。

此外，对于常见问题，系统还可提供相应的指导建议，如针对即将流失的用户，可根据此前用户的活跃状态建议运营采用不同的触达策略；针对新用户，可根据用户的注册渠道、注册后的行为建议运营在触达时采用不同的话术；针对活跃用户，可根据用户的活跃行为建议运营适时进行付费转化。

精准定位用户是一个非常复杂的分析过程。大部分筛选条件都是基于静态的用户数据形成，比如用户的消费金额、频率等。而业务场景中对用户的理解和分析却是动态的，产品经理几乎不可能根据过去的数据变化趋势将所有时间维度的特征整合至筛选项。

即使简单粗暴的将所有筛选条件加入系统，其内在逻辑对操作者而言也很难理解，用户体验很差。

因此对于需要通过复杂筛选项组合分析的业务场景，可以将已经验证有效的分析过程抽象成一个整体的召回细则作为一个选项供使用者筛选。

简单讲就是通过与业务团队深入沟通，把业务的分析逻辑梳理成产品方案，整合成一个筛选项，操作者只需通过点击选项即可完成整个分析过程得到可视化结果。

该逻辑的典型应用就是“用户分群”，即基于某些维度，把目标人群区分为不同的群体。既可以按性别、年龄、地域的人口属性划分，也可以根据数据分析的结论区分，比如待激活用户、活跃用户、流失用户等维度。

不同行业也可以根据业务属性划分，比如教育行业可分为体验用户群、购买用户群、复购用户群，企业服务领域可根据客户的购买阶段分为陌生客户、意向客户、潜在客户、签约客户等等。

这里需要注意的是，每种分群逻辑之间必须互斥。如果一个用户被划入“活跃用户群”，则用户在同一时间周期内不可被划入“流失用户群”或其它用户群。

除了系统层面的用户分群，CRM系统也可以帮助每个运营者自定义“用户标签”。与用户分群不同，标签是运营者基于自己对用户的主观理解以及业务需要，人为标记的特征标识。

标签之间并不互斥，同一用户也可以被标记多个标签。运营者在工作中标记的越精准，对效率的提升也就越高。产品经理也可以在调研中根据运营者添加的标签特征进行分析，完善用户画像，或者将适合用于分群的特征抽象为分析选项。

业务层面，管理层对运营人员的行为分析对目标的达成也至关重要。基于产品的数字化闭环，针对运营人员的数据分析一般集中在任务的执行和记录以及符合绩效标准的用户数提升。

任务的执行记录，可根据操作者的处理时长、记录完整度、使用频率等数据维度在一定程度上衡量人效。更重要的是运营触达用户后，用户行为数据或付费转化数据的提升。

产品经理可以根据业务实际情况，将此类数据整合成可视化的图表供运营层管理者评估团队整体及个体的工作现状。

3. 触达用户

站在用户视角，平台的触达可分为用户主动发起和被动接受两种。用户被动的接到营销电话或微信好友申请体验相对较差，除非命中有切实需求的用户，否则转化率极低。

对于用户主动发起的互动，可分为两类：

一种是使用或体验产品的过程中遇到问题，需要向平台咨询。该场景可通过智能Q&A将常见问题整理成结构化的客服消息自动回复给用户，类似在淘宝购物时自动弹出的尺码、发货咨询消息。此外也可通过交互式语音问答（IVR）帮助用户解决典型问题，类似中国移动的客服电话。

另一种主动发起的互动，在当前的教育、消费领域较为常见，也是近年十分火热的私域流量运营模式。平台一般会通过提供专属的服务或优惠政策，引导用户添加服务人员微信。建立好友关系后，再通过社群、朋友圈、线上活动等运营形式提升用户活跃度，进而促成付费转化。

提到私域流量运营，这部分产品迭代其实属于CRM的范畴，但由于微信的接口限制，除非在操作系统层面Hack微信客户端（该操作存在较高的封禁风险）否则无法与内部系统打通。

直至去年企业微信3.0版本陆续开放客户联系、客户朋友圈等相关API后，将企业微信与内部系统打通几乎成了私域流量运营的标准配置。自此企业微信便可作为CRM的移动端工作站，帮助企业沉淀用户关系。

关于企业微信和私域流量运营，是另一个大话题，这里不做更多讨论。

综合来看，关于触达用户，用户主动发起的互动对沉淀用户关系具备更高的价值，在CRM系统日渐完善的基础上，如何让目标用户主动与产品产生连接以及后续一系列的价值交换行为，是值得产品经理用更多心力思考的问题。

四、激励

在哈维茨（Hurwiez）创立的机制设计理论中，激励相容是指：在市场经济中，每个理性经济人都会有自利的一面，其个人行为会按自利的规则行为行动。如果能有一种制度安排，使行为人追求个人利益的行为，正好与企业实现集体价值最大化的目标相吻合，这一制度安排，就是激励相容。

对员工的正向激励可以提升产出，这是个不言自明的道理。

如何在CRM系统中让使用者获得成就感、价值感也是值得产品经理思考的问题。相比核心的业务操作及分析，与员工激励相关的功能往往排在靠后的优先级，但这并不影响产品经理去思考及规划。近两年的产品实践中，以下几点在激励角度具备一定的参考价值。

1. 实时业绩

业务产出的结果对员工的重要性不言而喻。如果能在系统中实时展示使用者的工作成效，对士气的提升具有重要意义。

不论业务目标是收入增长还是用户行为数据增长，在运营人员的个人中心或更明显的Dashboard上展示前，产品经理都需要跟运营决策者明确要展现的数字及计算逻辑是否符合业务层面的激励原则，以及具体的更新频率、有效时段、结算逻辑。

与此同时，还需考虑研发层面对业务数据的结算能做到多久的实时性，中间要经过哪些数据流转节点以保证最终展现的数据与实际结算一致。综合考虑业务及研发团队的现状，方可产出卓有成效的激励方案。

2. 公告板

产品层面，公告板是一个逻辑极其简单的功能，只需一个明显的展示入口和一个内容编辑模块即可完成整个流程。

业务层面，公告板起到了重要的信息同步作用。平台鼓励什么、反对什么，业务层面的最新进展以及政策变动等重要信息，均可通过公告板实时发布。

与业务团队合作的产品经理，应当积极的了解业务动态，深入业务的各个环节去理解每个业务诉求。好的解决方案不一定非要做的多么复杂以体现产品逻辑的缜密，而是要极尽简洁。用程序的语言表达，则是要考量需求是做成一个“类”还是“实例”。

拿公告板举例，业务的诉求可能是做一个业绩公告或是排期同步的功能。产品经理应该注意到这是业务人员从“实例”层面提出的解决方案，背后真实的需求是解决多人协作时的信息同步。

此时需要尽可能从“类”的层面抽象出一个可满足所有此类场景的产品方案，而不是简单跟随业务的想法机械的落地方案。

分配权重

对于应用“自动召回逻辑”分配任务的CRM系统，如果业务层面对使用者有相应的激励政策，则可在运营人员的召回逻辑，以及对召回用户和运营人员进行匹配的逻辑中根据激励政策加入相应业务逻辑。

比如对于业绩超过均线的运营人员分配更高比例的优质用户，对业绩水平较差的运营人员分配更简单的任务。通过对分配权重的调整，能够让运营人员更明显的感知到自身行为产生的结果，帮助整体业务更好地进行优胜劣汰。

五、架构

如果把做产品类比为在虚拟的比特世界中盖一座大厦，架构则是动工之前必备的图纸。对于系统的非功能性特征，如扩展性、复用性、QPS、TPS等，一般由研发团队进行设计和迭代。

产品经理在其中的角色更多是结合当前团队现状以及业务未来的发展预期综合考量，提出在业务发展各个阶段中都能具备统一规范且足够灵活，可扩展、可复用的产品方案。

做产品是个熵增的过程。随着用户规模、业务规模的扩张，必然引入一系列新场景、新需求，产品复杂度也随之提升。

从这个角度，架构其实就是基于业务结构定规则做限制。正因如此，架构没有对错之分，也没有一套架构能适用所有业务场景，产品经理只能在迭代中不断打磨提升。

首先，架构最重要的就是贴合业务。

这是一个从整体到部分的过程。只有明确公司对用户提供的服务是什么，业务如何开展并规模化，定下最上层的战略之后，产品的边界才得以划分，这个基本上一旦确定就很难更改。

接着就是基于整体规划，给每个部分划分解决方案，定义其核心功能以及各部分之间的关联关系，形成最终的产品结构图，并随着业务的发展同步迭代。

系统落地层面，产品经理首先要基于组织架构定义合理的权限管理机制。最简单粗暴的方法，是直接将读写权限授权给用户。这里引入的问题是所有用户的权限变更均需管理员手动变更，且不支持多层级的权限管理。

因此在系统实践中，引入了“角色”概念，即在用户集合与权限集合之间建立一个角色集合，每一种角色对应一组相应的权限。一旦用户被分配了适当的角色后，该用户就拥有此角色的所有操作权限，这就是权限控制理论中经典的基于角色的访问控制（RBAC）。

在更复杂的使用场景中，如果把角色视为用户的一种属性，就可以添加更多的用户属性，通过对属性的策略调整控制用户的权限，即基于属性的访问控制（ABAC）。

以上的权限管理方法，几乎可以满足目前所有公司对于权限管控的基本需求。感兴趣的朋友可以另行深入研究。

确定权限管理机制后，产品经理需要对权限所控制的每个业务模块进行抽象归类，将业务场景高度重合的功能模块化，集合在统一入口，在产品层面实现功能的高度聚合，尽可能降低模块之间的复杂关联，用程序的语言描述即——高内聚低耦合。

这个过程也可以称之为组件化，本文仅阐述了CRM系统中最核心的流程，在实际业务中，系统还可能包括营销管理、订单管理、流程管理、知识库等众多子系统，一个功能点的改动可能牵涉多个子系统的修改，不利于产品快速交付。

因此产品经理需要尽可能将长期稳定使用的功能切分成子系统，在子系统内按功能点再进行切分。

比如对于具备优惠券、折扣减免等营销功能的CRM系统，就可以将优惠折扣的属性配置集中在营销管理这一子系统中，把具体的发放流程添加至上文描述的“任务”中，运营者只需在任务中完成优惠发放，无需在营销管理中进行复杂设置，后续关于营销工具的迭代也更利于研发快速交付。

组件化带来的另一个问题是定制化，即为不同的人提供不同的产品。

如果能为每个使用系统的用户提供定制化的产品必然能提高人效，然而在成本层面考虑并不现实，因此可以考虑通过配置化的方式，让用户可以通过配置来选择符合个性化需求的插件解决问题。

配置化是CMS（内容管理系统）的核心思想。具备配置化功能的系统，新功能的上线及老功能的更新不需额外开发工作，客户端发版后，系统管理员仅需简单的配置即可实现。CRM系统也可以借鉴这种思路，将主体结构和功能细节变动相对不频繁的产品模块迭代成可灵活配置的组件供用户使用。

以上，即是近两年产品工作中关于CRM产品方法论的系统总结。希望可以给从事相关工作的产品经理们提供一些参考。

一个系统是否好用、有效，最终都取决于团队。希望产品经理们也能够从整体的视角来迭代产品，协力打造一个具备高执行力、积极向上、创新思维的团队，共同成长。

#专栏作家#

柳大叔，人人都是产品经理专栏作家。一个自由职业的产品经理，正在平坦的道路上曲折前行。专注企业服务领域的产品规划、UX、用户研究及数据分析。坐标帝都，欢迎交流。

本文原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash, 基于CC0协议