将多个 AI 观点转化为客户提案

决定提案需要实现什么目标

初次会议的演示文稿，与等待批准的正式提案，目的并不相同。前者帮助澄清问题并就前期调研达成一致；后者明确范围、责任、价格和验收条件。请在需求说明中写清交易所处阶段，避免草稿作出超出已商定内容的承诺。

描述接收者、他们的决定以及他们已经知道的内容。企业主可能正在选择下一步，而运营主管则检查员工是否可以支持实施。这种区别决定了哪些反对意见值得关注以及哪些内容属于幻灯片。

工作场景：代理机构审核丢失的入站请求

想象一下，由于一些查询丢失，客户要求代理机构实施新的 CRM。源材料包括流程图和错过的请求的示例。它没有确定损失是否发生在工作人员交接、数据输入或后续过程中。这是一个假设的工作流程，而不是 Colay 客户故事。

最初的提案可能直接进入系统实施。审阅可能发现，更换系统尚无充分依据，真正的问题可能是职责不清。一次有用的讨论会建议先检查流程、验证原因，再商定实施范围。如果证据支持更换系统，就应得出不同建议。

将推理带入演示中：已知的内容、第一阶段解决的不确定性以及支持下一个决策的内容。对新系统的完美描述并不能建立这种联系。

从多个角度查看需求说明

这些是根据提示建议的任务，而不是内置的认证专家小组。使用Ask separately来获取个人的初始回复。提供相同的需求说明并确定客户证据在哪里结束以及您的假设从哪里开始。

要获得共同结论，请向 Consensus 明确提供需求说明、相关摘录和审阅笔记。单独的聊天不会自动成为新请求的来源。请要求讨论保留现有证据无法解决的分歧。

• 解决方案设计师：哪个工作顺序可以解决客户的问题。
• 质疑者：哪些声明缺乏支持以及哪些依赖项缺失。
• 接收者的观点：在批准之前需要澄清什么。
• 编辑：如何将审阅的结果转化为简洁的文档。

将承诺转化为团队可以验证的条件

不要仅仅为了填充幻灯片而将未知数变成有把握的数字。负责团队必须确认估计、日期和承诺。当某个值未解决时，在工作草案中留下问题；在客户端版本中，明确说明条件或删除不支持的承诺。

结论和演示的提示

“使用这份需求说明 [证据] 和审阅笔记 [摘录]，为处于 [初次会议或范围审批] 阶段的 [接收者] 准备提案。区分事实和假设。检查每项建议活动是否针对客户的问题。不要编造团队经验、客户评价、价格、日期或绩效提升。列出需要人工确认的争议条件。然后制作 HTML 演示文稿，涵盖：客户问题；已确认的观察结果；备选方案及推荐方法；工作范围及不包含的内容；依赖条件与验收条件；下一步。”

首先回顾一下实质性结论。在最终演示工作之前解决范围或条件的变化。 Colay 的默认Consensus请求包含基于结论的 HTML 演示，但请检查生成的结果：模型可能会忽略要求或表现不佳。

准备一个可以在会议中使用的版本

从收件人的角度阅读每张幻灯片。如果没有口头解释，该提案是否有意义？范围是否明确？压缩是否消除了一个重要条件？检查名称、数字、链接和表格的可读性。删除不适合客户的内部注释。

在需要时导出审阅的演示文稿。 Colay 当前的 PPTX 导出将幻灯片保留为图像；单个标签不是可编辑的 PowerPoint 文本对象。如果您需要更改幻灯片文本，请在导出之前进行更改或套餐进行其他编辑。

通过您花在修改上的时间以及您可以同意的条件的清晰度来评估工作流程。此场景并未建立准备时间基准或销售改进。考虑积分和重复生成。从一份匿名需求说明和一份团队不同意的提案部分开始。