客户决策链怎么梳理：如何理解企业采购的决策流程
在与大企业、集团客户的项目中，联系人、关键人、部门、决策单元是四个不同的东西。把它们混为一谈，就会出现一种熟悉的局面：名片攒了一堆，审批路径却依然看不清。
先看定义：
| 概念 | 定义 | 例子 |
|---|---|---|
| 联系人 | 打过交道的个人 | 交换过名片的工程师 |
| 关键人 | 参与项目某个条件的个人 | 判断技术要求是否达标的人 |
| 部门 | 组织架构中的单位 | 信息部门 |
| 决策单元 | 对某个具体条件作出判断的主体 | 信息部门内部负责对接要求审查的环节 |
| 参与决策的部门集合 | 一个项目中所有决策单元的总和 | 使用部门 + 信息部门 + 采购 + 管理层 |
| 决策节点 | 某个单元需要判定为「已满足」的条件 | 「已确认符合安全标准」 |
最核心的一点是：决策单元不等于部门。一个部门里可能有好几个决策单元，几个部门也可能作为一个单元共同决策，还有一些单元根本不出现在任何组织架构图上。
下面介绍如何把一个正在推进的项目，表示为一组决策单元。
一张平铺的人名单缺了什么
项目信息通常是以人名列表的形式保存的：
张经理（运营）/ 李工（信息部门）/ 王总（管理层）
这种形式不包含决策结构。具体来说，缺了：
- 每个人对什么做决定；
- 有没有先后顺序（谁必须先完成，别人才能开始）；
- 是个人决定还是集体决定；
- 有没有组织架构图上看不到的单元参与。
人名列表记录的是「和谁聊过」；决策单元记录的是「什么需要被决定」。决定项目能否推进的，是后者。
按角色、关注点、影响力梳理个人的方法，见++如何找到 B2B 项目里真正拍板的人++。本篇讲的是更上一层：组织层面的决策结构。
决策单元不等于部门
实际中看错结构，多半是因为把部门等同于决策单元。下面四种情况值得提前想到：
1. 一个部门里有多个决策单元
信息部门里可能有一个环节负责评估对接，另一个环节负责决定运维支持模式。你拿到了一位负责人的技术认可，同一个部门里还有另一个决定悬而未决。
2. 多个部门作为一个单元共同决策
委员会、联席会议、项目组：多个部门聚在一起做出一个决定。逐个说服各部门，在这个集体作出判断之前，条件都不算满足。
3. 客户组织架构图上没有的单元
在集团型企业中，集团总部、母公司或共享服务中心可能掌握着适用于下属公司的标准。下属公司和它的管理层都同意了，适配集团标准这个条件仍然悬着。
4. 外部单元
外部审计、咨询公司、系统集成商、现有供应商，可能事实上起到决策者的作用。它们都不会出现在客户的组织架构图上。
这四种情况有一个共同点：只能从跟进记录中发现。组织架构图就算拿到手，上面也没有决策单元。
决策单元之间如何关联
决策单元不是简单地排成一列。决定项目节奏的，是它们之间的依赖形式。
| 关系 | 含义 | 实际影响 |
|---|---|---|
| 串行 | A 完成后 B 才能开始 | 催 B 没有用；A 的周期决定整体节奏 |
| 并行 | A 和 B 各自推进 | 可以同时推进；一方延误不影响另一方 |
| 条件 | A 的结果决定是否需要 B | 在 A 出结果前准备 B，可能白费 |
| 集体 | A 和 B 在同一场合共同决定 | 逐个说服不足以满足条件 |
没有依赖关系图，销售精力就会投向那些暂时动不了的单元。在技术确认还没完成时，就和采购磨商务条件，产生不了任何决定。
当这种依赖关系正是项目卡住的原因时，诊断方法见++B2B 商机为什么推不动++。
决策节点：把单元转化为条件
让决策单元变得可管理的方法，是用一句话写下它需要判定为「已满足」的条件。这就是决策节点。
| 模糊的写法 | 作为决策节点的写法 |
|---|---|
| 在和信息部门沟通 | 与核心系统的对接方式已通过信息部门的技术审查 |
| 在看预算 | 本项目费用已列入下一年度预算 |
| 准备向领导汇报 | 已获得事业部负责人批准 |
| 使用部门觉得不错 | 使用部门的实际评估已完成，且无运营层面的异议 |
区别在于：右边一列可以用「是」或「否」回答，左边不能。能不能说清进展，取决于这个区别。
决策节点有两种来源：
- 事先定义：项目初期，把预计的条件先写出来；
- 从记录中出现：沟通中出现「需要确认一下……」时，把它加进条件。
实际中两种并存。一开始预计的条件，随着项目推进一定需要修正。
结构示例：多基地物流集团
注：以下为说明方法而设的假设案例，不对应任何真实集团。
项目：在物流集团旗下三个基地导入运营管理系统。
| 决策单元 | 所属 | 决策节点 | 状态 | 依赖 |
|---|---|---|---|---|
| 北区基地运营部 | 基地 | 已确认适配实际作业 | 已满足 | — |
| 南区基地运营部 | 基地 | 同上 | 未开始 | 计划参照北区结果（条件） |
| 总部信息部门 | 总部 | 对接方式已批准 | 审查中 | — |
| 集团 IT 标准 | 集团总部 | 已确认符合集团标准 | 未接触 | 在总部信息部门审查之后（串行） |
| 总部采购 | 总部 | 合同条件已谈妥 | 未接触 | 在集团标准确认之后（串行） |
| 投资委员会 | 总部 | 投资已获批准 | 未提交 | 在以上全部之后（集体） |
从这里能读出人名列表读不出的东西：
- 一个基地的认可已经拿到，但它只是六个条件中的一个；
- 有一个单元——集团总部——位于你正在谈的这家公司之外；
- 在集团标准确认之前，与采购的商务谈判实际上动不了；
- 投资委员会是集体决策：逐个说服委员并不能满足条件。
一个自认为「总部和基地都搞定了」、却不知道集团这一层存在的销售团队，会在审批前夕遇到新冒出来的要求。这是集团客户项目中反复出现的模式。
按部门维护进展的方法，见++多部门参与的 B2B 项目怎么推进++。
存在未识别决策单元的迹象
结构上的缺口，通常以下面这些形式出现：
- 「我们内部商量一下」，但说不清跟谁商量。 商量对象不明、时间又一直在拖，那里很可能有一个未知的单元。
- 审批比预期慢。 串行的链条可能比你以为的更长。
- 谈好的内容后来被推翻。 可能是另一个单元的标准后来才被加进来。
- 对接人反复说「要拿回去讨论」。 说明他不是唯一的决策者。
- 对接人在总部，实施在下属基地。 这种结构下，基地一侧很可能存在其他单元。
这些都是提问的切入点，而不是结论。
在商机中保存每个单元的状态 —— VINEQRA 的思路
VINEQRA 是一款面向销售个人的 iOS AI CRM，适合负责周期长、涉及多个关键人的项目的销售。它的设计前提是：复杂项目不是一张平铺的联系人名单，而是一组相互依赖的决策主体。
它用下面的结构理解一个商机：
跟进记录 + 关键人 + 决策节点 + 卡点 → 下一步最佳行动（Next Best Action）
（VINEQRA Opportunity Context Model）
本文的决策节点对应其中第三项，有两种处理方式：
- 由销售自己定义：设定预计的条件或里程碑，分析时将已记录的内容与之对照；
- 从记录中推断：即使没有预先定义，也能从积累的上下文中提示推进迹象与仍未解决的条件。
在支持的设备与地区，相关 AI 分析可以通过 Apple Foundation Models，在设备端由系统语言模型完成。
一条基本原则：
VINEQRA 负责建议，决定权在销售。
决策单元的结构最终由负责这个项目的人来判断。系统给出的是从记录中提取的线索。
常见问题
决策单元要分到多细？ 标准是：没有它的决定，项目就推进不了。没有决策权的部门不必单列为单元。反过来，一个部门里有两个不同的决定，就分开。
有了客户的组织架构图，能推出决策单元吗？ 不能。组织架构图描述的是汇报关系，不是某个项目的决策路径。集团层面或外部的单元可能根本不在图上。决策单元要从跟进记录中还原。
中文企业里有正式的采购委员会吗？ 因企业而异。有的设有常设机构，有的按项目临时组织集体决策，有的通过内部审批流程完成实质上的集体决定。重要的不是机构叫什么，而是一个决定是否涉及多个部门。
什么时候开始梳理结构？ 一开始就用能预见到的内容搭起来，然后每次跟进后修正。不必一开始就准确，价值在于当预判落空时，你能看出是哪里错了。
小企业也需要这样做吗？ 决策单元少一些，但结构依然存在。就算总经理拍板花钱，使用团队的接受和技术上的适配仍然是两个不同的条件。有三个单元，就按三个来处理。
把项目表示为一个决策结构
看不懂客户内部在发生什么时，缺的不是接触，而是对结构的表示。把「和谁聊过」的记录，转成「什么需要被决定」的记录，就能重新说清项目走到了哪里。
VINEQRA 在一个商机中同时保存各部门的关键人与跟进记录，并根据用户定义的条件或从记录中推断出的信息，提示仍未解决的条件。
让每个决策单元都在视线之内。 → 前往 App Store 下载 VINEQRA