CRM是管理企业和客户在销售、营销、服务等层面上的交互，实现销售自动化、营销自动化、服务自动化，最终进化为智能化。销售自动化的前提是对客户的分类管理，那么客户来自于哪呢？

CRM（Customer Relationship Management）客户关系管理。在百度百科中的解释为：客户关系管理是指企业为提高核心竞争力，利用相应的信息技术以及互联网技术协调企业与顾客间在销售、营销和服务上的交互，从而提升其管理方式，向客户提供创新式的个性化的客户交互和服务的过程。其最终目标是吸引新客户、保留老客户以及将已有客户转为忠实客户，增加市场。

聊CRM就不能不提到他的开山鼻祖Siebel CRM，它是以其创始人Thomas Siebel命名的。1984年Thomas Siebel以系统工程师的身份进入Oracle，此后转身成为了Oracle最出色的销售人员，并作为营销部副总裁来进入总部工作。

他开始考虑将信息技术应用于建立和维持客户关系。此后Siebel帮助Oracle建立了Oasis的系统，用于加强公司自身销售管理能力。随着不断的积累，Thomas Siebel最终离开了Oracle，成立了以自己名字命名的Siebel公司。

• 1995年6月，Siebel发布了自己开发的销售自动化软件。产品一鸣惊人，第一年的销售量800万美元，第二年就攀升到3920万美元。
• 1996年，Siebel公司上市，每股17美元，上市当天股价就翻了一翻。
• 1997年，Siebel 花费4.6亿美元以获得专门制作客户服务软件的Scopus 技术, 当年公司的销售额由原先的1.2亿美元迅猛的增长到2.7亿美元
• 1998年又攀升到了3.9亿美元。
• 2005年的时候，Oracel以85亿美元的价格收购了Siebel，Thomas Siebel本人也同时回归Oracel。

在Siebel迅猛发展的同时，另一家日后的巨头则刚刚起步。Mark Bennioff在1999年3月创立的Salesforce，可提供SaaS化的客户关系管理平台。

格局的分水岭大概是在2011到2012年出现的，这一年Siebel在国际上丢了三个大客户，IBM、微软、惠普。IBM替换成了SugarCRM，微软换成了自己的Dynamics CRM，惠普则使用了Salesforce。在国内Siebel也丢失了一个大客户——北京移动，好像是国内第一家替换掉Siebel CRM的公司。至此Siebel开始走上了下坡路，Salesforce则成长为今1600亿美金市值的巨头。

下图是网上找到的有人在2017年1月做的一张CRM厂商图谱，展示了各家个爱恨情仇。

CRM是管理企业和客户在销售、营销、服务等层面上的交互，实现销售自动化（Sales Force Automation）、营销自动化（Marketing Automation）、服务自动化(Service Automation)，最终进化为智能化。销售自动化的前提是对客户的分类管理，那么客户来自于哪呢？

一、线索商机

线索（Leads）是企业的潜在客户。线索数据的来源很广泛，会议的报名信息，展会上收集的名片，网站上的试用申请，询价信息，从数据公司购买的线索数据，等等。

商机（Opportunity）将错误的、无意向的、不相关的线索排除掉，留下有意向，有可能有意向的潜在客户，就是商机。

1. 线索

（1）数据问题

线索数据来源广、渠道多，这就势必造成会出现很多问题，例如数据缺失、错误数据、假数据、重复数据等等。

1. 不同的场景设计不同的数据收集维度。产品试用场景维度不用太多，公司、行业、联系方式等大约3/5个就差不多，更多的信息可以通过后续的沟通了解。会议邀请场景可以适当的增加信息维度，如果潜在客户对内容感兴趣不会太排斥。户外广告可以直接引导到公众号，再通过后续的互动逐步获取线索信息。在线索收集过程中，要注意能选择的不要设置成手动填写的，可以在合适的场景中增加数据校验，比如手机验证码。
2. 线下录入线索数据。人都是有惰性的，当在外跑了一天回到公司还要填报一大堆的数据，有时候线索数量还被设置成KPI进行考核。这就要考虑录入的便利性，比如增加移动端方式。在录入线索数据时要求上传照片或者定位数据作为证据（定位数据要考虑法律风险，国外有被起诉的案例）。同时需要设立对应的规章制度，不要单纯的考验人性。
3. 来源渠道多势必会造成线索数据重复的情况发生，如果不加以限制有可能会对已购客户造成骚扰或者增加销售的工作量。针对个人客户一般是通过手机号、邮箱进行去重。这两项是最容易获取的标识ID。企业客户相对就会比较麻烦，有联系人信息的优先根据联系人排重。其次根据名称+地址信息进行数据聚集，这时候并不太好直接去重，还是需要人工判断下。

（2）线索分级

在线索数量不多的情况下，本着蚊子腿再小也是肉的原则，全部跟进是必须的。但当线索数据充足的情况下，不加以区分的顺序跟进肯定不会是最优解。

曾经有客户（toB企业）对于线索的处理流程是：

1. 收集各渠道线索数据；
2. 交给呼叫中心进行外呼；
3. 呼叫中心按周向销售部门提供外呼结果；
4. 销售跟进。

这里边有几个问题：

1. 线索数据没有集中管理；
2. 线索不分主次统一处理；
3. 受限于外呼资源，信息反馈慢。

第一个问题好解决，接入到统一的系统中就OK了。

第二个问题需要对线索进行评分，分出优质层级。我们在系统中不只是接入了线索数据，还包括广告监测数据，官网、小程序、公众号等监测数据。然后设计规则综合各方数据对线索进行评分（这其实涉及到另外一个CDP系统的概念Customer Data Platform，这里我就当成CRM的基础功能使用了）。

因为数据的多样性，对线索评分除了数据完整性就有了更多的维度：

• 行业                                 5分
• 有邮箱                             5分
• 有地址                             5分
• 最近7天点击过广告          10分
• 最近7天访问过小程序      10分
• 关注公众号                      10分
• 打开H5微页面                 5分
• 观看直播                        10分
• ……

除了加分项还会有扣分项，通过规则计算显而易见的我们知道了哪些线索最为重要。其实除了规则的计算引擎，我们还尝试了算法。

由于初始样本数据量比较小，通过算法得出的线索评分和规则引擎的计算结果相差不大。但我想如果样本数据量够大的话，应该还是会有新的变化，比如地区，甚至留资的时间是不是都会成为参考依据。

第三个问题在解决了上边问题的基础上就有了优化方案。不再是将全部数据给到呼叫中心，而是将高价值线索直接给到销售人员，剩余的线索再给呼叫中心。根据外呼结果会对线索再次评分，这次的评分占比会比较大足以影响线索等级，最后将有价值线索分配给销售。

这样有几个好处：

1. 高价值线索直接到销售手中，响应时间短且销售人员对产品的了解更透彻有利于成单。
2. 从另一个角度看当销售知道手中的线索价值较高时会更有耐心，不会因为一两次未接通电话就放弃。而外呼人员手中有大量的线索数据，而且有外呼数量的KPI考核，不会在单个线索上耗费太多精力。

（3）线索分配

要实现线索的利用率和成单率的最大化，只是区分出线索价值还是不够的。企业需要一套机制来实现线索的分配、回收、流动，最终实现转化。

就像《安家》中，老洋房业务就找店长徐文昌，别人卖不掉的房产房似锦可以。

不同的企业，不同的业务形式，实现的方式也不一样，整体规则也是一个不断完善不断优化的过程。

下图根据实际经验以及网上的一些资料列出了一些常用的方式方法供大家参考：

下图是组合应用的一个示例：

2. 商机

有效的线索经过跟进后，如果潜在客户对产品/服务有意向，那么就会转为商机。一般商机会划分成几个阶段，随着销售和客户之间的沟通进展，通过阶段递进的形式构成漏斗进行管理。

需要思考的是一个CRM系统中是不是线索和商机都要包括？我觉得这就要分情况来看了。如果是设计标准的CRM产品，那么这两个模块还是都要存在，并且是有一定的递进关系的。

而如果是贴近业务的定制化CRM则需要仔细分析一下，比如一些2c的业务（教育、培训），消费者的决策链条没有那么长，销售也没有那么明显的阶段区分，那么是不是只有线索模块就够了，或者说把线索和商机的功能结合一下整合成一个功能模块。

这里会涉及到每个阶段销售的拜访记录、客户意向产品/服务、意向金额、失败原因、竞争公司、竞争产品等信息，成单的商机会生成合同。还会有人员流动等各种原因造成的商机转派；申请后台业务或技术同事参与拜访等功能。

其他周边功能：

任务管理，销售记录自己每天的任务包括电话、拜访、会展等。可以关联线索商机，也可以独立存在，最好要求每个任务有结果说明。这样销售不但可以计划自己的工作任务，同时也保证每个事项都有结论记录，俗话说的好好记性不如烂笔头。部门领导也可以方便快捷的了解到每个销售同事的工作状况。

排行榜，原因不用多说是青铜还是王者榜上见。可以设立全国、区域、团队等多范围的排行。

目标管理，管理销售年度、季度等维度的销售目标，以及目前达成率。仅限上级于本人查看。如果有明确的奖励规则，甚至可以将奖励或提成的也展示出来，形成直观刺激。

二、客户联系人

客户是整个系统和核心，一切都是为了更好的服务客户。一般来说是于企业订单或合同的潜在客户（线索商机）才正式成为客户。

1. 客户、联系人

企业面对的客户群体不同，大体上可以把客户分为企业客户与个人客户两类。

企业客户主要包括的基本信息有：客户名称、简称、行业、统一社会信用代码、国家、省份、城市、公司规模、企业类型、公司电话、传真、邮箱、官网、上级企业（父客户），以及其他业务相关字段。

此外客户实体还有一些是一对一或一对多关系的实体信息，比如：联系人、收货地址、开户行、结算账户、订单、合同、子公司等。因为有可能会涉及到财务信息，所以企业客户的信息修改还会有审批流程。

个人客户主要包括的基本信息有：姓名、性别、生日、手机号、邮箱、证件、地址、行业、职业、职位、学历等。其他一对一或一对多关系的实体信息有：分组、标签、触点行为记录。此外业务不同可能还会有订单、资产、服务请求等。

联系人字段内容和个人客户类似，包括除了姓名、联系方式等信息外还有所属客户。一般来说一个联系人有且只能属于一个客户，一个客户可以有多个联系人。由于联系人和个人客户存储信息很类似，如果企业只做2C业务的话即只有个人客户，是不需要联系人模块的。如果同时具有企业客户和个人客户，建议在创建个人客户时自动在联系人中创建一条对应的联系人数据。

这样做的目的有两个：

1. 客户—联系人数据关系统一；
2. 后续在做分组、打标签时，统一都在联系人上操作，避企业客户与个人客户不一致。

泛客户联系人，在传统CRM的基础上social CRM还会接入其他的数据，最常见的的是微信公众号、小程序、微博等。公众号、微博的粉丝并不属于传统意义上的客户，但在现实情况下又是很好的触达和传播渠道。所以将这些粉丝数据当做泛客户、泛联系人。

随着数据的积累，当能识别出粉丝数据和客户联系人数据的关联关系后，进行数据合并。考虑到营销层面，营销的最终目标是人，不管是公众号粉丝还是微博粉丝都是和手机号、邮箱一样的渠道。

在电信行业对于客户有个著名的三户模型：

你品，你细品，品出点啥？

2. 标签

维基百科中对标签的定义是这样的——标签是无等级的关键字或分配某项物品的信息（如互网络书签，数字图像，或电脑档案）。这样的数据有助于说明一个项目，并允许它再次发现浏览或搜寻。

根据系统，标签本身被非正式创作者或其他观察者选择。 在许多用户标记许多项目的网站上，标记的汇集成为分众分类法。经常说起的用户画像，基本上也是将用户各种维度的信息进行标签化，及用一个个的信息点去描绘用户。

那么那些信息可以作为标签呢？

性别、年龄算不算，如果是描述一个人当然算。但在系统中，这些虽然也是很重要的信息，但我认为更应该归为属性而不是标签。标签应该具备分类、次数、权重、关联性等。

（1）分类

标签体系的建立不是一蹴而就的，而是随着对业务的梳理和发展慢慢发展起来的。

标签的分类也是根据业务进行划分的，不同行业不同产品都会不相同。一般可以从两个大的角度进行考虑：人和产品/服务。比如从人的角度可以考虑互动频率、互动内容偏好、活动偏好、消费特征、性格等等。产品/服务可以从其不同品牌、型号、功能等去进行分类。

（2）次数

这个很好理解，在其他情况相同的条件下，同一个标签被打上的次数多肯定要比少的浓度要高。

（3）权重

要计算好标签的权重是比较复杂的，请阅读《用户画像之标签权重算法》这篇文章中的内容，很是认同其中的设计逻辑。如果暂时不想设计的这么复杂，衰变个人觉得还是很有必要的。相同的标签一个客户是近期被打上的，而另一个客户是三年前被打上的，那么在一场营销活动中的反应很大可能是不一样的。

（4）关联性

尿不湿和啤酒的故事大家应该都听说过。那么在标签体系中看似风马牛不相及的两个标签是不是也会存在这种关系呢。想想就觉得好复杂啊，再次偷懒请大家移步《『啤酒与尿不湿』之关联规则》，还是交给算法工程师来解决这个问题。当有足够多的数据进行支持的时候，那么在营销层面就有了更多的玩法。

3. 分组

当客户积累到一定数量时，为客户进行合理的分组十分重要，它能够帮助企业提高管理效率，而无需再在茫茫客户群之中费力的找寻。

这里有两种方式：

1. 一个客户只能属于一个分组；
2. 一个客户可以属于多个分组。

第一种方式客户分组清晰非此即彼，但不能多个维度综合分析。所以更倾向于第二种方案，可以从多维度设置不同分组，也为交叉分析做好准备。

4. 客群

具有某一类或几类公共特征的客户群体。是不是觉得和分组很类似，会觉得功能重复。确实有那么一点儿，初始我也觉得很困惑。但其实两者之间还是有区别的（要不我也不会写出来了）。

分组更像是一种常规稳定的客户类别，就像我们在QQ好友中分的初中同学、高中同学、大学同学。客群则更像是团购中的拼团，往往是为一次活动、营销、销售等等按一定条件圈定出来的群体（当然也可以长期存在）。

这个条件可以选择的范围更广、甚至各种条件组合。

• 比如从事件角度：浏览了商品页面、购买了某款产品、打开了H5页面、扫描了二维码、提交了问卷等。
• 从标签角度：具有某标签、不具有某标签、标签多少分值之上、某标签被打了几次。从属性角度：性别、地区、年龄段等。

三、产品价格

前边我们又是对线索分级评分，又是对客户打标签分组，最终目的是将产品（服务）销售出去，这就少不了产品的管理。

这里主要关心两个方面：

1. 卖的是什么产品；
2. 价格是多少。

（1）简单产品

最简单的产品只需要产品编码、产品名称、产品描述、产品图片等简单信息。需要有一个产品发布功能，只有发布的产品才可以在后续价格列表、订单等业务中使用。

（2）产品属性

当需要更为复杂的产品数据时，就需要使用产品属性了。包括属性名称、数据类型（字符串、数字、日期、布尔值）、样式类型（自有格式、枚举、排除）、单位、最大值、最小值、属性值。举个例子：属性名称—颜色，数据类型—字符串，样式类型—枚举，属性值—红色、蓝色。

（3）产品类

建立一个大的产品类别，将产品属性加入到产品类中。可以设置产品属性的默认值、只读、隐藏等。当新建自定义产品时，选择对应的产品类，会自动在产品中加载产品类中定义好的属性。如果有面向对象经验的话，会比较好理解，其实就是类—属性—实体之间的逻辑关系。

（4）产品目录

当产品数据很多的时候，可以通过将产品添加到产品目录中，对产品分类管理。产品和产品目录是多对多的关系。尤其是在合同或订单录入时，可以通过产品目录快速找到目标产品，方便操作。

（5）父子产品

在产品中添加其他产品做为子产品。当在合同订单中添加产品时，如果该产品为父产品，会自动将子产品添加到行项目中。

在配置父子产品时有两种类型：

1. 是赠送；
2. 是捆绑销售。

当时赠送时，订单行项目中的子产品是不计入总价的，捆绑销售则会计入到订单总价中。

（6）价格列表

价格列表要有名称、生失效时间、货币、说明等。行项目中添加产品和价格，每个行项目可以设置单独的生失效时间。在订单头上配置价格列表，订单行项目中的产品将依据该价格列表展示价格。

（7）属性价格列表

属性价格列表绑定产品类，根据产品类中配置的属性，生成笛卡尔积属性矩阵。然后配置对应的价格调整方式及数值。将属性价格列表添加到产品价格列表的产品行项目中进行使用。

• （8）产品促销

和价格列表类似，但在促销行项目中产品对应的是价格调整方式及调整值。将促销方案配置到订单头，订单行项目中产品会在价格列表价格基础上依据促销方案对价格进行调整。

四、营销触达

传统CRM在营销层面功能相对是比较弱的。随着这些年的发展，对客户的营销手段越来越丰富，除开传统的呼叫中心、短信、邮件（EDM）、展会，到现在的微信、微博、小程序、短视频、直播……渠道和方式越来越丰富。这里基本不涉及到广告投放，其将由DSP、Trading Desk等完成。

（1）营销活动

企业在进行营销活动，无论是线上或者线下都会使用到各种各样的营销内容，管理和统计每一项营销内容的工作非常繁琐，而营销方案管理功能可以帮助营销人员简单地将所有的营销内容进行汇总管理，并且营销人员可以自己设置每项内容的完成进度以及查看每项营销内容的效果统计。包括活动名称、渠道、目标人群、使用素材、预算、规则、活动日期等等。对于一些经典或者有规律的活动可以保存成活动模板，方便后续快速使用。

（2）营销素材

包括图文、图片、音频、视频、海报、H5微页面、问卷、H5小游戏、二维码、模板消息、短信模板、邮件模板等。

（3）自动化营销

这是现在SCRM中基本都具备也都在说的一个功能点。主要是在画布中将预定义的一些步骤组件通过拖拽的形式组合到一起，以任务的形式执行某些营销活动。步骤组件一般分为受众、动作、条件判断等几大类别，通过定时触发添加人群的做法，对满足条件的客户自动触发后续动作。同时这种拖拽化的交互操作，使操作人员更方便，逻辑也更清晰。

（4）裂变营销

近些年很火爆的一种营销方式，像专属二维码海报、专属口令、链接等。

总结起来大致是以下几步：

1. 选题；
2. 准备诱饵；
3. 种子用户；
4. 步骤执行；
5. 新用户留存；
6. 活动总结。

五、合同订单

CRM中的合同更主要侧重客户相关方面的管理，对于产品和财务方面一般会对接ERP或财务系统。

（1）合同录入

合同信息录入包括：编号、名称、类型、签订主体、金额、数量、付款方式、状态等其他业务相关字段内容。还要包括一些附件的上传功能。某些情况下还应具备合同导入功能。

（2）合同审批

审批一般包括并行和串行两种形式。并行及在一个审批节点上有多名审批人，任何一个审批人进行审批都可以。串行只有一层审批人通过，才会到下一层审批人。合同审批不同于其他数据的审批，合同具体很强的法律责任，需要考虑增加法律人员的审批节点或接入法律系统。

（3）合同变更

作为双方权利义务的约定，合同的变更必须要记录好版本和变更记录。一般只有审批通过或正在执行的合同才可以变更。对于正在审批中合同会发起驳回请求，完成的合同则不允许变更。

（4）其他功能

包括：提醒、暂停/启用、归档、作废等。需要注意各个功能间的逻辑规则。

（5）订单

合同和订单是一对多的关系，一个合同下边可以有多个订单。而每个订单会包含多个订单行项目，一个行项目对应一个产品或服务。

之所以合同下边还会有订单这一层，那是因为一个合同可能会有多个收货方，对于年度合同或者框架合同会分批次去执行，每个收货方或者每个批次都可以是一个订单。在一些业务流程相对简单的场景可以不需要合同直接到订单层，像我们在各种电商平台付款后叫提交订单而不是合同。

六、服务请求

与客户完成了合同的签订并不是整个流程的结束，从某种角度来说应该是刚刚开始。如何服务好客户，及时有效的解决客户的疑问、请求、咨询、投诉，对客户对企业、产品的忠诚度、好感度有着直接的关系。

（1）创建

有两种方式进行创建：

1. 通过客服或相关服务人员手工创建；
2. 通过自助渠道（邮件、短信、网页）由客户创建。

信息包括：编号、客户、产品、类型、内容描述、状态、紧急程度，当前处理人员、处理记录（多条）、解决方案等。其中类型可以是一个多级联动的下拉列表，尽量将分类分详细。

（2）流程处理

对于相对简单或者比较常规的服务请求，基本在客服人员接待过程中即可解决的由接待人员直接结单。客户自助渠道就会有分派的需求了，一些基本方法可以参照线索的分配方案。可以通过地区、渠道、类型分配给不同的客服组或人员。

对于复杂的请求，就需要有升级、转派的功能，将服务请求提升到领导处理或转派给其他适合的同事处理。某些企业业务场景，还需要能生成工单用于技术人员参与甚至出客户现场。整个处理的过程需要进行记录，包括参与人、处理方案、客户反馈等内容。

（3）状态

下图是一些常见的服务请求的状态：

• （4）知识库

为实现服务客户的标准化、准确化，将话术、解决方案、产品介绍等知识化是很有必要的。既可以当做员工平日里的学习途径，当服务客户时又可以当成工具手册进行使用。像电信行业，因各种套餐、活动、优惠、规则繁多且变化很快，甚至是将知识库单独作为了一个系统，当我们拨打客户电话时，可以迅速查询出需要了解的各种信息。

七、统计分析及预测

从业务角度统计分析是不可或缺的且十分重要的功能。不同行业、客户、部门关注点都不尽相同，这需要根据实际业务进行分析。在做定制化开发的时候，这里也往往是需要重点讨论的一个地方。

从功能角度，一般会为客户准备一些相对通用的统计报表。复杂的话会提供自定义报表的功能，功能更强大的像国际上很出名的Tableau产品等。传统的统计分析往往都是人定义目标，然后从数据中去进行分析。

随着技术的发展，更多的应该引入数据科学由算法对数据进行分析，往往能发现一些意向不到的点。而且可以对将来进行有效预测。现在很多的国际上的大牌零售企业已经在进行这方面的工作了，比如提前预测双11各个渠道的销量的。

八、其他

作为标准化的CRM产品基本上会包含上边绝大部分的业务功能，但如果是自建系统则需要根据实际业务对功能进行取舍，同时添加特定业务相关的功能，系统是为人服务的不要被单单一个名字限定住。像CRM也好，ERP也好都是将相关联的业务和功能组合到一起形成的。

以上算是对之前工作的一个总结，啰啰嗦嗦写了不少。

下面要说一个更更更重要的事情，有没有和CRM产品相关工作的坑砸过来啊，有的话请发邮件 392051121@qq.com，在此提前拜谢。

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

题图来自Unsplash，基于CC0协议