从销售线索到回款的七道关卡，CRM项目全流程真是一道都松不得
从销售线索到回款的七道关卡，CRM项目全流程一道都松不得
一、先把这条路走一遍
区分线索和项目，有一个实用的判断标准：这条线索值不值得投入方案资源。不需要方案资源就能推进的，是标准品的生意；需要专门组织技术力量去争取的，才应该被当成项目管起来。标准清楚了，项目清单就不会膨胀到没人看得完。
理解项目型生意的管理难点，最好的办法是把一个项目从头到尾走一遍。
起点是一条线索。它可能来自展会上的交换名片，可能来自老客户的推荐，也可能来自一次技术交流。这时候掌握的信息很少，只知道对方有需求、需求大概朝向哪个方向。线索本身不是项目，只有当它被确认值得投入资源时，才需要被当成一件事管起来。
接下来是登记与立项。这一步的意义在于把「有人在跟」变成「系统里有一个对象」，从此以后这个项目有了归属、有了负责人、有了明确的目标。再往后是方案、报价、商务谈判、签约、交付、验收、回款，每一段都有自己的参与方和自己的完成标志。
- ● 线索是原料，项目是对象
- ● 从线索到项目的那一步，是管理真正开始的地方
- ● 走得完这一段，才算完整的一圈
从管理的角度看，这条路最需要被盯住的地方不是终点，而是两处转折：一处是从线索到项目，另一处是从签约到交付。第一处转折决定资源投入得对不对，第二处转折决定承诺能不能兑现。这两处出了问题，中间推进得再顺利也补不回来。
图1：从线索到回款，中间不止几道关
二、路上有几个明确的节点
节点数量定得恰当，还有一个好处：它让不同项目的进度可以互相比较。说到底，同样是「处在方案阶段」，如果节点定义清楚，说明这两个项目面临的工作量大致相当；节点定义含糊，比较就没有意义，汇报出来的分布也就没法用来做判断。
把这条路拆细，会看到十几个动作，但真正需要被系统认定的节点只有几个。
第一个节点是项目成立。从这一刻起，它需要有一个明确的负责人，需要知道自己属于哪个客户、对应哪个需求方向。第二个节点是方案定稿。这意味着技术侧的判断已经完成，接下来的讨论围绕条件和商务展开。第三个节点是商务条件确认，包括交付节奏、验收方式、回款安排这几件事的初步共识。
再往后，第四个节点是签约，第五个节点是交付完成，第六个节点是验收通过。第七个节点是回款结束。这七个节点各有各的参与方，也各有各的完成标志。
- ● 节点之所以重要，是因为它们标记了责任的交接
- ● 每个节点都有明确的参与方，不是所有人都要全程在场
- ● 节点的完成标志要能被客观判断
节点的完成标志最好挂在已经产生的材料上。方案定稿的标志是一份提交记录加一份客户反馈，签约的标志是一份合同。交付完成的标志是一份验收确认。挂在材料上的标志不需要任何解释，谁来核对都会得出同一个结论。
图2：看板上要能看到每一步的等待
三、每个节点各要留下什么
这些记录还有一个共同要求：它们要挂在项目上，而不是挂在某个人身上。挂在人身上，人一换就断档；挂在项目上，换人只是换参与方，项目的完整过程仍然留在原处。这一点在人员流动比较频繁的团队里格外重要。
节点本身只是一个位置，真正有用的是每个节点上留下来的东西。
在项目成立这个节点上，要留下的是客户信息、需求方向、初步的规模判断，以及客户的参与角色分别是哪些人。在方案定稿这个节点上，要留下的是方案版本、讨论记录、客户方对方案的反馈。在商务条件确认这个节点上，要留下的是报价的依据、让步的边界、以及内部审批的痕迹。
签约之后，留下的东西会换一种类型：交付计划、里程碑安排、验收标准、回款节点。不绕弯子，这些内容跟前半程不同，它们的服务对象从客户变成了内部团队。用途也从「争取」变成了「履约」。
- ● 前半程留的是判断依据
- ● 后半程留的是履约安排
- ● 两种记录的服务对象不一样
这两种记录在使用中会同时出现。做下一个同类项目时，前半程的判断依据是最好的参考；做交付复盘时，后半程的履约安排是最直接的素材。分开存放，需要的时候才拿得准。
四、节点前后最容易断的地方
三处断裂有一个共同点：它们都发生在注意力转移的时候。谈判转向签约时，注意力从争取转向轻松；签约转向交付时，注意力从外部转向内部；验收到回款时，注意力又转回了下一个项目。制度性的节点确认，能在注意力转移的瞬间把该做的事固定下来。
实际推进中，最容易断的地方往往不在节点本身，而在节点之间。
一处常见的断裂是从商务谈判到签约。条件谈得差不多了，各方都以为马上要签，跟进反而松下来，等到合同流程真正走起来的时候，才发现有些条款还需要重新确认。另一处断裂是从签约到交付。签约是销售的高光时刻，团队注意力随之转移，而交付那边还没拿到完整的背景信息，于是开头一段时间都在补课。
还有一处断裂在验收与回款之间。验收通过了，但验收过程中的遗留问题没有记录下来，回款时客户拿这些遗留问题说事，双方各执一词。谁也拿不出依据。
- ● 节点之间松劲，是最常见的失控来源
- ● 交接时信息没带过去，接手方就要从头问
- ● 遗留问题不记录，回款时就变成争论
要减少这类争论，办法是让遗留问题有一个正式的出口。交付结束前把未解决的事项列成清单，写明各自的责任和计划时间，并由双方确认。这份清单不是不信任，而是把模糊的口头共识变成可以跟进的条目。
图3：拜访只是其中一环，不是全部
五、把这几个节点放进系统
把节点放进系统，还有一个附加好处：项目之间的对比变得有意义。同类型的项目，从方案定稿到商务条件确认分别用了多长时间，放在一起看就能判断哪些项目推进得慢、慢在哪一段。这类比较在靠人工记录的时候几乎做不了。
把这七个节点放进系统，需要做的其实不多。
每个节点有明确的进入条件，条件没满足就不允许往下走。这样节点之间就不会松劲。每个节点有明确的参与方，谁该在这里出现、该做什么。提前定好。实话讲，每个节点的产出物有固定的位置存放，方案、报价依据、交付计划都各归各处，不再散落在个人手里。
节点与节点之间的时间可以观察。从方案定稿到商务条件确认花了多久、从签约到交付启动花了多久，这些时长放在一起看，就能发现流程里哪一段最容易拖延。
- ● 进入条件防止抢进度
- ● 参与方明确防止互相等
- ● 时间可观察才能找到拖延的那一段
这些时长数据不应用来评价个人。项目推进的快慢受客户节奏影响很大，把时长直接算在负责人头上，只会让人想办法把记录改短。它们的正确用法是找出流程里的结构性阻力。
图4：上报订单时，过程已经走完大半
以海软CRM的做法为例，它把一个项目拆成可以被逐个确认的节点，每个节点都有对应的记录位置和参与角色，节点之间的间隔时长在项目视图里直接可见。这样管理者不需要追问过程，看项目停在哪个节点、停了多长时间就够了。
六、大家最关心的几个问题
1、问：节点是不是定得越多越好？
答：不是。节点太多，填报负担重，反而没人认真确认。控制在几个真正需要责任交接的位置上，效果最好。
2、问：小项目也要走完整套节点吗？
答：不必。可以按项目规模分档，小项目合并节点，大项目保持完整。关键是规则要提前定好，而不是每个项目临时决定。
3、问：节点到了，但客户那边没有进展，怎么办？
答：这正是节点管理最有价值的地方。客户没进展的时候，系统里会显示项目停在某个节点很久，团队就能提前讨论，而不是等到最后才发现。
4、问：参与方跨部门，怎么保证每个节点都有人负责？
答：在节点上直接挂责任人，而不是在项目上挂一个总的负责人。谁在哪个节点负责，写清楚，系统里就能按节点提醒。
5、问：这套节点能不能随着业务变化调整？
答：可以，而且应该定期调。节点设置本来就是业务经验的固化，业务变了，节点也要跟着变，否则规则会变成负担。
