从目的、定位、落地三层面，谈谈我的CRM产品方法论
导语：CRM（客户关系管理）是一种企业与现有客户及潜在客户之间关系互动的管理系统，通过对客户数据的历史积累和分析，CRM可增进企业与客户之间的关系，从而增加企业销售收入和进步客户留存率。本文作者从目的、定位、落地三层面，为我们谈一谈他的CRM产品方法论。
近两年产品工作的核心根本在围绕CRM展开，本文将从CRM的目的、定位、落地三个层面系统的总结关于CRM的产品方法论。
一、目的
CRM系统搭建和迭代的前提，基于3点：
目的的制定属于战略层的业务决策。其影响因素不只限于内部资源、组织架构，同时与外部市场趋势及竞争环境相关。对于科技公司，业务目的根本可以归类为收入增长、用户增长、用户行为数据增长3类。
针对CRM系统，核心目的一般效劳于收入增长。用户及其行为数据的增长虽然是收入增长的根底，但系统层面的目的，多数是如何通过这些数据更好的协助团队达成预期收入。
对于收入的拆解，不同业务形式的定义大相径庭，总体上可以笼统为：收入=符合某些特征的用户数×该类用户付费金额，通常这个公式的表述是：收入=用户数×每用户平均收入（ARPU），ARPU值的影响因素，通常与产品效劳用户的频率和时长相关。
若引入用户生命周期的概念，则可优化为：收入=用户数×生命周期价值（LTV=LT×ARPU），简单描绘，LTV就是产品从获取一个用户到彻底流失该用户所得的全部收入。从应用层面理解，LTV应是一类用户的平均生命周期价值，因而某段时间周期内的收入应=用户数×流失率×ARPU。
基于上述公式，可推导出下列因素均可协助收入增长：
用户数增长高质量用户增长提升效劳频率及时长提升运营人员效劳效率（即人效）降低用户流失率
运营人员的数量和工作时间往往非对应的产品经理能决定，因而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协议 |
|
|
|
|
|
|
|
|
