WhatsApp is often the fastest operational channel in Dubai. That speed is exactly why consent and opt-out handling needs to be explicit and consistent.
This post is not legal advice. The goal is an implementation pattern that is auditable, repeatable, and safe under retries.
If you are evaluating tooling, see:
The mistake: treating consent as a checkbox
Consent is not a boolean. In real operations you need:
- A current status (
unknown,opted_in,opted_out) - When it changed (timestamps)
- How it was captured (method)
- Proof (metadata you can show later)
When any of those is missing, teams either stop sending (business impact) or keep sending (compliance risk). The solution is to make consent an explicit record with audit-friendly fields.
A practical consent record shape
Use a consent record keyed by:
- Tenant (so multi-tenant isolation is guaranteed)
- Channel (
whatsapp) - Subject identity (who the consent applies to)
- Optional normalized phone (for deterministic matching)
Operationally, that lets you answer: "Are we allowed to message this person/vendor/tenant on WhatsApp right now?"
Normalize phone numbers first (deterministic routing)
Consent is only reliable if you can match identities reliably. In practice:
- People paste numbers in different formats
- Imports include spaces and punctuation
- Some sources use
00prefixes instead of+
Pick one normalized representation (commonly + plus digits) and normalize on write. Then store both:
- The raw phone as entered (optional, for support)
- The normalized phone (for matching)
Fail closed when consent is unknown
The safest default is:
opted_in-> allow messagingopted_out-> deny messagingunknown-> deny automation (and prompt for a human decision)
That single rule prevents accidental blast messaging to contacts where consent status was never captured.
Capture proof (so audits are easier)
A "proof" payload does not need to be complicated. It needs to be consistent.
Examples of useful proof metadata:
consent_method:manual,web_form,import,whatsapp_message- Who updated it (user id / profile)
- When it was updated
- Source context (record id, file name, form id, etc.)
The point is not bureaucracy. The point is being able to answer "why did we think consent existed?"
A minimal outbound gating checklist
Before sending any outbound WhatsApp message automatically:
- Validate tenant WhatsApp is enabled (feature flag / settings)
- Check kill switch is not enabled
- Check outbound budgets (tenant-level + conversation-level)
- Check consent record is
opted_in - Only then enqueue/send
This is the pattern that keeps automation safe under retries and real-world operational load.
Connect consent to operations (not just CRM)
Consent is not only a CRM problem. It shows up in:
- Procurement follow-ups with vendors
- Tenant collections and reminders
- Brokerage lead follow-up and viewing coordination
The rule stays the same: store consent once, then enforce it everywhere.
What to do next
- If you need to connect WhatsApp into tenant-scoped workflows, start here: WhatsApp Business integration (Dubai)
- If you want automation with guardrails, see: WhatsApp automation (Dubai)
- If you need visibility and traceability for operational actions, use: audit logs (Dubai)