AI销售客户状态怎么设计？用状态驱动下一步动作

先分清标签、状态和待办

“制造业、200人团队、使用企业微信”是属性标签；“等待客户补充需求”“等待销售确认方案”“已明确停止联系”才是流程状态；“周五前回电话”则是待办。三者混在一起，系统就会同时把客户标成高意向、沉睡、待报价和无需跟进，却仍无法选择下一步。

已有的客户标签体系适合描述事实、意向和控制信息；本文关注的是如何把这些证据转成可执行流程。两者应连接，但不应互相替代。

一个可落地的六状态起点

状态名称应对应真实责任和动作。以下模型适合用作试点起点，企业可按业务调整，但不要一开始就拆成几十个细状态。

状态迁移必须同时写清事件、证据和动作

一个可靠迁移可以写成：当前状态 + 新事件 + 证据质量 → 新状态 + 下一步动作。例如，客户主动确认演示时间并给出参与人，可以从“探需中”进入“待人工接手”；仅仅打开资料，通常不足以直接升为高意向。

Microsoft Dynamics 365 的自适应序列会根据邮件互动、电话结果、字段值或业务流程阶段进入不同路径；Up next则区分当前、后续及已完成活动。这些产品实现说明，流程判断与下一动作应一起设计，而不是只更新一个标签。

每次迁移至少记录：

• 旧状态与新状态；
• 触发事件及原始证据定位；
• 事实、推断和未知项；
• 执行主体、发生时间和规则版本；
• 生成的下一步、负责人和截止时间；
• 是否允许人工覆盖、回退或重算。

证据不足时，不要强行给出确定状态

客户问价格，可能是做预算、替同事询价，也可能已经准备采购。先按ICP、BANT与证据分级确认匹配度和购买准备度，再决定是否改变流程状态。

Microsoft 的销售资格智能体概念页把目标客户匹配度、购买意向和 BANT 作为可解释的判断维度，并展示判断理由。企业自己的状态迁移也应保留理由；低置信度时，可以维持原状态、补一个必要问题或交给真人，而不是为了填满字段而猜测。

建议把证据至少分为“客户明确确认、系统事件、人工确认、模型推断、未知”五类。只有模型推断时，应在前台和后台都避免把它写成客户承诺。

超时动作取决于正在等待谁

进入“待人工接手”后，还要配合线索路由与接手SLA和人工接手完整度评分：前者确定多久由谁接，后者检查交接信息是否足以行动。

新事实与旧状态冲突时怎么处理

客户昨天说“下月再联系”，今天主动要求报价，新事件应触发复核；但不能直接删除昨天的记录。建议保留时间线，用最新、明确、来源可靠的事实决定当前动作，同时记录谁改了状态以及为什么。

人工覆盖也不能静默发生。销售可以纠正模型，但应选择原因，例如“客户已电话确认”“系统识别错误”“项目拆分”或“状态过期”。这些原因会成为后续评测和规则改进的样本。

NIST AI RMF强调治理、测量和持续管理风险。用于销售流程时，一个实用落点就是保留决策依据、人工监督、反馈和变更记录，避免无法解释的自动迁移长期累积。

从20段真实对话开始，而不是先画一张大流程图

1. 抽取最近20—30段脱敏对话，标出每段“现在轮到谁做什么”；
2. 合并同义状态，先控制在5—8个主状态；
3. 为每个状态写进入证据、允许动作、禁止动作和退出条件；
4. 把人工接手、明确拒绝和关键承诺设为高优先级规则；
5. 影子运行，比较AI建议状态与销售判断，不立即自动执行高影响动作；
6. 按误迁移、漏迁移、重复触达和人工覆盖原因每周校准。

验收时不要只看状态字段是否变化，还要看下一步是否生成、负责人是否明确、禁止动作是否生效、超时后是否按责任方处理。

如何用于ZigoAI销冠试点

ZigoAI官网公开说明，系统会结合客户阶段、历史沟通和企业销售策略判断回复、追问、跟进或转交，并记录任务执行状态。企业可用本文框架定义自己的主状态、证据和边界，再用真实对话逐项验证。

本文的六状态、迁移审计字段、回退规则和CRM映射属于实施建议，不代表ZigoAI已经提供通用、可视化的状态机编辑器或所有自动迁移能力。正式范围应以演示、试点和合同确认为准。

常见问题

一个客户能同时有多个销售状态吗？

建议同一产品或商机只有一个主流程状态，但可以同时拥有多个标签、待办和原因码。若客户涉及多个独立项目，应分别管理各项目状态。

客户状态多久更新一次？

有可靠事件时应及时更新，例如客户回复、资料补齐、真人认领或明确拒绝。定期批量复核可以发现过期状态，但不能替代关键事件后的即时变更。

AI判断客户状态错误怎么办？

保留人工纠正入口、原始证据和修改原因。影响报价、停止联系或人工接手的高影响迁移，应允许人工确认或覆盖，并把错误样本加入后续评测。

CRM销售阶段可以直接当作AI对话状态吗？

可以建立映射，但通常不能直接等同。CRM阶段往往较粗，AI对话状态还要说明正在等待什么、由谁行动、允许做什么以及何时超时。