WhatsApp CRM in South Africa: a POPIA‑compliant setup

Yes — South African SMEs can accept WhatsApp leads into a CRM and remain POPIA‑compliant by doing four things immediately: capture demonstrable consent at first contact, persist the consent text + channel + timestamp in the contact record, implement an auditable deletion workflow, and choose a WhatsApp Business Solution Provider (BSP) that supports in‑region hosting, deletion APIs and immutable audit logs. These are the minimum controls auditors look for and match the Information Regulator’s Form‑style guidance on direct electronic marketing. Information Regulator guidance on direct marketing

Why POPIA matters for WhatsApp leads

POPIA treats messages sent to promote goods, services or events as direct electronic marketing. The practical implications for WhatsApp lead handling are:

• You must have a lawful basis (normally demonstrable consent) for outbound marketing.

• You must keep records that show the exact consent text, the channel and the timestamp.

• You must allow easy withdrawal of consent and provide an auditable deletion trail.

These are not abstract requirements — the Information Regulator’s note explains what auditors expect to see when they request a Form‑style consent pack. Information Regulator guidance on direct marketing

Three integration models and when to pick each

Pick a model based on scale, budget and audit needs.

• Shared inbox (WhatsApp Business App + manual inbox)

  • When: solo operators and micro‑businesses.

  • Pros: fastest and cheapest to start.

  • Cons: no deletion APIs, limited auditability, manual export for evidence.

• Managed BSP with API (local or global providers)

  • When: SMEs that need templates, message logs and manageable automation.

  • Pros: template approvals, message logs, deletion endpoints and often in‑region hosting options.

  • Cons: recurring fees and vendor onboarding.

• Cloud API + custom middleware

  • When: organisations that require full control over residency, automated deletions and custom audit trails.

  • Pros: end‑to‑end automation and programmable logs.

  • Cons: higher build and operations costs.

Decision matrix (quick)

• Budget constraint → Shared inbox.

• Need audit evidence + templates → Managed BSP.

• Need residency + automation → Cloud API + middleware.

Vendor documentation describes the 24‑hour messaging window and template constraints you must design around; review a BSP API page when building template flows. Infobip on WhatsApp Business API

Ready‑to‑use consent: exact copy and CRM field mapping

Capture consent at first contact (sticker, web widget, automatic reply or agent). Auditors want to match the consent text in your record to what the user actually saw — store the exact string.

Suggested consent text (form‑ready)
"I consent to [Business Name] sending me messages, appointment reminders and offers to this WhatsApp number. I understand I can reply STOP or request deletion by replying 'DELETE' or contacting contact@business.co.za. Consent captured on [date/time]."

Record these CRM fields for every contact (use consistent names)

• consent_boolean: true / false

• consent_channel: "WhatsApp" / "Web form" / "Phone"

• consent_text: exact consent string shown to the data subject

• consent_timestamp: ISO8601 timestamp (UTC)

• consent_captured_by: "bot" / "webform" / "agent"

• origin_campaign: campaign_id or form_id (for attribution)

• template_id: saved when the first outbound is a template message

Why exact text matters: storing consent_text lets auditors match what the user saw to your records quickly.

Deletion & retention: auditable workflow, webhook pseudocode and tests

Design a deletion flow that produces two artifacts: a user confirmation and an immutable audit record (store only a non‑PII hash where required).

Auditable deletion sequence

1. User requests deletion (WhatsApp "DELETE", email, web form).

2. System verifies request against contact identifier; create request_id and request_timestamp.

3. Trigger deletion job:

   • remove contact from marketing lists and revoke tokens;

   • purge or anonymise PII in active tables but retain an audit entry with a contact hash;

   • call BSP deletion API if available.

4. Send confirmation to user: "We deleted your personal data on [timestamp]."

5. Store audit entry: {contact_hash, action:"delete", performed_by:"system", timestamp, proof_reference}.

webhook-delete-pseudocode.js

// POST /webhook/delete-request
// payload: { contact_id, request_id, requested_by, request_timestamp }
async function handleDeleteRequest(payload) {
  const contact = await crm.lookup(payload.contact_id);
  if (!contact) return respond(404);

  // call BSP deletion API if available
  if (bsp.supportsDeletion) await bsp.deleteContact(contact.externalId);

  // purge PII or anonymise in CRM
  await crm.purgePII(contact.id);

  // write immutable audit log (store only a SHA256 hash of contact_id)
  const auditEntry = {
    contact_hash: sha256(contact.id),
    action: 'delete',
    performed_by: 'system',
    timestamp: new Date().toISOString(),
    proof_reference: payload.request_id
  };
  await auditLog.write(auditEntry);

  // send user confirmation
  await messaging.send(contact.channel, `Deletion completed on ${auditEntry.timestamp}`);
  return respond(200);
}

Testing checklist (compact)

• Submit a WhatsApp opt‑in and verify consent_text and consent_timestamp in the CRM export.

• File a deletion request and confirm receipt message and audit_log entry exist (non‑PII).

• Export a sample audit pack: consent_text, consent_timestamp, deletion_request, deletion_confirmation, audit_log.

Note: when a BSP exposes deletion or retention APIs, test them end‑to‑end with a vendor test account and keep the results as proof.

Handling the WhatsApp 24‑hour window without losing conversions

WhatsApp allows freeform replies only within a 24‑hour session after the user’s last message; outside that window you must send pre‑approved template messages. Build a decision tree and simple automation rules.

Decision tree

1. If user replied within 24 hours → continue conversational follow‑up (human or bot).

2. If >24 hours and you have an approved template → send template and log template_id.

3. If >24 hours and no template → send SMS fallback or escalate to human agent.

Operational rules (middleware pseudocode)

• Rule A: last_user_message < 24h → auto‑send conversational follow‑up.

• Rule B: >24h and template_approved → send template (log template_id).

• Rule C: >24h and no template → fallback: SMS + tag contact for human follow‑up.

Practical evidence: studies show WhatsApp reminders can reduce outpatient no‑shows, a useful reference when prioritising investment in templates and escalations. WhatsApp reminders reduce no‑shows (study)

BSP selection checklist and vendor tradeoffs

Ask vendors for written evidence and map answers to your compliance needs. Local managed BSPs often advertise in‑region hosting and POPIA‑aware platforms; validate their claims with a technical test.

Must‑have capabilities (questions to ask vendors)

• Do you offer in‑region hosting or a clear data residency policy?

• Are deletion APIs available and SLA’d?

• Can you provide immutable audit logs (inbound/outbound with timestamps)?

• How are template approvals versioned and archived?

• Do you support CRM integrations (webhooks, message IDs, template_id tracking)?

• Do you support in‑chat payment‑link reconciliation if you accept payments in chat?

Vendor checklist table (quick view)

Local examples to review when shortlisting vendors include managed platforms that advertise in‑region hosting and payment features. CloudZA WhatsApp Business Suite (in‑region hosting) | Bidvest Data WhatsApp platform and payments

FAQ — templates, webhooks and auditor requests

Appendix: one‑page testing checklist and immediate next actions

One‑page testing checklist (do these in a test environment)

• Consent capture: create test contact → capture consent_text + timestamp → export consent evidence.

• Template audit: send approved template → record template_id + approval proof.

• Deletion flow: submit deletion → confirm user message + audit_log entry exists.

• 24‑hour window: simulate >24h inactivity → verify template/blocking and SMS fallback.

• Payment link test (if used): send payment link → confirm reconciliation to contact ledger.

Immediate next actions (practical)

1. Map your current WhatsApp handling: shared inbox, managed BSP or cloud API.

2. Add the consent fields above to your CRM and update intake flows with the suggested consent text.

3. Shortlist BSPs that support deletion APIs, in‑region hosting and audit logs; run a written technical test with each vendor.

4. Run the testing checklist and collect an audit pack for internal compliance records.

Luminum builds connected systems that join websites to lead handling, automations, appointments and reconciled payments. See how Luminum connects websites to WhatsApp, automations and billing.