心事死在
楼主
发布于 2023-5-23 09:40:11
阅读 3291
查看全部
编辑导读：CRM（Customer Relationship Management）客户关系管理，是随同着因特网和电子商务的大潮进入中国的。本文作者认为，CRM的精华不在于复杂缭乱的CRM产品功能，而在于隐含其后的管理学理论，商业形式创新以及客户运营方法的探寻。
小珠觉得CRM的精华不在于复杂缭乱的CRM产品功能，而在于隐含其后的管理学理论，商业形式创新以及客户运营方法的探寻。
市面上介绍CRM产品的文章资料比比皆是，对于管理水平，运营手腕还在开展中的国内大部分企业，这些功能与客户的痛点和需求中间隔着一层厚厚的，透明的硅胶，仿佛看得透，其实捅不破。
只要从业务理论中去，回归CRM实质，构架你的方法论和理论框架再回到业务中理论中去才干突破产品功能的藩篱，甚至跨越行业应用的壁垒。
客户，时机（商机）……这些CRM领域的根本概念，你未必真的理解！
时机的实质：
时机是什么？时机是销售过程？时机是协同过程？时机是销售活动的结果？……
在我的答案公布前，请你考虑下！
时机是销售目的！
或者时机是阶段性销售目的！
牢牢记住这句话和下面的分析，这是你设计业务时机体系的实质方法。
我们公司运行的核心任务是不时的获取更多客户的更多订单（当然还有实现各种价值！）。
从客户生命周期来看，随着客户状态从潜在客户到时机客户（建立有效联络，建立销售时机），再到已经下单的老客户及忠实客户。这里，小珠只是拿一个通用的客户状态变化过程来讲。
从潜在客户到忠实客户这是个最终销售目的，那么，有时这个目的不是一簇而就，需要分成大的阶段来完成，可能有些大的阶段还要分解成小的阶段来管理和标识，这样就产生了时机系列，产生了时机，也产生了时机的晋级阶段。
时机系列与客户状态：
对客户状态变化的精准把握是设计时机的核心!
明确客户状态：先明确在业务中的客户生命周期经历了哪些阶段。先尽量细化，忘掉系统，浸入业务。如，我们在公司的某业务中发现客户经历了CS1，CS2……CSN。
提炼客户状态：上述的CS1, CS2…..CSN是可以辨识出来的最小颗粒度客户状态。那么进一步需要分析的是，哪些状态是你业务流程，运营分析，客户管理中不需要细分的状态。剩下的就是S1, S2……SN。
举例说明：如某业务客户经历了潜在客户，维护客户，先导客户，先导交付客户，正式客户，二次购置客户，转介绍客户，跨业务客户的状态。那么在进一分析中，发如今目前的管理体系中，二次购置及跨业务客户还没有触及其他流程和其他对象的变化，所以在后续的时机体系设计中去掉这两个状态使用，潜在客户，维护客户，先导交付客户，正式客户，转介绍客户这六个客户状态即可。
时机系列与销售形式：
销售团队：这里的销售团队，并非指承担类似销售任务，采用相同销售方式的不同团队，而是指在整个客户状态推进过程中承担不同阶段任务的销售团队。
比如，在上例的潜在到转介绍客户6个客户状态的过程分别由两个类型的销售队伍：前端销售团队和后端销售团队负责。
前端团队：负责潜在到正式客户的状态的推进，即客户完成第一次正式产品的采购这个过程。那么自然我们就设计出一个时机系列或者类型，可以命名为新客户开发过程或者叫M系列。
后端团队：负责第一次下单的客户再次购置及介绍新客户的状态的推进，那么这个时机系列为老客户维护过程的时机系列，如S系列。
业务优化：
客户状态和销售形式匹配：认真考虑上面的过程，从客户状态到销售形式再到时机系列。在小珠的从业经历中，有很多客户状态和销售形式不匹配的情况，那么优化客户状态和销售形式及分工到匹配的阶段是个业务优化的大动作，也是时机设计的根底。
简化举例：最典型的情况，在互联网时代下，原来的新客户开发形式大大改变后，原来复杂的开发过程，呼叫中心应用等被自动导入客户功能取代。企业发现从潜在到正式客户的过程已经大大简化，缩小，几乎无需销售人员的介入。那么，整个潜在到转介绍的客户状态推进过程中无需要二种销售团队，也无需对应两个销售时机系列完成。
分解举例：而在另一种业务中，我们发现从客户完成导向体验课订单，到在体验课上下单由原来销售完成不太复合业务场景，转由负责试听课程的教学职能完成比较适宜，所以从原来的前端销售再演化出中端过程，这样销售分为前，中，后端，时机也要多设计一个系列。
方法总结强化：
综上，先理解时机实质是完成客户从潜在到不时下单的状态推进这个大目的的阶段性目的。
梳理客户状态，优化客户状态，分析销售形式，功夫到家的CRM业务构架人员不只仅理解业务的销售形式还要本着客户状态演化和销售形式和谐的目的去优化二者到达匹配。在此根底上才干去设计你的时机类型或者叫时机系列。
接下来就是给你的时机设计阶段，这里有非常多的考虑和误区，小珠会在后续的文章中介绍。
一定要有时机？
假设你理解了时机的实质，就能回答这个问题，假设客户状态在整个客户生命周期就有很少的变化，只要2，3个状态，也没有复杂的销售形式分类，那你的CRM中根本无需机械的设置时机对象。
那你直接关注客户状态的晋级即可。这也是很多人纠结我是看客户状态这条线还是看时机晋级这条线的原因所在，这还是不理解时机的实质的表现。
不机械化的使用时机，不机械化的套用CRM产品的概念（特别是源于B2B业务的产品们），不机械化的设置复杂的时机阶段（通病，下回分解）
就如我们求学阶段所学定律，概念，核心概念都很简单，但是你真的理解吗？大道至简，理解实质，才干突破。
一、“突破迷局”：CRM“时机阶段”设计详解与实务 (上）
从客户整个生命周期笼统出客户状态变化，提炼出相关过程。分析销售形式，即分析出业务中有哪几种销售职能完成什么阶段的销售任务。将销售过程和客户状态协同并优化，来设计好你的时机系列。
1. “线索”和“商机”与“客户建立”
需要说明的是，不要因为CRM中线索，商机的分割而感到困惑。在初期的潜在客户阶段，信息有限，可能客户文档（新建客户）的时间点也发生在线索之后，符合某些业务判断后，才转化为时机（商机）。
而这些都是整个客户生命周期中的主要状态，如何分割，是否分割，建立文档和线索哪个在前，哪个在后？看业务对客户信息获取需要和业务分工情况而定。
A公司的业务从Social 工具（可能是Socail CRM，抑或官微，官网）中获取初级线索，那么第一个发生的对象即为线索。之后，经过初步筛查和审核后，甚至客户接触后建立客户文档，这里常见的筛查就是查客户信息的“合法性”，比如缺乏11位手机号码，信息明显逻辑正确等。有时，销售会依照初步信息去和客户接触，挑选可以继续接触，有业务时机的客户来建立该客户的文档。最后，再根据客户初步对产品的意愿建立商机（时机）。
线索 > 客户文档 > 商机
B公司的业务从很难从社交媒体上获取线索，获取线索起点为销售首次发现，并获得有效客户信息，注册客户后，再根据客户联络的详细情况建立商机（时机）。线索的过程非常模糊，甚至没有必要存在。
客户文档 > 商机
2. 时机阶段设置的目的
先看清楚时机阶段设置的目的，才干把握好如何设置时机阶段。常见的设置时机阶段目的有如下几种：
区分销售阶段，标志时机进程，展示业务分布。
标志时机停止的水平，获得阶段成果，整体上也可以分析某项业务都有多少在停止的时机，每个阶段都有多少个时机，每个阶段都有多少的业务量（估计金额），这种业务的分布经常会以漏斗形存在，所以在有些CRM产品中，常成为销售漏斗，英文叫PIPELINE。这种分布展示可以分析业务的同比环比情况，也可以提醒业务形势好坏。
漏斗过程
阶段分布同比比较
销售预测，基于赢率的漏斗，调整业务规划。
销售漏斗这里涉及到几个“率”，转化率，分布比例，赢率，三种比率是提醒销售推进情况，销售预测和业务形式的重要数值。
转化率：是指销售阶段能胜利向下一个阶段推进的比例，比如处于初步接洽的时机在2017年8月初为2000个，追踪这2000个时机，其中有1000个转化为需求确定及其以后的阶段，800个维持现状，200个放弃。那么这2000个时机在8月这一个月的转化率为50%。
分布比例：是指某范围内的所有时机在各个阶段的个数或者金额占比。
赢率：赢率是销售漏斗乃至销售预测中一个特别重要的话题，小珠后续会拿出一篇文章专门介绍赢率的设置，使用方法。首先要明确对于业务来讲，赢的概念是什么？是“中标”，是“签订合同”还是“全款到位”，假设是“中标”为例，那么之前的每个阶段转化到“中标”都有个比例，这个比率为“赢率”。
每个阶段到“中标”都有转换率，严谨的“赢率”是个事后数值，也就是说，有个起始点，在经历一段时间后看各个阶段转化的结果，赢率是各个阶段转化率的叠加。
而我们常说的赢率常常是个估计值，经历值，用于对某将来时点的业务结果停止预测。常有固定赢率是单独给出赢率二种。
如：某业务估计成交日期在2017年1月到10月的时机有10000个，P1阶段有4340个，估计金额为5000万，赢率为10%，估计中标金额为500万；P2阶段为3000个，估计金额为2000万，赢率为30%，估计中标金额为600万；P3阶段为2000个，估计金额为1000万，赢率为60%，估计中标金额为600万；P4阶段为300个，估计金额为500万，赢率为100%，估计中标金额为500万；P5为280个，估计金额为400万，赢率为100%。所以该业务从2017年起估计截止2017年10月估计中标金额为2600万。
凝结销售方法，浸透销售智能，规范销售行动。
一些大客户长周期处置方案式的销售对销售自身的专业才干，销售技巧要求比较高，销售周期长，对销售过程的管控集中在重要节点，重要结果，无需记录管控销售所有行为和细节。
更多的小B型的业务，销售人员门槛不高，销售中需要规范，管控详细的交互信息，那么销售阶段及相关任务和详细方法要固化在销售阶段中，指导，规范销售的行为。
这时候时机阶段和行动对象有非常严密的关系，常常完成规定动作，规定行动方可升迁。时机的类型也会总结，固化下来。
即把SOP甚至话术浸透在销售时机及其对应的行动对象中。
触发业务流程，规范数据获取，提升数据质量。
对于一些重B型的业务，在不同的销售阶段会产生，评估，审核，计算等不同的业务流程，比如到了方案阶段，可能要产消费品配置需求，方案评审流程，价格预审流程。在时机初期，对于具有存货本钱（前期投入大量人力，物力）的业务类型（大型软件厂商）可能有时机评估及立项的流程和节点。
这里小珠想分享的是，对于CRM和OA分工的问题，在大型CRM系统规划时都是个重点和难点，小珠赞同在结合现有公司IT系统才干的前提下，在CRM中实现销售业务相关的严密流程（无论是在CRM系统自身实现还是调用其他流程）。
这些流程直接实现了数据搜集，比如价格审批中自然对时机估计金额修正和精准，自然地通过人为审批对关键数据质量加以控制，如业务管理者做业务审批时自然对客户信息和时机信息加以审核。
依托这些流程自然地完成客户和业务数据的搜集，整理，不用为了搜集数据而搜集数据，减少销售人员的抵触和反复填写。
当然，当业务流程过于繁琐时，通过CRM体系建立，优化业务流程是常见的做法，认真审视某一流程节点是否可以合并，是否到达管控的目的。CRM规划人员不能全盘接受现有流程，让CRM沦为OA。
二、“突破迷局”：CRM“时机阶段”设计详解与实务 (下）
本文上篇介绍的时机阶段设计中“线索”和“商机”与“客户建立”，同时还和大家交流了“时机阶段的目的”。本文将完成下半部分。
1. 常见误区
阶段过多，混淆客户状态变化和时机阶段。
这是时机阶段设计经常会遇到的问题，小珠曾经遇到过的项目中，有将所有客户状态变化均设置为时机阶段的实例，一个时长不超越1个月的新客户开发周期，设置长达8个阶段，销售除了停止销售工作外，还要不时地对系统中几十个停止中的时机停止阶段晋级和维护，而这些时机节点既无业务分析预测价值，也起不到规范行动的作用。
节点模糊，混淆过程和结果，难以判断
问题2常常和问题1伴生，如“建立联络”，“消除异议”，“获得信任”，这些目的都是达成“有效联络”，应该以获得合法且不反复的客户决策人员手机号为准，而不是都设立为时机阶段。
“规定动作”当成销售阶段。
在达成销售阶段目的的时候，有些业务会设计些规定动作，如有效电话，邮寄资料，高层访问，讲解方案，老客户现身说法，试用试听等等，这些销售行动，可以关联在销售阶段中，设置成“必需”或者“选择”动作。有的销售形式甚至会选择“动作到位”及升迁阶段的方式，一般在销售阶段成果不明显，同时还需要对销售行动严密管控及规范的销售形式中。可以在销售阶段中设置与行动对象的关联关系，而不是混淆二者。
机械设置“赢率”
在小B的业务中，或者单体时机规模小数量大时，当时机阶段和赢率对应关系比较明晰，亦或没有“库存本钱”或者时机预测只是看看大约业务走向（那不如直接对比时机阶段状态分布）的时候可以依照经历大致设置每个阶段的时机的“赢率”。
还有一种比较理想的情况，公司长期，积累而大量准确可靠的业务数据，建立起多因素影响的赢率估计方法（比如客户类型，项目规模，时机阶段，客户细分，涉及产品等因素），可以给出每个阶段的固定赢率。在当前国内甚至国外企业的销售管理水平和CRM体系运营水平下，几乎无法到达这个效果。
将赢率依照项目阶段机械的固定下来，使得的业务预测数据失去价值，特别是对于数量少且单个时机体量大的情况。一个不够准确的赢率加权到估计金额大的时机上，对整个业务的预估产生非常大的偏向。
如：共有100个时机来停止业务预测，估计金额为1亿。其中某一个估计金额为3千万的项目到了方案阶段， 假设赢率固定为30%。那么自然估计中标金额为900万，而实际这个项目可能性非常小，本着增长经历的想法去推进该业务，中标率几乎为0。那么这900万就机械的参与到业务预测中，使得预测结果大大偏离实际。
对于上述业务情况,更适用于销售或者业务主管手动给出赢率并随着业务推进不时修正赢率的做法。
2. ”阶段“与”结果“的考量
对于很多时机在“中标”，“赢单”的设置会存在纠结，因为依照业务流向，并不是所以业务流向都是单一结果分支，有中标就有输标，有赢单就有输单。 单从漏斗赢率及业务预测的需求不需要考虑这些，但大部分业务中还要分析赢单结果和输单结果。特别是有一种业务情况，当输单发生时并非业务的终点，还有时机跳转到赢单的状态，所以输单的状态和阶段也要管控起来。
一般不会为输单单独设置时机阶段的节点，而是将“中标”节点演化为“结果列示”阶段，该阶段触发业务结果字段的填写，并对应触发结果原因分析。
3. 方法总结
依照上图分析后，同时还要注意根据业务情况设置时机结果是否可以回退，是否必需连续升迁等。
本文由 @小珠CRM 原创发布于人人都是产品经理。未经容许，制止借鉴
题图来自Unsplash，基于CC0协议 |
|
