{"id":3098,"date":"2026-10-19T17:40:59","date_gmt":"2026-10-19T12:10:59","guid":{"rendered":"https:\/\/www.smsgatewaycenter.com\/blog\/?p=3098"},"modified":"2026-10-19T17:41:02","modified_gmt":"2026-10-19T12:11:02","slug":"sms-whatsapp-preference-centre-design-purposes-channels","status":"publish","type":"post","link":"https:\/\/www.smsgatewaycenter.com\/blog\/sms-whatsapp-preference-centre-design-purposes-channels\/","title":{"rendered":"Building an SMS and WhatsApp Preference Centre: Purposes, Channels, Frequency and the Send Gate"},"content":{"rendered":"\n

A preference centre is the page where customers choose what you may send them, on which channel and how often. Built badly it becomes a third list that disagrees with your consent log and your suppression table. Here is how to build one that writes into those records instead, maps purposes to DLT categories, handles rows nobody can switch off, and feeds a send gate that fails closed across SMS, WhatsApp, RCS and Telegram.<\/p>\n\n\n\n

\"Abstract<\/a>
Every choice on the page ends up in one place: the gate in front of every send.<\/figcaption><\/figure>\n\n\n\n

Table of Contents<\/h1>\n\n\n\n
    \n
  1. The Short Answer<\/a><\/li>\n\n\n\n
  2. TL;DR<\/a><\/li>\n\n\n\n
  3. What a Preference Centre Actually Controls<\/a><\/li>\n\n\n\n
  4. Three Layers of “No” and Who Owns Each<\/a><\/li>\n\n\n\n
  5. Purposes, Channels and the Matrix<\/a><\/li>\n\n\n\n
  6. Mapping Purposes to DLT Categories<\/a><\/li>\n\n\n\n
  7. The Rows a Customer Can’t Switch Off<\/a><\/li>\n\n\n\n
  8. The Data Model: Preferences Write Events, Not Flags<\/a><\/li>\n\n\n\n
  9. Frequency Caps, Pauses and Quiet Hours<\/a><\/li>\n\n\n\n
  10. Getting the Customer There: Signed Links<\/a><\/li>\n\n\n\n
  11. Easy Out, Careful In<\/a><\/li>\n\n\n\n
  12. Saving a Change: Diff, Version, Idempotency<\/a><\/li>\n\n\n\n
  13. The Send Gate With Preferences In It<\/a><\/li>\n\n\n\n
  14. Changes That Hit Messages Already Queued<\/a><\/li>\n\n\n\n
  15. Channel Specifics: SMS, WhatsApp, RCS, Telegram<\/a><\/li>\n\n\n\n
  16. Mirroring to the Platform Where You Can<\/a><\/li>\n\n\n\n
  17. Four Code Samples, Four Traps<\/a><\/li>\n\n\n\n
  18. Decision Matrix<\/a><\/li>\n\n\n\n
  19. Launch Checklist<\/a><\/li>\n\n\n\n
  20. Unspecified Behaviour and How to Code Around It<\/a><\/li>\n\n\n\n
  21. FAQs<\/a><\/li>\n<\/ol>\n\n\n\n

    The Short Answer<\/h2>\n\n\n\n

    A preference centre is a page where a customer says what you may send them, on which channel and how often. The trap is building it as a fresh table of on\/off flags. Do that and you now have three places that answer “may I message this person?”: your consent log, your suppression list and the new flags. Sooner or later they disagree, and a send goes out that shouldn’t.<\/p>\n\n\n\n

    Build it as a writer instead. Every toggle the customer changes becomes an event in the consent log (for “yes, send me offers on WhatsApp”) or the suppression log (for “stop everything”). Frequency caps, pauses and quiet hours are the only genuinely new records. Your send gate then reads all of it in one place and refuses anything it can’t prove is allowed.<\/p>\n\n\n\n

    On SMSGatewayCenter<\/strong> the preference centre is something you host. The platform gives you a dashboard Blocked Numbers list and a dashboard WhatsApp opt-in list, plus whatever the operator’s DND registry enforces on SMS<\/a>. None of those are written from your code, and none of them know about purposes like “offers” or “reminders”. So your own records are the authority, and the page is how customers change them.<\/p>\n\n\n\n

    TL;DR<\/h2>\n\n\n\n