不进不退的项目最该被看见，CRM究竟该怎么设计停滞提醒不扰民

不进不退的项目最该被看见，CRM如何设计停滞提醒才不扰民

一、停滞是一种状态，不是一件事

这类项目还有一个特征：它们看起来不紧急。紧急的项目会自己冒出来，停滞的项目只会慢慢沉下去。所以管理上的难点不是发现之后怎么处理，而是怎么让它在沉下去之前被注意到。

项目推进里最容易被忽略的情况，是它既没有失败，也没有前进。

没有失败，所以没人上报；没有前进，所以也没有新的记录产生。它只是安静地待在那里，时间一点点过去。等到某天有人问起来，才发现这个项目已经很久没有动过了，客户那边的窗口期可能已经关了。

这种状态很难被人的注意力捕捉，因为人的注意力天然会被有动静的事情吸引。有争议的项目会被讨论，出问题的项目会被上报，反而是安静的项目。谁也不会想起它。系统在这里能帮上忙的地方，就是把「安静」本身变成一个信号。

• ● 停滞没有事件，只有时间的流逝
• ● 人的注意力追不上时间的积累
• ● 系统恰好擅长盯住时间

把停滞交给系统识别，还有一个额外好处：它不带情绪。由人来提醒，容易被理解成催促或者不信任；由系统按规则提示，讨论的对象就变成了事实本身。

图1：卡点往往集中出现在某几个环节

二、停滞是怎么发生的

这几类成因的处理方式完全不同。等客户的，需要确认等待是否还有价值；等内部的，需要明确责任人和时间；没有原因的，需要一个正式的结束流程。混在一起处理，往往会用力不均：把可以推动的当成了在等客户，把该结束的又拖着不放。

停滞的成因，大致可以归成几类。

一类是等客户。等对方内部评审、等对方预算周期、等对方决策人回来。这类等待在项目型生意里非常常见，本身不算异常，但如果没有人定期去确认等待是否还有意义。等待就会变成搁置。

一类是等内部。等方案出稿、等审批通过、等资源到位。往实里说，这类等待的责任在公司内部，通常是可以推动的，只是没人明确说这是谁的待办。

还有一类是没有原因。项目实际上是团队判断不再值得投入，但又没有人正式做一个结束的决定，于是它就那样挂着。占用着团队的注意力。

• ● 等客户：需要定期确认等待是否还有价值

区分这两类停滞，有一个简单的判断方法：问一句「如果我们今天想推，能不能推得动」。推得动的属于内部问题，推不动的属于外部等待。回答经常是含糊的，而含糊本身就是一种信息。

• ● 等内部：需要明确责任人

等内部的情况最容易被轻视，因为每个人都会觉得那件事是别人的。等到有人真正去问「这是谁的待办、什么时候给结果」，往往很快就推动起来了。

• ● 没有原因：需要一个体面的结束机制

结束机制经常被忽略，但它很重要，对吧？项目没有正式结束，负责人就始终要分出一部分注意力；团队的资源清单里也一直挂着这件事。一个明确的结束记录，既是对过去的交代，也能让复盘有据可依。

图2：推进慢了，客户感受最直接

三、什么样的停滞值得提醒

提醒的规则还要考虑阶段之间的差异。早期阶段的停滞，可能只是客户还在内部酝酿；后期阶段的停滞，往往意味着已经出现了实质障碍。同样是长时间没有更新，含义完全不同。处理方式也应该不同。

如果把所有没有更新的项目都提醒一遍，提醒很快就会失效。

值得提醒的停滞有两个特征。超过了一个与阶段相匹配的时间。方案阶段停一段时间可能正常，但如果已经进入商务讨论却长时间没有新记录，就很不寻常。重要性足够高。规模大、参与方多的项目，一旦停滞，损失比小项目大得多。值得更早被看见。

把这两条合起来，就可以设计分层的提醒：一般的停滞进入周视图，重要的停滞进入即时提醒。分层的意义在于让提醒保持稀缺，稀缺的提醒才会被认真对待。

• ● 提醒要跟阶段挂钩，不同阶段标准不同
• ● 提醒要跟重要性挂钩，重要的事优先被看见
• ● 分层是为了保持提醒的分量

提醒的呈现方式也影响效果。进入一个需要处理的任务清单，比弹出一个通知更容易被真正对待。说穿了，通知可以被忽略，任务清单会一直挂着。

四、提醒之后要做什么

这三个动作里，最容易漏掉的是第二个。很多人会确认状态，也会在推不动的时候往上报告，但不愿意写下具体的下一步。原因不难理解：写下下一步就等于做了承诺。但没有下一步的项目，其实已经停滞了。

提醒本身不解决任何问题，它只是把注意力引过来。真正有价值的是提醒之后的规定动作。

第一个动作是确认状态。这个项目是真的还在推进，还是已经事实上停滞了？这个判断必须由负责人给出，并且要在系统里记录下来。让下一次提醒有依据。

第二个动作是更新下一步。如果项目要继续，下一个动作是什么、谁负责、什么时候做。写清楚。如果项目要结束，就走结束流程，明确记录原因。

第三个动作是升级。确认之后仍然无法推动的项目，应该被提升到更上一层的视野里，而不是继续在原来的位置上下沉。

• ● 先确认状态，再决定动作

确认状态这个动作本身也有价值：它逼着负责人重新把这个项目看一遍，而不是凭印象判断。看过之后再下的结论，通常更接近事实。

• ● 没有下一步的项目，就等于已经停滞
• ● 推不动的项目要往上走，不能继续下沉

升级不是告状，而是换一个层级来解决问题。有些项目卡住的原因本来就在负责人权限之外，比如需要更高级别的资源投入、需要跨部门协调。这类问题留在一线，只会一直卡着。

图3：现场的问题，会倒推回项目过程

五、让停滞可见带来的变化

还有一个变化出现在跨部门之间。原来方案、商务、交付各自只看得见自己那一段，现在能看到整个项目的状态，也就更容易理解对方为什么慢。沟通时的对立情绪会少一些。

把停滞变成可见的状态，会带来一些意料之外的变化。

第一个变化是团队的注意力分配更合理。原来大家会不自觉地围着声音大的项目转，现在可以把一部分注意力固定放在那些安静但有分量的项目上。第二个变化是汇报更诚实。当停滞会被自动识别时，用「正在推进」来掩盖搁置就变得没有意义。

第三个变化出现在复盘时。复盘过去一段时间的项目，能看到停滞集中出现在哪几个环节，是方案反复、是审批慢，还是客户评审周期长。实话讲，这些结论会直接指向流程改进的位置。

• ● 注意力不再被声音大小左右

这一点在项目多的时候尤其明显。一个负责人手上十几件事，注意力必然被最吵闹的那几件占满。系统性地把安静的项目摆出来，是对人的注意力局限的一种补偿。

• ● 汇报不必再靠形容词

当系统的状态足够可信，汇报里的形容词会自然减少。不需要说进展顺利，只要说项目停在哪个阶段、下一个节点安排在什么时候。

• ● 复盘有了具体的落点

长期来看，这些数据还能反过来修正停滞判定的标准。如果某个阶段的正常时长普遍已经变化，那么原来的提醒阈值就应该跟着调整。标准跟着业务走，提醒才不会被当成噪音。

以海软CRM为例，它的做法是按项目所处的阶段设定停滞判定的时间标准，停滞达到一定程度后在项目视图里直接标出来，并区分重要项目与一般项目的提醒方式。这样处理之后，安静的项目不会因为没人提起就被遗忘。

图4：停滞要能被算出来，不能靠感觉

六、这几个问题问得最多

1、问：项目本来就该等客户，提醒会不会太吵？

答：会，所以要允许负责人主动标注「在等客户」，并设定一个复查的时间点。到点没复查，提醒重新出现。

2、问：提醒应该发给谁？

答：首先发给负责人，迟迟没有动作再往上一层发。直接抄送所有人，会让提醒迅速失去分量。分层发送还有个好处：一线不用天天被提醒淹没。

3、问：停滞判定标准怎么定？

答：按阶段分别定，用历史上的正常推进时长做参考。定得太短会天天报警，太长就失去了意义。

4、问：会不会出现为了躲提醒而乱更新？

答：有可能，所以更新的内容要有实质，比如必须有下一步和责任人，单纯改一个备注不算有效更新。

5、问：停滞提醒对销售是不是一种压力？

答：短期是，长期不是。当团队发现提早暴露问题反而更容易获得支持时，提醒就变成了工具而不是监督。