Skip to main content
在启动 WhatsApp 工作流之前，请检查您联系客户的方式以及您的业务所提供的内容。 客户同意、模板批准、业务验证和费用支付是独立的要求。其中任何一项都不是对整个使用案例的全面批准。

​
从适用政策开始

请使用最新的 WhatsApp 商业消息政策、商业服务条款 以及 消息传递指南。在销售或促进交易时，请遵循商业消息政策中的商业政策引用。 本页面是产品规划指南，而非针对特定司法管辖区的法律建议。

​
审查完整的客户体验

将消息、商业个人主页、产品、按钮跳转目标和下游工作流放在一起进行评估。 建议的审查问题：
  • 商业身份是否与客户的预期相符？
  • 客户是否授权接收此通信？
  • 实际提供的优惠是否与批准的消息模板目的相符？
  • 落地页是否准确且与消息内容一致？
  • 客户是否可以联系支持人员并停止接收未来的消息？
  • 是否暴露了不必要的敏感信息？
不要以为通过了模板审核就意味着 Meta 已经批准了未来插入其变量的每个值或链接网站上的每个产品。

​
受监管和受限的活动

规则因活动、国家/地区、年龄和产品界面而异。某些受监管行业的短消息传递有有限的例外情况，但有额外要求。消息传递的例外并不自动意味着允许通过目录或支付体验进行销售。 在构建受监管的使用案例之前，请记录适用的确切产品、受众市场、年龄控制、许可证和批准。必要时寻求专业建议。 不要从旧教程中复制允许的国家/地区列表，也不要从竞争对手的例子中推断许可。请针对您的具体活动查看当前的政策章节。

​
保护客户信息

仅收集任务所需的数据并说明其用途。为收件箱对话、Flow 提交、导出和连接的系统设置访问和保留规则。 当任务可以使用更安全的方法时，避免要求客户通过聊天发送完整的敏感标识符。在测试中使用合成数据，并从常规故障排除日志中脱敏客户内容。 使用 Flow 或自动化代理并不能免除您对所提交数据使用方式的责任。

​
提供升级途径

自动化应包括一条清晰的路径，以便在无法解决请求时提供帮助。根据工作流的不同，这可能是人工转接或另一个受支持的联系渠道。 测试识别失败、重复提问、代理不可用以及非办公时间的请求。不要让客户陷入自动化循环中。

​
使用发布审查矩阵

为每个问题分配负责人和证据：

​
示例界限：服务讨论与销售

客户支持对话、促销优惠、目录列表和支付流程即使涉及同一行业，也可能受到不同的管理。不要将一个层面的许可带入到所有其他层面。 对于受监管的使用场景，请写下确切的活动：“发送关于现有服务的非促销更新”比“金融消息”更精确。然后评估适用的政策章节、市场、年龄要求以及任何所需的授权。 客户同意并不代表豁免平台规则，平台可用性也不代表解决了当地的法律要求。当规则不明确时，请在构建自动化营销活动之前解决该使用场景的合规问题。

​
实践中的数据最小化

对于预约 Flow，仅收集安排预约所需的信息。避免仅仅因为表单支持就添加无关的身份、财务或健康字段。确认完成的提交内容将存储在哪里以及谁可以查看。 在故障排除截图中，遮盖客户电话号码、私信内容、凭据和无关的账户详情。在公开文档中使用虚构记录。

​
保留发布记录

对于每个新的使用场景，记录其负责人、受众、同意来源、模板类别、适用政策、数据流和支持途径。 当您引入新产品、市场、模板用途或数据收集字段时，请重新审视该记录，而不仅仅是在发生限制时。 如果 Meta 标记了问题，请参阅 账户限制与申诉。

​
相关主题