The Consent-Enforced CRM for UAE Business

The origin

Why a compliance company built a CRM

Invaq started as an e-invoicing compliance platform for the UAE’s phased 2026–2027 rollout: invoice data goes in, a deterministic rule engine validates it against our current draft PINT AE-style ruleset (openly versioned as a draft until the regulator publishes the final specification), compliant XML comes out, and documents route to Accredited Service Providers through provider adapters. Invaq is not itself an ASP — it is the layer that prepares, validates, and routes, and records every step. If you are still mapping the rollout, our deadline guide covers the timeline in plain language.

Building that pipeline taught us something uncomfortable about CRMs: most of them treat customer messaging the way pre-compliance accounting treated invoices — free-form, unverified, and unlogged. A marketing blast goes out, nobody can say afterwards who consented, who was excluded, or why, and the “do not contact” flag lives in a spreadsheet column that half the integrations ignore. So we built the CRM the same way we built the invoice engine. One audited data spine runs underneath both: the same tenant-scoped store, the same append-only audit log, the same discipline. The CRM enforces consent the way the invoice engine enforces VAT rules — as a hard gate in code, not a policy document — and every send outcome, allowed or blocked, lands on the same audit trail your invoices do. It is the same engineering culture that ships our free ICV calculator and PINT AE validator: show the rule, apply the rule, log the result.

The consent model

Tri-state consent, one dispatch gate, no way around it

Every contact carries a consent value per channel — email, SMS, and WhatsApp are tracked independently — and each value is one of three states: granted, denied, or unknown (never asked). The third state is the one most CRMs quietly collapse into “fine to message”. Invaq does not. For marketing purposes, unknown means excluded: silence is not opt-in. For transactional and payment messages, only an explicit denial blocks the send, because a customer who never filled in a preference still needs their payment reminder.

The enforcement point is a single dispatch gate. Campaigns, birthday greetings, payment reminders, and one-off messages all resolve consent at the same function before anything leaves the platform — there is no second code path that skips the check, which is what makes the guarantee real rather than a policy note. And consent itself is treated as compliance data: every change is audit-logged with the before and after state, who or what changed it, and its source, so “when did this customer opt out of SMS?” has an exact, timestamped answer.

Read the columns, not just the rows: marketing-class messages (campaigns, birthday greetings) send only on an explicit grant, while transactional and payment messages block only on an explicit denial. A denial is absolute — no purpose overrides it on that channel.

Channels & providers

Email, SMS, and WhatsApp behind provider adapters

Each channel sits behind a provider adapter — the same pattern our invoice pipeline uses for ASPs — so the CRM’s consent logic, campaigns, and audit trail never depend on a single vendor. Email dispatches through Resend; SMS and WhatsApp dispatch through Twilio and the WhatsApp Business API. Until your credentials land, a built-in mock provider simulates sends safely: you can build audiences, run previews, and exercise the whole flow without a single real message leaving the building. The interface shows a “Live” or “Mock” badge on every channel, so there is never ambiguity about whether a campaign will actually reach phones and inboxes.

Campaigns

The preview names exactly who is excluded, and why

Campaigns start from tags: assemble an audience from your real contact list, write the message once with merge fields like {{contact_name}} and {{company}}, and pick a channel. Then comes the part most CRMs hide: before anything sends, the preview resolves consent and contactability for every single recipient and tells you plainly who is in, who is out, and the reason for each exclusion — no marketing consent versus no address or number on file are reported separately, because they are different problems with different fixes. Sending is a deliberate two-click act: review the preview, then confirm. No campaign fires from a single misclick.

Loyalty

Points that come straight from paid invoices

Loyalty points accrue automatically from delivered and paid invoices — the same invoice data that runs through your compliance pipeline — so a customer’s balance reflects real business rather than a hand-maintained ledger. Accrual is idempotent per invoice: each invoice can earn its points exactly once, so retried queue events, replayed webhooks, and re-recorded payments can never double-credit a balance. When a human does need to intervene — a goodwill bonus, a correction — manual adjustments are supported, but each one requires a reason, and both the adjustment and its reason land on the audit trail.

Balances map to four tiers, bronze through platinum, and every company gets a printable QR loyalty card: hand it over, and the customer scans it to check their tier and balance whenever they like.

New · Consumer enrollment QR

Customers enroll themselves — consent included

The newest addition closes the loop on how contacts get into the CRM in the first place. Print one enrollment QR for your workspace and put it at the counter, on the receipt, on the delivery bag. A customer scans it and lands on a public join form: name, contact details, an optional birthday, and — the important part — explicit consent checkboxes per channel. A ticked box is a real opt-in: it is recorded as consent granted with source enrollment, timestamped on the audit trail like every other consent change. An unticked box stays unknown — the form never manufactures consent the customer did not give.

The moment they submit, the customer receives their own loyalty card link — tier and balance, live, no app to install. And because printed paper can walk out the door, the QR is rotatable: rotate it once in settings and every previously printed copy is revoked, while the new code takes over. Self-enrollment stops being a data-quality liability and becomes your cleanest consent source: contacts who joined via QR arrive with channel consent you can prove, attributed to the exact mechanism that captured it.

Automated reminders

Birthday and payment-due reminders that never double-send

Two automations run server-side every morning on Asia/Dubai time: birthday greetings at 06:00 and payment-due reminders at 07:00. Each individual send passes the same consent gate as everything else — a birthday greeting is marketing-class and needs an explicit opt-in; a payment reminder blocks only on an explicit denial. Delivery is at-most-once by design, using a marker-first pattern: the system records “this reminder happened” before dispatching it, so if a run crashes or retries mid-flight, the worst case is one missed greeting — never a duplicate. We chose that trade deliberately: the system would rather miss one happy-birthday than send two.

The timeline

One audited feed per company

Every company has a single activity timeline: notes your team writes, every message outcome (sent, blocked, and why), consent changes with before and after, loyalty accruals and adjustments, enrollments, and reminders — one chronological feed. Because everything the CRM does is audit-logged at the moment it happens, the timeline is not a convenience view bolted on afterwards; it is the audit trail, read back to you in order. When a customer asks “why did I get this message?” or an auditor asks “prove this contact opted in”, the answer is one scroll away.

Quick answers

CRM questions, answered plainly