Grok Bot 与 Brevo：跟进产品反馈，完成闭环

客服工单可能显示“完成”，而客户仍无法使用功能。在一个假设的 CSV 导出需求中，工单 T-104 对应的代码已经合并，但发布开关仍关闭。此时说“你的功能已上线”会成为落空的承诺。

将一条需求连接到一次已确认的发布和一位可联系的用户。xAI 的 GTM Loop Closer 示例介绍了寻找承诺、展示证据并准备回复。这里的检验更严格：产品负责人必须确认实际发布了什么，以及谁可以使用。

有发布证据时才开始

以产品发布记录为触发条件，而不是工单状态变化。记录需要稳定的 feature_id、release_id、已发布的行为、发布日期、开放状态和指定负责人。负责人必须确认，提出需求的客户账号或套餐已经可以使用该功能。代码已合并、测试环境演示或计划中的发布说明都不够。

用功能 ID 将需求记录与发布记录对应，用客服系统保存的联系人 ID 将需求与客户对应。只保存映射和状态。Grok Bot 不需要整个收件箱或产品目录。如果任一 ID 缺失，返回待审核项目，不要凭相似名称猜测。

输入	最少字段	应核实的事实
需求	工单 ID、功能 ID、提出日期、请求者联系人 ID	这个人确实提出过该需求
发布	发布 ID、功能 ID、已发布行为、可用状态、负责人签核	此账号现在可以使用
联系人	联系人 ID、获批的客服沟通渠道、抑制状态	此人可以接收这种回复

需求不等于营销同意。对该需求的事实性回复，应使用获批的客服沟通渠道。如果草稿推广其他功能、要求升级，或面向从未提出需求的人，应视为另一个营销活动，有单独的受众资格规则。遵守所选渠道的退订和抑制状态。双重确认订阅指南说明工单为何不能替代订阅记录。

用有边界的提示词起草一封回复

假设的结果把 T-104 对应到 F-7 和 R-22，但发现发布仍关闭。等待，不要发送。

提供获批记录后，复制以下提示词：

只检查我提供的需求、发布和联系人记录。依据稳定的功能 ID 和联系人 ID 进行匹配，不能只看文字相似。对每个候选项列出工单 ID、功能 ID、发布 ID、负责人签核、账号可用状态、获批的沟通目的和抑制状态。缺少或互相矛盾的证据标为阻断。只对已确认且可用的发布起草简短、事实准确的回复。只根据提供的事实，说明变更内容、客户在哪里使用及如何获得帮助。不要推断营销同意、增加促销说法、创建或更新联系人、发送消息或关闭工单。在这里返回证据表和草稿，等待审核。

**核查：**产品负责人将草稿与发布记录对照，并在提出需求的账号中测试可用性。客服负责人核对收件人身份和沟通目的。任何一项失败，草稿就留在聊天中。Grok Bot 与 Brevo 入门指南介绍有文档依据的 MCP 连接，并解释为什么仍须检查可用操作；这一具体工作流尚未在 Grok Bot 账号中运行。

只发送一次，并记录回执

将获批的发送任务加入队列之前，根据 feature_id + contact_id + release_id 计算去重键，并在持久台账中原子性地预留。已有预留、待处理、状态未知或成功的键都阻止再次入队。不能让两个工作进程通过分离的先读后写检查。超时后，在考虑重试前先核对事件和服务商回执；没有响应不代表没有送达。

审核后，在 Brevo 中配置获批渠道。在 Automations > Workflows > Create an automation 下，如果你的账号提供自定义事件触发条件和邮件操作，就将拟定的 feature_followup_approved 事件映射到获批的客服用途模板。事件需要已验证的联系人标识；功能 ID 和发布 ID 是你提出的事件属性，不是 Brevo 默认字段。启用前用内部联系人测试。只有在批准且成功预留键后，才发出一次事件。否则由客服人工回复。Brevo 记录了自定义事件和工作流设置；核查账号中实际可用的操作。Grok Bot 的草稿不构成执行授权。Brevo API 指南讨论单独的 API 路径。将事件接受记录与邮件发送回执分开保存。事件被接受不证明邮件已发送。记录准确的收件人、获批文本、发布证据、目的、渠道、服务商发送 ID 和时间戳。只有取得确认的发送回执或有记录的人工客服回复后，才将工单标为已跟进。Brevo 的 MCP 文档只表明有可能的集成接口，不能证明你使用的客户端具备所有写入操作或权限。

给每次发布设定观察截止点，例如负责人确认可用后的七天。到截止点时，完成率为得到一次确认跟进的合格需求数，除以该发布的合格需求数。阻断和无法联系的需求分别计数。送达状态和客户回复有助于发现失败；打开邮件不能证明客户看过或用过该功能。没有已验证收件人的发布仍是待办事项。不同结果指标的营销活动实验也需要同样的证据约束。