信息散在三方手里拼不出客户全貌，CRM项目空间才是真正的汇合处
信息散在三方手里拼不出客户全貌，CRM项目空间才是汇合处
一、协作难的根子在信息分布
信息分布还有一个副作用：它让每个人都倾向于从自己掌握的信息出发做判断，并且真诚地认为自己看到的就是全貌。销售觉得客户马上要签，因为他刚被热情接待；方案觉得客户还在犹豫，因为他刚被问了几个难题。两边都没错，只是各自看到的都只是一部分。
项目型销售里，几乎所有的协作问题最终都能追溯到同一件事：信息分布在不同的人手里。
销售掌握客户关系的进展，知道谁支持、谁有顾虑、下一步该约谁；方案人员掌握技术侧的判断，知道客户的哪些要求能满足、哪些需要取舍；商务和交付掌握条件与履约的安排，知道成本边界在哪里、交付上有什么限制。三方手里各有一部分事实，但没有一个人手里是完整的。
这种分布本身不是问题，问题是缺乏一个把三方信息汇到一起的地方。于是协作就变成了不停地互相问：「客户那边有消息吗」「方案改好了吗」「那个条件能不能让」。每一次问都是一次中断，每一次回答都可能遗漏一部分。
- ● 信息分布是天然状态，不是谁的失误
- ● 缺的是汇合的地方，不是沟通的意愿
所以解决协作问题的方向，不是要求大家沟通得更多，而是给信息一个固定的落点。沟通频次可以提高，但如果每次的内容都散落在不同的通道里，协作质量并不会改善，只会让人更疲惫。
- ● 靠互相追问来同步，成本会随时间累积
追问的成本不只是时间。每一次追问都意味着一次中断，被打断的人要重新进入状态；追问的次数多了，人还会本能地少说一点，避免被反复问。信息质量因此进一步下降，形成循环。
图1：一个项目多人参与，信息要合在一处
二、项目空间里该放什么
这四类内容的写法不同。摊开讲，事实类用陈述句，产出物用文件，讨论用记录。约定用条目。混在一起写，读的人分不清哪句是已确认的事实、哪句是还在讨论的猜测。项目空间的可用性会大幅下降。
把三方信息汇到一起，需要一个明确的空间。空间里放的东西要有讲究。
第一类放事实。客户方的参与角色分别是谁、各自的立场如何、最近一次接触发生了什么，这些是判断的基础。必须集中存放。第二类放产出物。方案的第几版、报价的依据、交付的安排，这些东西版本容易乱。必须有一个固定位置按版本存放。
第三类放讨论。项目推进过程中会有大量讨论，散在各个群里的话事后找不回来。集中放在项目里就留下了痕迹。第四类放约定。谁负责什么、什么时候要交付什么，这类约定写下来才算数。
- ● 事实类信息让所有人站在同一个起点
实践中，项目空间最容易缺的恰恰是事实类信息。产出物和讨论一般都会有人管，而客户方有几个人参与、各自什么态度这类内容。常常只留在销售个人脑子里。恰恰是这类信息，决定了其他人判断的起点。
- ● 产出物按版本存放，避免拿错版本
版本管理还带来一个附带好处：它能看出一个项目的反复程度。方案改了很多版才定下来，说明前期判断有反复。这类项目值得在复盘时多看两眼。
- ● 讨论与约定留下来，事后才有据可查
还有一个细节：项目空间里的内容要有主次。关键结论、当前待办、未解决的分歧。应该比日常讨论更容易被看到。否则信息越积越多，接手的人反而不知道该从哪看起。
图2：外部伙伴也要能进同一个空间
三、外部伙伴怎么进来
外部伙伴的参与还有一个管理上的好处：他们的视角往往和内部不一样。渠道更了解当地客户的采购习惯，服务商更了解实施中的实际困难。把这些视角留在项目记录里，后续同类项目的判断会更全面。
项目型生意里，参与方不一定都在公司内部。
有的项目需要渠道伙伴一起推进，有的需要原厂或上游供应商配合。有的需要第三方服务商参与实施。这些外部角色如果被排除在项目空间之外，协作就会重新退回到打电话、发消息的状态，而他们恰恰又掌握着部分关键信息。
做法上有两种选择。简单说，一种是把外部伙伴纳入项目空间，给他们只看相关内容的权限；另一种是在项目里为外部协作单独开一块区域，把需要共享的部分同步过去，内部讨论仍然留在内部。两种做法各有适用场景，关键是不要因为「是外部的人」就把协作默认放在系统之外。
- ● 外部角色掌握的信息同样关键
- ● 用权限区分可见范围，而不是用系统内外区分
- ● 需要共享的部分要能同步过去
- ● 内部讨论仍然可以留在内部
无论选哪一种方式，有一条底线要守住：同一件事不要出现两份互相矛盾的记录。外部看到的内容可以从内部同步过去，但不要各自维护一份，否则一旦对不上，反而会增加解释成本。
四、协作靠什么维持下去
这三件事背后其实是同一个逻辑：让维护项目空间这件事对参与方自身有利。只强调公司要求，参与方会把它当成作业；当它确实减少了被追问、减少了返工，习惯才养得成。
把三方放进同一个空间，只是开始。真正难的是让这件事长期维持。
维持靠的是三件事。第一件是让空间里的信息对每一方都有用。如果只有管理者看得到价值，其他人就会把它当成额外的填报负担。第二件是让更新变得顺手。如果记录一次要切换好几个页面，人就会退回到最省事的方式。
第三件是让不更新有代价。项目停滞久了会被提醒，节点到期没完成会被标出来。这些反馈本身就是维持的力量。
- ● 对每一方都有用，才有人愿意维护
- ● 记录顺手，习惯才养得成
判断顺手与否，有一个很朴素的标准：填一条记录要不要先想一下该填到哪里。如果需要想一下，说明结构还不清楚；如果不用想，说明分类已经符合人的直觉。
- ● 停滞会被看见，更新才有压力
还有一点容易被忽略：项目空间需要有人定期整理。不是每一次讨论都值得留下，重复的、无关的内容积累多了。空间就会变得不可读。指定一个人负责阶段性梳理，比完全放任自然堆积更有效。
图3：交付阶段的动作，同样要留在系统里
五、让经验留在项目里
经验的留存还有一个现实意义：项目型生意的人才培养周期很长。新人从参与到独立负责一个项目，往往需要跟过好几个完整的项目。如果有记录可查，这个周期可以明显缩短。
项目空间还有一个容易被忽略的价值：它把经验留了下来。
一个项目做完了，为什么赢的、哪里差点输掉、哪个环节本来可以更快，这些问题的答案如果只存在参与者的记忆里，过一段时间就模糊了。说到底，等到接手同类项目时，团队只能重新摸索。
把答案留在项目里，效果完全不同。新项目开始时，可以翻看同类项目当年的方案、当时遇到的阻力、最终是怎么化解的。这份材料比任何培训都具体，而且它不会随着人员流动而消失。
- ● 项目结束不代表记录失去价值
- ● 同类项目的记录是最好的参考
- ● 经验留在系统里，才不随人走
在使用这些记录时，有一点要注意：同类项目之间的可比性。客户类型不同、规模不同的项目，直接照搬方案并不合适。记录的价值在于提供思考的起点，而不是提供现成的答案。
图4：交付涉及物料，账目要能对得上
以海软CRM为例，它的做法是把项目文档、讨论记录、参与角色和关键节点都归在同一个项目之下，项目结束后这份记录依然可以被后续项目引用。这样处理之后，团队积累的不再是零散的个人经验，而是一份可以被翻阅的项目档案。
六、常见疑问集中回应
1、问：三方都往里面记，会不会重复？
答：各记各的部分，重复的可能性不大。真正需要约定的是边界，哪些内容由谁负责维护，提前说清楚。
2、问：方案文档版本很多，怎么管理？
答：按版本存放，并且标明每一版的结论和待确认项。关键不是存了多少版，而是任何时刻都知道当前生效的是哪一版。
3、问：外部伙伴不愿意用我们的系统怎么办？
答：不必强求。可以内部先用起来，把需要共享的内容按约定同步给对方。协作用什么工具可以不同，信息来源尽量统一。
4、问：项目空间会不会变成聊天群？
答：只要结构在，就不会。事实、产出物、讨论、约定分开存放，讨论不会淹没关键信息。
5、问：怎么判断协作真的改善了？
答：看两件事：重复询问的次数是不是在减少，以及项目交接时接手方需要追问的信息是不是在变少。
