为什么CRM同一件事要记录两个时间？“计划时间”和“实际时间”不能混着用

预计拜访日期、实际拜访日期，预计签约时间、实际签约时间，计划交付时间、实际完成时间。很多企业刚开始设计CRM时觉得两个时间字段太重复，只保留一个日期。但当管理者想知道“到底延迟了多久”时，才发现原来的计划已经被实际日期覆盖。

一个项目原计划10月1日交付。

实际到了10月15日才完成。

如果系统里只有一个“交付日期”，员工最终把它改成10月15日，那么系统只能告诉你项目什么时候完成，却无法再告诉你它原本计划什么时候完成。

两个看起来重复的时间字段，实际上回答的是两个完全不同的问题。

计划时间和实际时间分别解决什么问题？

计划时间描述的是业务当时的预期。

实际时间描述的是事情最终真正发生的时间。

只有两者同时存在，企业才能继续判断计划是否准确。

为什么不能事情延期以后直接修改计划日期？

这是很多系统数据看起来永远“准时”的原因之一。

原计划10月1日，没有完成，于是把计划日期改成10月8日；10月8日还没有完成，又改成10月15日。

最终项目10月15日完成，系统里显示：

数据看起来完全准时，但最初其实已经延期了14天。

计划发生变化以后应该怎么办？

真实业务中，计划当然允许调整。

关键是企业是否需要保留原计划，以及知道计划为什么改变。

对重要业务节点，保留计划变化历史，可以帮助企业区分正常调整和长期反复延期。

哪些CRM业务适合同时记录计划时间和实际时间？

不是所有日期都需要成对出现，但涉及执行效率和时间承诺的关键节点非常适合。

企业可以根据自身真正需要分析的业务节点进行选择，不需要机械地给所有字段都增加一组时间。

计划和实际时间可以帮助企业分析什么？

两组时间最直接的价值，就是能够计算偏差。

这些问题无法只靠一个最终日期回答。

“预计时间”最大的价值，不是提醒，而是事后能够验证

很多企业记录预计成交日期，只是为了让销售漏斗看起来完整。

但如果最终从来不把预计日期和实际结果放在一起比较，企业就很难知道自己的计划能力到底准不准。

当计划时间、实际时间和计划调整历史能够同时被保留以后，CRM记录的就不再只是“什么时候发生了”，还能够回答“我们原来是怎么判断的，以及最终偏差了多少”。