销售通话之后往往还有一串重复工作：整理记录、提取行动项、更新 CRM、创建任务并准备跟进内容。AI 可以协助处理非结构化文本，Make 则负责连接系统、执行确定性规则和保留运行状态。两者结合时，重点不是让模型自行决定销售动作，而是把每一步的输入、权限和复核责任设计清楚。
本文以 MeetGeek 或同类会议工具提供的通话记录为输入，介绍一种可复用的工作流。具体模块、事件字段和 AI 能力取决于当前账户与连接器，实施时应先查看真实样本，不应直接照搬字段名称。
定义自动化边界
在录制或处理通话之前，先确认参与者知情、录制依据、数据保留期限和可访问人员。通话文本可能包含个人信息、商业机密或敏感判断，应先按组织政策确定哪些内容可以进入 AI 服务和 CRM。
为输出定义一个窄而稳定的结构，例如：
不要让模型从模糊对话中生成未经确认的预算、购买意向或联系人事实。无法从记录中确认的信息应返回空值或“待复核”。
构建场景主线
1. 接收会议完成事件
当会议工具完成处理后，可通过其当前可用的 Make 模块或 Webhook 启动场景。首先验证事件来源，并用会议标识建立幂等键。重复事件应更新同一处理记录，而不是重复创建联系人、任务或商机。
如果事件只包含记录地址，应通过经过授权的连接下载内容。不要把长期有效的访问地址写进普通日志。下载失败、记录仍在处理或权限不足时，应进入等待或人工处理分支。
2. 规范化通话数据
把说话人、时间戳、正文和已有会议摘要整理成统一结构。保留原始记录引用，以便复核，但只把任务所需的最小文本发送到后续步骤。
在调用 AI 前进行基础校验：记录是否完整、语言是否可识别、联系人是否可关联、是否包含禁止处理的字段。过短、缺失或不符合政策的记录不应继续自动分析。
3. 提取结构化结果
可以使用 Make 中当前可用的 AI 模块或智能体，从通话文本中提取行动项、问题和跟进草稿。提示应要求固定字段，并约束模型：
随后用确定性模块检查必填字段、日期格式和允许值。结构校验失败时，不要把原始模型文本直接写入 CRM。
4. 人工复核关键动作
模型可以生成建议，但涉及客户承诺、商机阶段、价格条件、合规风险或外发内容时，应先进入人工复核。复核界面可以是受控表格、任务系统或 CRM 队列，并显示原文依据、建议值和修改入口。
只有复核通过的字段才能进入写入分支。被拒绝或修改的结果也应留下状态，便于以后评估提示和规则，而不是把人工反馈当作新的客户事实自动扩散。
5. 幂等更新 CRM
写入前先按可信的外部标识查找联系人和会议记录。若无法唯一匹配，应创建人工核对任务，而不是仅凭姓名猜测联系人。更新时只修改本场景负责的字段，并保存来源会议标识与处理时间。
创建任务或后续步骤时，明确负责人和截止时间。对可能重复执行的模块使用幂等键或“查找后更新”模式，防止重试产生多个任务或商机。
6. 准备跟进草稿
AI 可以根据已复核的行动项起草邮件，但默认先保存为草稿或任务附件。发送前由负责人检查收件人、承诺内容、日期和语气。若组织已批准特定低风险模板自动发送，也应设置允许条件、撤回流程和发送记录。
错误与恢复设计
将错误分为可重试和不可重试两类。临时网络错误可以有限重试；授权失效、找不到联系人、结构校验失败或政策不允许处理，则应停止并通知负责人。每次运行至少记录会议标识、当前阶段、错误原因和下一步动作。
端到端测试应覆盖：重复 Webhook、空记录、多人同名、日期缺失、AI 输出格式错误、CRM 权限不足和邮件草稿失败。测试数据应为已获准使用的样本。
评估是否有效
不要只统计自动创建了多少记录。更有意义的检查包括：人工修改率、无法匹配的联系人比例、重复写入次数、处理失败后的恢复时间，以及外发前发现的问题数量。指标应帮助团队发现流程缺陷，而不是被模型用来自动评价个人表现。
从一个低风险动作开始，例如“提取行动项并创建待复核任务”。当来源、结构、权限和恢复路径都稳定后，再逐步加入 CRM 更新或跟进草稿。这样，AI 负责把文本转成候选结构，Make 负责可观察的流程编排，而最终业务判断仍由有权限的人承担。