迪拜企业的每月网站维护清单
迪拜企业每月网站维护清单：更新、备份、正常运行时间、表单、安全、性能，以及网站出问题时该怎么做。
阅读文章把迪拜 WhatsApp Business API 正确接入一个网站，意味着要在一个简单的点击即聊链接和 Meta 的 Cloud API 之间做出选择，搭建需要先获批、才能发给活跃对话之外的人的消息模板，收集真实的用户授权同意，而不是想当然地认为存了一个号码就等于拿到了同意，并围绕决定何时才允许自由格式回复的24小时客服窗口来设计整个流程。架构搭得对，WhatsApp 就会变成您的 CRM 和支持团队真正能用起来的另一个渠道。搭得不对，企业最后得到的只是一个看起来像 WhatsApp、却做不了 WhatsApp Business 大部分该做之事的小组件。
本指南从搭建角度，聚焦阿联酋企业该如何做 WhatsApp Business API 接入：Cloud API 相比点击即聊链接到底是什么，消息模板和审批如何运作，对网站表单而言授权同意意味着什么（而不是营销名单意义上的同意），24小时窗口如何决定您的网站在什么时候能发送什么内容，以及如何在不丢失上下文的情况下，把一段对话交给真人接手。
要点速览
- 一个点击即聊的 wa.me 链接打开的是一段普通的 WhatsApp 聊天。WhatsApp Business API 则把 WhatsApp 接入您自己的系统，比如 CRM 或工单系统。
- Meta 的 WhatsApp Business Platform 文档确认，消息模板通常需要先获得审批才能发送，每个模板还会被分配一个类别。
- 网站不能凭空开启一段 WhatsApp 对话。只有经过审批的模板，才能触达活跃对话之外的人，而 Meta 仍然要求为此获得授权同意。
- 访客给您发消息时，会打开一个24小时的客服窗口，只有在这个窗口内，才能发送自由格式、非模板的回复。
- 在这个窗口内使用自动化是允许的，但一个可用的人工接手路径，才是让 WhatsApp Business API 集成真正好用、而不是令人沮丧的关键。
点击即聊与 WhatsApp Business API 的区别
把 WhatsApp 放上网站最简单的方式，是一个普通链接，格式是 wa.me/您的号码，有时还会在地址里附上一条预填消息。访客点击它，WhatsApp 打开时已经带上了您的号码，接下来的对话就和任何一段普通的 WhatsApp 聊天一样，发生在某人手机上的普通 WhatsApp 或 WhatsApp Business 应用里。除了添加一个链接或按钮，它不需要任何开发工作，对一个乐意用手机回复的小型企业来说，这是一个真正合适的选择。
WhatsApp Business API，Meta 现在把它记录为 Cloud API，是一种完全不同的产品。Meta 自己的概览把它描述为支持大规模程序化消息收发，把 WhatsApp 接入的是软件，而不是一部手机。消息不再是由某个人在 WhatsApp 应用里读取聊天，而是通过一个 webhook 到达您自己的系统，您的 CRM、工单系统或预订工具可以读取它们、进行分流，并做出回复，这个回复既可以是自动的，也可以是由坐席在同一个系统里、而不是靠一部手机完成的。
这个选择真正关乎的是规模和集成程度，而不是质量高低。一家只处理餐桌预订咨询的咖啡馆，没有明显理由去搭建一个 webhook。而一家需要把每一条咨询都记入 CRM、路由给正确团队、并统计响应时间的企业，恰恰需要这个 API，因为一个点击即聊链接，除了手机屏幕之外，没有任何办法把数据送到别处。
一套完整的 WhatsApp Business API 接入实际由什么组成
在网站上的那个按钮背后，一套能正常运作的 WhatsApp Business API 集成，通常由几个固定部分组成。
- 一个 WhatsApp Business 账户和一个已注册的企业电话号码，通过 Meta 的 Cloud API，或一家代您托管这一切的商业解决方案提供商连接。
- 一个部署在您自己服务器或平台上的 webhook 端点，实时接收来自 Meta 的传入消息、送达回执和状态更新。
- 一套已获批的消息模板，用于任何在活跃对话之外发送的内容，每一条都按 Meta 的格式撰写，并提交审核后才能使用。
- 一个对话真正落地的地方，不管是 CRM、工单工具，还是专门搭建的坐席界面，让真人回复成为可能，而不只是一个机器人脚本。
- 对授权同意的记录，因为一个网站为 WhatsApp 采集了电话号码，仍然需要一份站得住脚的记录，说明这个号码为什么可以被发送消息。
一家商业解决方案提供商，也就是 Meta 认证的合作伙伴之一，通常会托管这套技术栈中的技术部分，把一个更简单的界面交给企业使用，对没有自己开发团队来直接运行 webhook 的公司来说，这是切实可行的路径。
WhatsApp Business API 消息模板：为什么审批很重要
消息模板是一条带占位符、预先写好的消息，需要先提交给 Meta，才能被使用。Meta 自己的开发者文档指出，模板通常需要先获得审批才能发送，获批之后还会被赋予一个质量分数，并受到消息发送上限的约束。模板存在的理由只有一个：用 Meta 自己的话说，它们是唯一可以在一个开放客服窗口之外，发送给 WhatsApp 用户的消息类型。
对一次网站集成来说，这一点会立刻产生影响。如果您的网站想发送一条预订确认、一条订单更新，或者在有人放弃填写表单之后发一条跟进消息，而此刻访客并没有在和您实时聊天，这条消息就必须作为一个已获批的模板发出，而不能是临时写就的自由格式消息。这一条规则，塑造了 WhatsApp Business API 接入大部分的技术设计，因为任何一条网站可能想在实时对话之外发送的消息，都必须事先存在为一个有人写好、并由 Meta 批准过的模板。
模板同时也会被分类，类别既影响允许包含什么内容，也影响如何计费。Meta 的模板分类文档列出了营销、实用信息和身份验证这几个类别，一条把订单更新和促销优惠混在一起的模板，会被归为营销类而不是实用信息类。一个用于发送订单确认、预约提醒或一次性验证码的网站集成，应该让这些模板严格保持在实用信息或身份验证类别，不要掺入促销内容，以免模板被重新归类。
在一段开放对话之外，WhatsApp Business API 只会说 Meta 已经批准它说的话。
授权同意：网站实际需要采集什么
网站上的 WhatsApp Business API 集成，通常从一个表单开始：一个预订请求、一个报价申请、结账流程里提供 WhatsApp 更新的一个选项。不管是哪种表单，Meta 关于授权同意的指南给出的要求，和平台其他任何地方一样：明确说明这个人是在同意接收来自该企业的沟通，写明企业名称，并遵守适用法律。为配送目的在结账字段里填写的一个电话号码，并不自动等于同意接收关于其他任何事情的 WhatsApp 消息。
实际的解决办法很直接：在网站表单上任何一个 WhatsApp 相关字段旁边，加一个明确、独立的勾选框或说明文字，写清楚访客将通过 WhatsApp 收到什么内容，并把这份同意记录和号码一起保存下来，而不只是单独存一个号码。阿联酋企业自身关于WhatsApp 营销规则的义务，包括阿联酋的电话营销和数据保护法律，会在此之上另行适用，其覆盖范围远超一次单纯的技术接入所能满足的，所以应该把授权同意，既当成一个表单设计问题，也当成一个合规问题来对待。
从网站角度看24小时客服窗口
当访客通过 WhatsApp 联系您的企业，无论是通过点击即聊链接，还是通过 API，都会打开一个24小时的客服窗口。Meta 关于 WhatsApp Business Platform 定价的文档直接说明了这一点：在这个窗口内，非模板消息可以自由发送，并且每当客户再发一条消息，这个窗口就会重新计时。一旦从访客最后一条消息算起过了24小时，就只有一个已获批的模板才能再次触达他们。
对一次网站集成来说，这个窗口决定了您的系统在任何一个时刻被允许做什么。一个即时回复一段开放对话的在线客服组件，完全是在窗口内运作。而一个想在两天后跟进一次被放弃的咨询的系统，已经离开了这个窗口，需要一个已获批的模板才能做到，这是一个和回复一段活跃对话完全不同的技术和内容决策。设计集成时如果没考虑到这个区别，正是一个 WhatsApp Business API 项目在演示阶段跑得通、真实消息却迟迟发不出去的常见原因之一。
自动化、机器人与转交给真人
在客服窗口内，企业可以搭建真正有用的自动化：回答常见问题、在真人回复之前先收集必要信息，或根据访客输入的内容把对话路由给正确的团队。这些本身都没有问题。真正的问题在于，一套 WhatsApp Business API 集成，从来不让一个真实的问题触达一个真实的人。
一次真正可用的接手，至少需要具备这些：访客能有一种明确的方式直接要求转人工，系统能识别出机器人脚本确实已经给不出有用答案，而不是在同一个菜单里循环，以及一条通往您团队实际使用的工具的路径，不管那是一个共享收件箱、一个工单系统，还是一个 CRM。在设计阶段就把接手路径建进去，远比等机器人已经惹恼客户之后再去补救要简单得多，这也正是一套让人信任的 WhatsApp Business API 集成，和一套让人放弃使用的集成之间的区别。
WhatsApp Business API 接入的简要搭建顺序
在点击即聊与 API 之间做出决定
依据对话是否需要进入 CRM、工单系统或机器人来判断，而不是看哪个听起来更先进。
选择一家商业解决方案提供商，或直接搭建 Cloud API
没有内部团队维护 webhook 的企业，适合用提供商方案；已经在运行自己后端基础设施的企业，则适合直接搭建。
为任何在实时对话之外发送的内容撰写并提交模板
把实用信息和营销内容分开做成不同模板，并在上线日期之前，而不是当周才提交审核。
在每个采集 WhatsApp 号码的表单里设计好授权同意
写明访客将会收到什么内容，并把这份同意记录和号码一起保存下来。
先搭建接手路径，再搭建机器人
先决定一段对话该在何时、如何到达真人手中，再围绕这条接手路径去设计自动化，而不是反过来做。
Digital Marketing Dubai 能提供哪些帮助
我们的WhatsApp API 接入服务，把这套连接搭进您的网站、CRM 或工单系统，模板、授权同意和人工接手，从一开始就设计进去，而不是事后补上。它可以和我们更广泛的网站开发工作配合，用于新项目里的集成需求，也可以和API 与系统集成支持配合，用于 WhatsApp 需要连接到网站以外系统的场景。如果您的企业也在做 WhatsApp 推广，请阅读我们另一篇阿联酋 WhatsApp 营销规则指南，它从营销和法律角度，而不是这里讲的技术搭建角度，说明了 Meta 的授权同意和模板规则。
