为什么“找到决策人”经常把复杂采购做简单了
企业采购往往由多人共同完成:业务发起者提出问题,核心使用者评估流程,技术或安全团队判断可接入性,采购与法务核对条件,预算负责人决定资源,最终批准者承担结果。早期咨询人可能最了解痛点,却没有预算权限;职位最高的人也可能并不参与具体评估。
Microsoft Dynamics 365 的公开文档把机会中的客户参与者拆成 stakeholder、decision maker、champion、end user、economic buyer、influencer 和 technical buyer 等角色,并允许记录一次采购是个人决定还是委员会决定。HubSpot 的公开资料也以 Buying Group 组织目标账户中的多位联系人和购买角色。这些产品实践说明:复杂采购需要账户级关系,而不是给单个联系人打一个“高意向”分数。
先建立五类角色,再接受一人多角色
| 采购角色 | 可观察证据 | 适合补齐的问题 | AI不应做的推断 |
|---|---|---|---|
| 业务发起者 | 描述痛点、目标和现有流程 | 这项改变希望解决什么业务结果? | 发起者就是预算批准者 |
| 核心使用者 | 关注日常操作、易用性和培训 | 哪些岗位会实际使用,当前最耗时的环节是什么? | 参加演示的人一定会做最终决定 |
| 技术/风控评估者 | 询问接口、安全、数据、权限和审计 | 后续需要哪些团队评估,材料应交给谁? | 转发给IT的人本人就是技术负责人 |
| 预算负责人 | 关注总成本、预算周期、回报与采购方式 | 预算评估通常在什么阶段、采用什么口径? | 问价格的人已经有预算 |
| 最终批准者 | 确认战略、风险、资源和采购条件 | 最终批准前还需要哪些证据或审查? | 职位最高的人必然拍板 |
角色是项目中的责任,不是固定身份。小型企业中一个人可能兼任多种角色;大型企业中同一角色也可能由多人共同承担。系统需要支持多角色、时间变化和证据更新,而不是只留一个“决策人姓名”。
事实、推断和未知项必须分栏
决策链最常见的错误,不是没有信息,而是把推断写成事实。建议每条角色判断同时保存四个字段:角色候选、原始证据、证据时间、确认状态。
| 客户表达 | 可记录事实 | 仍需确认 |
|---|---|---|
| “我先把方案发给我们IT看看。” | 存在技术评估环节;当前联系人愿意协调 | 技术评估者是谁、关注哪些要求、何时参与 |
| “预算要等总部批。” | 当前联系人不是唯一预算批准者 | 预算周期、总部角色、需要的决策材料 |
| “老板周五一起看演示。” | 一位高层人员将参与演示 | 其决策职责、其他参与者、演示关注点 |
| “使用部门已经认可。” | 客户声称使用部门有正向意见 | 具体人员、适用范围、是否完成正式确认 |
AI可以说“预算批准者尚未确认”“疑似存在技术评估者”,不应自动补出姓名、职位或影响力。关键角色变更、预算确认和批准路径应由销售在会议后复核。
决策链识别的六步法
- 按账户合并:在合法、授权和最小必要范围内,把同一企业的联系人与互动关联起来,保留来源渠道和客户归属。
- 提取明确陈述:从对话、会议纪要和客户提供的材料中提取角色、任务和流程原话,不先做“谁说了算”的结论。
- 分开事实与推断:给每条关系标记已确认、待确认或冲突,并记录最后核查时间。
- 识别角色缺口:检查业务、使用、技术/风控、预算和批准环节是否存在未覆盖节点。
- 用中性问题补齐:询问“后续还需要哪些团队参与评估”“为了方便您内部推进,需要准备哪些材料”,而不是逼问“谁是决策人”。
- 由人工确认下一步:关键会议后更新角色、责任人、材料和时间,决定是否需要客户引荐。
若当前咨询由同事代为转达,可先参考识别“代同事询价”和真实需求人;进入正式机会后,再用本页方法建立多角色决策链。
怎样问,既能补齐角色,又不破坏当前联系人信任
| 目的 | 建议问法 | 应避免 |
|---|---|---|
| 了解使用者 | 除了您,还有哪些岗位会实际使用或受流程影响? | 谁是真正用户?您说了算吗? |
| 了解评估流程 | 后续通常还需要技术、安全、法务或采购中的哪些团队参与? | 请把技术负责人联系方式直接给我 |
| 了解批准路径 | 为了准备内部决策材料,最终批准前通常要完成哪些步骤? | 最后谁拍板?能不能直接找他? |
| 请求引荐 | 如果合适,我可以先整理一页摘要,由您决定是否转给相关同事。 | 我绕过您联系领导会更快 |
好的提问帮助联系人推进内部工作,而不是削弱其位置。客户不愿披露某个人时,可以先记录角色和所需材料,不强求姓名与联系方式。
多人沟通必须有信息边界
把联系人关联到同一账户,不代表所有信息都能互相转述。一个联系人透露的预算范围、对同事的评价、私人联系方式或内部意见,可能只适合特定目的和特定人员。系统应按业务目的、角色权限和客户授权控制可见范围。
- 向新联系人引用历史信息前,确认其身份、项目关系和必要性;
- 内部推断、敏感标签和未经确认的评价不对外转述;
- 跨群聊、私聊、邮件和会议合并上下文时,保留来源与可见范围;
- 外部数据补全需核查来源、准确性、授权与更正机制;
- 不确定是否可共享时,先由销售或数据责任人确认。
《个人信息保护法》要求个人信息处理具有明确、合理目的,与目的直接相关,并采取对个人权益影响最小的方式、限于实现目的的最小范围。本文不构成法律意见,企业还需结合数据来源、合同关系和所在行业评估具体义务。
试点怎么验收:不要用“决策人字段填写率”当成功
| 指标 | 建议口径 | 要防止的假进展 |
|---|---|---|
| 角色证据完整率 | 角色判断带原话、来源和时间的比例 | 只有标签,没有证据 |
| 角色纠正率 | 销售或客户更正AI角色建议的比例 | 把更正隐藏为“模型已更新” |
| 关键缺口发现率 | 在方案、试用或报价前识别未覆盖角色的比例 | 到合同阶段才发现安全或预算负责人 |
| 有效引荐率 | 经当前联系人确认后建立的新角色沟通 | 未经许可的跨层联系 |
| 重复询问率 | 已有证据却再次询问同一角色信息的比例 | 多联系人各自被盘问一遍 |
| 越权共享事件 | 跨联系人披露不必要信息的次数 | 为了推进而牺牲信息边界 |
试点样本应同时包含一人多角色、角色中途更换、总部审批、技术否决、当前联系人拒绝引荐、跨子公司和多渠道沟通。先用历史对话离线回放,再让销售审核角色建议;只有当错误类型和人工负担可控,才扩大自动提示范围。
适用条件与ZigoAI产品边界
本方法更适合客单价较高、周期较长、参与部门较多的B2B交易。单人决策的小额购买无需建立复杂关系图;早期线索信息不足时,保留未知往往比强行建图更可靠。
ZigoAI公开产品页介绍了客户对话承接、信息收集、意向识别、持续跟进和关键节点人工接手等方向,但没有公开承诺本文所述的账户级Buying Group、关系图谱、自动角色推断或跨联系人权限隔离能力。本文是一套实施与选型方法;实际数据模型、渠道、人工确认节点和交付范围应以产品说明、演示、试点和合同为准,公开方案以当前价格页面为准。
采购准备阶段可结合ICP、BANT与证据分级判断机会是否值得推进,再用本页方法检查“还缺哪些角色”,避免把联系人热情误当成组织已完成决策。
常见问题
AI能自动找出最终决策人吗?
不能保证。AI可以根据客户原话、会议参与、资料请求和流程信息提出角色候选,但应保留证据和置信状态,由销售通过客户确认与真实行为核实。
是否应该绕过当前联系人直接找领导?
通常不应默认绕过。更稳妥的做法是让当前联系人说明后续需要哪些团队参与、由谁组织沟通,并获得明确引荐或联系许可。
一个联系人可以有多个采购角色吗?
可以。中小企业中同一人可能同时是使用者、预算负责人和批准者;角色还会随项目阶段变化,因此系统应允许多角色、证据和时间记录。
不同联系人之间的信息可以自动共享吗?
不应默认共享。预算、个人联系方式、评价和内部意见可能具有不同权限。系统应按业务目的、必要范围和客户授权决定可见内容,并在不确定时交由人工确认。
引用来源
- Microsoft:为机会添加利益相关者、决策者和销售团队
- Microsoft:在机会阶段中识别采购流程与利益相关者
- Microsoft:Sales Qualification Agent 的ICP、购买兴趣与BANT概念
- HubSpot:使用Buying Group查看采购参与者
- NIST AI RMF Core:人机角色、责任与监督
- 国家互联网信息办公室:《中华人民共和国个人信息保护法》
- ZigoAI销冠:产品原理
- ZigoAI销冠:公开价格
资料核查于2026年9月26日。Microsoft与HubSpot资料用于说明机会角色、采购委员会和资格判断等公开产品实践;NIST用于说明人机角色与监督的一般原则;个人信息保护法用于说明信息处理的目的和最小范围。它们不代表相应机构对本文方法或ZigoAI作出背书,也不证明ZigoAI具备文中所有账户关系与权限能力。
Map the Buying Group
把“谁参与、凭什么判断、还缺谁”先梳理清楚
带上真实B2B对话、当前CRM字段和销售流程,一起设计可核实的角色证据、缺口提示与人工确认方式。
预约成交诊断