企业客户评审会后的方案交付闭环

背景

在复杂 B2B 销售中，客户评审会通常不是一次简单的产品介绍。客户会围绕业务价值、部署范围、系统接口、实施计划和责任边界提出连续问题。会议中的一个口头决定，往往同时影响销售方案、技术说明、交付排期和后续沟通。

本案例聚焦一种典型情境：客户在评审会上要求供应方补充 ROI 逻辑与分阶段部署计划，并希望在下一次沟通前收到更新方案。相关信息分散在本次会议、历史版本、合同约束、产品资料和内部讨论中。会议结束并不意味着方案已经可以制作；团队还要重新确认需求、收集证据、协调执行者、形成草稿、审批并回写状态。

挑战

口头要求存在模糊指代。 “按照上次说的范围”“把投入产出再讲清楚”对参会者可能明确，对系统却缺少可直接执行的对象与标准。

证据散落在不同位置。 客户当前版本、部署约束、产品能力说明和测算假设可能分别存在于会议记录、文档和业务系统中，且访问权限不同。

专业执行跨越多个角色。 销售负责客户表达，产品或交付团队确认能力边界，分析或文档工作流形成材料，负责人承担外发责任。任何单一通用 Agent 都不应默认替代这些角色。

完成状态容易被提前定义。 创建一条“更新方案”的任务不等于方案可用；生成一份文档也不等于内容已经获得业务负责人批准。

Stay 的介入方式

Stay 面向这条流程提供上游语音入口与软件链路。会议采集端在符合客户授权策略的前提下保留必要对话上下文；语音戒指可用于负责人会后的主动补充指令。Stay 随后尝试消解指代，组织当前任务所需的上下文，并形成包含目标、证据、约束和完成标准的 Context Pack。

Context Pack 被路由至客户已经选定的分析、文档或业务工作流。下游负责专业生成；Stay 不把“写出方案”描述为单一模型自动完成的能力。成果进入既定审批流程后，确认版本与任务状态可回到客户允许连接的文档、CRM 或项目系统。

端到端流程

01｜Capture：记录明确的业务意图

系统从获得授权的评审会中识别客户要求与责任约定，并保留与当前任务相关的时间点和说话人。无授权、无关或敏感片段不应默认进入后续流程。

02｜Resolve：确认“哪件事”

将“上次范围”“ROI”“部署计划”等表达关联到对应客户、会议、方案版本和待确认事项。若存在多个候选对象或证据冲突，流程暂停并请求负责人确认。

03｜Ground：定义交付目标

把口头要求转化为明确的交付结构，例如需要补充的测算假设、数据来源、实施阶段、前置条件与不在承诺范围内的事项。完成标准被定义为“可供负责人评审的方案草稿”，而不是“已对客户发送”。

04｜Package：形成 Context Pack

在调用者权限范围内，汇集会议证据、当前方案、批准使用的产品资料和合同约束。每项关键事实保留来源；缺失数据被标记为待确认，不由模型自行补全。

05｜Route：交给匹配的执行系统

测算部分可进入客户认可的分析流程，文档部分可进入已有的文档 Agent 或模板工作流，CRM 状态更新则使用受限的业务系统连接。不同执行者只获得完成各自步骤需要的最小信息与工具权限。

06｜Approve：负责人确认

方案草稿与跟进邮件在外发前由指定负责人审阅。审批视图应展示客户原始要求、引用证据、关键假设和拟发送内容；修改意见保留为任务事件。

07｜Return：成果与状态回传

经确认的版本存入客户指定位置，CRM 或项目系统只回写允许的状态字段。是否发送给客户仍由企业的审批与外发策略决定。采用、修改或退回状态为下一次上下文与路由评估提供反馈。

可验证的结果口径

在没有部署日志与客户授权前，本案例不宣称具体改善数字。正式验证应同时保留基线流程，并从以下维度比较：

| 维度 | 建议指标 | 证据来源 | |---|---|---| | 周期 | 评审会结束至首个可评审方案版本的时间 | 会议时间戳、文档版本记录、审批记录 | | 搬运 | 人工查找、复制和重新解释背景的步骤数 | 流程观察、任务事件、用户访谈 | | 理解 | 指代确认正确率、上下文缺失率、澄清比例 | Context Pack 评审、异常分类 | | 路由 | 下游工作流启动成功率、失败与回退类型 | 路由和工具调用事件 | | 成果 | 负责人修改范围、审批通过率、采用或退回状态 | 文档差异、审批与采用记录 | | 治理 | 越权读取、绕过审批、错误回写事件 | 权限与审计日志 |

这些指标需要按同一任务定义、同一时间范围和相同参与角色进行比较。效率提升不能只依赖主观感受；成果质量也不能只以文档是否生成来判断。

部署边界

采集边界：会议采集需符合企业政策和适用规则，并提供可见状态、暂停与删除机制。 数据边界：只读取当前调用者有权访问且完成任务必要的数据；不同租户的数据不得混用。 能力边界：Stay 负责意图理解、上下文组织、路由与状态追踪；专业分析和文档生成由客户选择的下游 Agent / 工作流承担。 动作边界：客户外发、价格承诺、合同修改和关键系统写入默认需要企业定义的审批。 结果边界：任何周期、质量或业务效果结论，都应在真实部署后由双方约定口径并基于日志验证。

下一步

这类闭环的价值不在于让一场会议生成更多文字，而在于让客户要求更早进入可控的执行流程，并让每个关键判断都有证据、责任人与状态。

Case Study CTA 如果您的团队也在客户会议后反复查找背景、重写方案和更新系统，欢迎带一条真实流程与 Stay 讨论。我们会从权限、输入、上下文、执行者和验收标准开始，而不是从“全自动”承诺开始。