多部门参与的 B2B 项目怎么推进：分别掌握每个部门的进展
多个部门参与的项目，推进从来不是一条直线。
使用部门的评估已经结束，信息部门的技术确认还没开始，和采购一次都没接触过，预算由谁审批也不知道——这四种情况同时存在。可在 CRM 里，它们只是一行「方案阶段」。
要管好这种项目，需要按决策单元（部门）分别维护进展。具体来说，对每一个参与的部门，都要随时能说出三件事：
- 这个部门关心什么；
- 这个部门哪些已经完成、哪些还没解决；
- 这个部门下一步需要满足什么条件。
下面介绍如何按部门维护进展，以及「单线联系」会让你漏掉什么。
为什么单线联系会出问题
大多数项目都是从一个人开始的。如果这个人很配合，沟通自然就集中在他身上。这也是对他在公司内部角色的尊重。
问题出在这种方式一直延续下去的时候：
- 信息是被转述过来的。 其他部门的顾虑，要经过对接人的理解才传到你这里。「信息部门那边有点意见」这句话背后，往往是一条没人转达的具体要求。
- 讨论发生时你不在场。 公司内部的讨论没有你参与，出现误解也无从澄清。
- 把对接人的热情当成了项目进展。 对接人很支持，和审批流程已经启动，是两回事。
- 对接人一换岗，项目就没了。 关系只系于一个人，接手的人拿不到任何上下文。
这不是说要绕过对接人，而是在维护对接人的同时，也要看清其他部门的状态。很多时候，能帮你打开这条路的，正是对接人（内部支持者）本人。
为每个决策单元分别维护状态
在多部门项目里，要把每个部门当作独立的决策方来看待。
注：以下为说明方法而设的假设案例，不对应任何真实机构。
项目：向一家中型医院销售医疗设备（预计周期 6 到 9 个月）
| 决策单元 | 主要关心 | 当前状态 | 未满足的条件 |
|---|---|---|---|
| 临床科室 / 使用部门 | 与日常工作的契合、使用负担、临床价值 | 设备评估已完成 | 无（支持方） |
| 信息部门 | 院内网络接入、与现有系统的对接 | 正在确认要求 | 对接要求的答复、验证周期 |
| 信息安全 | 是否符合院内标准 | 未接触 | 负责人未明确 |
| 采购部门 | 价格、合同条件、售后 | 已报价，与另外两家比较中 | 售后服务的说明 |
| 财务 | 预算科目、支出时间 | 未接触 | 下一年度预算中如何安排 |
| 院领导 | 投资优先级 | 未接触 | 审批人未明确 |
同一个项目里，并存着已完成、进行中、未接触、未明确四种状态。
关键在于：临床科室评估完成，并不代表项目整体在推进。使用部门的支持是必要条件，但不是充分条件。这个项目能不能往前走，取决于那三个还没接触的部门会发生什么。
至于每个部门里谁才真正有影响力，不在本文范围内，见++如何找到 B2B 项目里真正拍板的人++。
部门状态分四级
实际操作中，粗一点的四级比精细的完成百分比更好用：判断快，也更容易坚持更新。
| 级别 | 定义 | 这一级要做的事 |
|---|---|---|
| 1. 未接触 | 可能参与，但没有任何接触点 | 通过内部支持者找到负责人 |
| 2. 已接触、标准未知 | 知道是谁，但不知道对方按什么判断 | 问清楚这个部门要确认什么、需要什么 |
| 3. 确认中 | 标准已清楚，工作在推进 | 提供所需信息，约定时间 |
| 4. 条件已满足 | 这个部门的判断已经完成 | 记下事实和时间 |
用这个分级，项目状态一句话就能说清：
「临床科室在 4，信息部门在 3，信息安全、财务、院领导都在 1。瓶颈是信息安全的负责人还没找到。」
而只看商机阶段的话，同一个项目的描述就变成「方案阶段，客户反馈不错」。描述有多细，下一步行动就有多准。
「未接触」不要空着
操作上的要点是：在接触之前，就把可能参与的部门全部列出来。
如果只记录已经接触过的部门，这张表看起来永远都很顺利。把预计参与的部门一开始就列上，然后看到某些部门一周又一周停在第 1 级——这才是避免后期意外的办法。
给不同部门提供不同的信息
多部门项目里最常见的低效做法，是把同一套资料发给所有人。
| 部门 | 做判断需要的信息 | 发了也用不上的信息 |
|---|---|---|
| 使用部门 | 与工作流程的契合、操作负担、培训需求 | 合同条件、系统架构图 |
| 信息部门 | 对接要求、配置、与现有环境的兼容性 | 面向终端用户的价值说明 |
| 信息安全 | 是否符合标准、需确认的项目 | 价格、投资回报 |
| 采购 | 价格依据、服务条件、交付周期 | 冗长的技术细节 |
| 财务与领导层 | 投入规模、支出时间、优先级的理由 | 功能清单 |
把整套方案发给每个部门，等于让每个部门都先从里面找属于自己的那部分。这会增加对方的负担，也拉长评审时间。
还要确认一点：这份材料能不能直接给内部支持者拿去在公司内部用。在大多数项目里，向其他部门解释项目的人不是销售，而是内部支持者。一份他能直接转发或引用的材料，能减少审批过程中的阻力。
「方案阶段」背后是什么，你说得清吗
多部门项目难管，是因为表面上的进展很容易和实际脱节。
| 看到的 | 实际的情况 |
|---|---|
| 方案阶段，反馈不错 | 使用部门在 4，其余五个部门在 1 或 2 |
| 评估中 | 在等信息部门确认要求，没有约定时间 |
| 最后阶段 | 内部支持者在准备内部申请，审批人仍未明确 |
说不清楚背后是什么的时候，项目不一定是停住了，而是看不见。这两者要分开处理：前者是行动问题，后者是信息收集问题。
如何区分停滞的原因，见++B2B 商机为什么推不动++。
拓展接触面的实际做法
要接触一个还没打过交道的部门，通常需要内部支持者帮忙。实践中，下面这些做法更容易被接受：
- 把请求说得具体、范围小。 不是「能不能帮我介绍一下信息部门的人」，而是「我想把对接确认清单发过去，发给哪位比较合适？」对方的负担明显更小。
- 维护内部支持者的位置。 把与其他部门沟通的内容同步给他，避免他在自己公司里反而成了最后一个知道的人。
- 把别人要做的事提前做好。 确认清单、技术资料、比较表——把那个部门本来要准备的东西先准备好，能缩短对方的回复时间。
- 按商机记录，不按人记录。 按部门分开记笔记，会失去全局。应该是一个商机里，按时间顺序排列所有部门的跟进，方法见++客户跟进记录怎么写++。
常见的误区
1. 把支持者的数量当成进展。 支持的人再多，审批流程也不会因此前进。支持是必要的，但要和条件是否满足分开计算。
2. 把没提反对的部门当成「没问题」。 没接触过的部门既不支持也不反对——它只是还没做判断。把空白读成「没问题」，要求就会在审批前夕冒出来。
3. 用人名来管理各部门的进展。 人会换岗。以部门和角色为主线、把姓名作为附属信息来管理，才不会因为一次人事调整就丢掉项目的上下文。
在一个商机里看到每个部门 —— VINEQRA 的思路
VINEQRA 是一款面向销售个人的 iOS AI CRM，适合负责周期长、涉及多个关键人的项目的销售。它的设计前提是：商机的进展不是一个阶段，而是多个决策方状态的总和。
它用下面的结构理解一个商机：
跟进记录 + 关键人 + 决策节点 + 卡点 → 下一步最佳行动（Next Best Action）
（VINEQRA Opportunity Context Model）
与多部门管理相关的是：已记录的跟进会与关键人和部门关联，因此可以提示哪些部门没有任何跟进记录，以及哪些条件仍未解决。
在支持的设备与地区，相关 AI 分析可以通过 Apple Foundation Models，在设备端由系统语言模型完成。
一条基本原则：
VINEQRA 负责建议，决定权在销售。
给出的是候选项，不是对各部门会如何行动的预测。
常见问题
参与的部门要列到什么程度？ 所有可能参与审批或实施的部门都列上。多列没有坏处：停在「未接触」的部门，就是你要去确认的清单。
要不要先问对接人「能不能直接联系其他部门」？ 取决于怎么问。请对方告诉你某份材料该发给谁，通常容易被接受；请求直接去谈，则容易引起戒备。比较务实的做法是把目的说得具体、范围小。
不清楚客户内部的组织结构怎么办？ 与其凭猜测画一张组织图，不如从跟进记录里已经出现过的人和部门入手。不知道的就写「未知」，作为下次沟通时要确认的事项。这比空着更稳妥。
部门太多管不过来，从哪里开始？ 从正在拖住当前推进的那个部门开始。不是每个部门都需要同样的跟进频率。在「未接触」的部门里，优先下一个条件所需要的那个。
公司的 CRM 能不能做到这些？ 很多 CRM 都能记录部门和角色。差别在于，能否从已记录的内容里持续看出「哪些部门没接触过」「哪些条件还没满足」。多数情况下，缺的不是字段，而是用法。
按部门说清项目进展
多部门项目要做的，不是和每个人保持同样的联系，而是随时能说出每个部门完成了什么、还剩什么没解决。
VINEQRA 在一个商机里同时保存各部门的关键人和跟进记录，并提示仍未解决的条件。
在一个商机里掌握各部门的进展。 → 前往 App Store 下载 VINEQRA