识别请求及其范围
请求可以通过 WhatsApp、偏好设置页面、电子邮件或您的支持团队提出。WhatsApp 的 商业消息政策 要求您遵守在 WhatsApp 平台内外提出的退订请求。 客户可能会停止接收促销优惠,但仍要求获取进行中订单的更新。当您的系统支持时,请保留明确的类别偏好设置。如果请求宽泛或含糊不清,请勿将其解释为允许继续发送营销活动。 不要假定身份验证、公用事业或服务消息总是可以免除客户声明的偏好设置或适用法律的约束。在下次发送前应用该决定
一个可靠的流程应当:- 记录请求及其范围。
- 更新相关的退订或偏好记录。
- 将客户从待处理受众和跟进序列中移除。
- 确保重试和手动操作应用相同的决定。
- 将变更与已连接的系统同步。
在 YCloud 中管理退订
YCloud 提供了退订列表和用于添加退订用户的基于规则的坐席工作流。 退订 API 会将客户和渠道一同记录。这些记录与删除客户联系人是不同的概念。 确认您的哪些发送路径会自动强制执行消息拦截。不要假定在某个营销活动中记录的退订也会阻止每个自定义 API 调用方、集成或单独账户。重要的 API 差异:不同发送路径下的拦截机制并不完全一致
当前的 YCloud 队列端点POST /v2/whatsapp/messages 支持 filterUnsubscribed。它默认为 false。启用后,适用的退订操作可以阻止发送,并在消息错误中产生 RECIPIENT_UNSUBSCRIBED。
该选项 不 适用于 POST /v2/whatsapp/messages/sendDirectly。如果您的集成使用直接发送,请在工作流程中强制执行相关的偏好检查,而不是假定队列端点的过滤器会对其进行保护。
类似地,队列端点的 filterBlocked 是黑名单的单独选项;它不是客户同意的证明。
来源:YCloud OpenAPI 规范。这些属于 API 行为,并非针对每个控制台产品默认拦截行为的声明。
定义退订按钮背后的处理逻辑

The Unsubscribe button returns a response. Your workflow must record the preference and suppress later offers.
- 识别传入的回复或配置的有效负载。
- 解析正确的客户和 WhatsApp 渠道。
- 记录请求的范围和时间。
- 添加相应的拦截机制。
- 阻止待处理的营销活动和跟进自动化出于该目的联系客户。
- 如有需要,仅发送允许的非促销性确认信息。
STOP。像“不要再联系我”这样宽泛的请求需要比停止单一营销活动更全面的处理。
使流程可测试
使用测试客户来检查:
同时还要测试自然语言请求以及您客户使用的各种语言。
仅在做出新决定后重新订阅
客户可以改变主意,但从退订列表中手动删除记录并不能作为重新获得同意的证据。 在移除相关退订拦截前,请记录新的 opt-in 授权及其适用范围。保留充分的历史记录,以便区分真实的新订阅与误导入或管理员误操作。 有关证据设计,请参阅 客户同意授权 (Opt-in)。避免不良做法
请勿切换到其他商业号码来继续发送用户不想接收的营销活动。请勿让退订消息的流程比订阅更困难。请勿单纯为了询问客户为何退订而发送新的促销消息。 清晰明确的退订处理能够保护客户信任,并有助于提升 消息质量。常见问题
我们添加了退订按钮。客户会在所有地方自动被拦截吗?
我们添加了退订按钮。客户会在所有地方自动被拦截吗?
按钮只是交互界面。请确保按钮响应会记录客户的偏好,并停止相关的 Campaign、Journey、基于规则的 Agent 以及 API 发送。请分别测试直接发送和排队发送路径;YCloud 可选的排队发送过滤功能并不自动保证每个 API 请求都会检查退订列表。
客户是对人工客服表达了停止接收意愿,而不是对基于规则的智能体说的。应该如何处理?
客户是对人工客服表达了停止接收意愿,而不是对基于规则的智能体说的。应该如何处理?
人工客服必须能够记录该请求及其适用范围和生效时间。请在下一次相关发送(包括排队或重试的消息)之前生效该设置。请勿要求客户必须使用完全一致的关键字或按钮重新提交请求。
已退订的客户咨询现有订单的情况。我们必须忽略他们吗?
已退订的客户咨询现有订单的情况。我们必须忽略他们吗?
不必。需要明确退订范围:停止接收优惠信息并不等于拒绝所有联络。您可以在适用的时间窗口内,使用符合条件的消息回复客户当前的客服请求,但切勿擅自恢复其营销许可或在回复中夹带促销内容。如果客户提出了更广泛的“拒绝联系”请求,请严格按照其要求的范围予以遵守。

