编辑导读：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协议