One player, one permission state: an iGaming CRM suppression playbook

The risk lives between systems

Most operators do not have one marketing tool. They may have an email platform, SMS provider, outbound dialler, customer-data platform, VIP workspace and service desk. Each system can be working as designed while the combined player experience is wrong.

A customer might withdraw email permission but remain on a reactivation calling list. A self-exclusion event may reach the account platform before it reaches the campaign queue. A VIP manager may work from an exported list that no longer reflects the current permission state.

The operational requirement is simple to state: every channel must act on the same valid player decision. Building that outcome requires explicit ownership, data design and queue controls.

Start with the regulatory minimum

For Great Britain, the Gambling Commission's current direct marketing preferences code requires remote operators to offer opt-in choices by product and channel, set to opt-out by default. The channel options include phone calls, email and SMS where applicable, while product choices cover betting, casino and bingo as applicable.

The Commission's electronic marketing consent provision also requires informed and specific consent unless contact is otherwise permitted by law, an opportunity to withdraw consent and evidence that consent exists.

The UK Information Commissioner's Office updated its detailed electronic-mail marketing guidance in April 2026. Operators should apply the law and licence conditions relevant to each market with qualified advice. This article focuses on implementation, not legal interpretation.

Create one permission object

A single “marketing: yes/no” field is rarely enough. The permission object should capture the choices the operator is required to respect and the evidence needed to explain them.

At minimum, define:

• player identifier and applicable brand;
• product permission by betting, casino, bingo or other approved category;
• channel permission for email, SMS, phone and any additional direct channel;
• status, timestamp and source of the latest valid choice;
• version of the language shown to the player;
• market or licence context;
• temporary and permanent suppression reasons; and
• the event that last changed eligibility.

Not every system needs every field. Every activation system does need an unambiguous answer about whether this player may receive this communication through this channel for this product now.

Separate preference, eligibility and suitability

Three decisions are often collapsed into one:

1. Preference: has the player chosen to receive this type of marketing?
2. Eligibility: is direct marketing permitted for the account under current restrictions and operator rules?
3. Suitability: is this particular message appropriate for the player's known circumstances?

A valid opt-in does not automatically make every campaign suitable. A player-protection interaction, restricted account, unresolved complaint or sensitive payment case may require broader or temporary suppression even where a historic preference remains recorded.

Keep the layers distinct so agents understand why a contact is blocked and which team may change that state. Frontline staff should not be able to override a regulatory or player-protection suppression simply because a campaign appears commercially valuable.

Make suppression event-driven

Batch updates create a window in which outdated eligibility can continue to generate contact. Sensitive events should publish suppression changes as close to real time as the operating environment allows.

Priority events commonly include:

• a player withdrawing a channel or product preference;
• self-exclusion or account closure;
• a safer-gambling restriction or review;
• an account eligibility decision;
• a formal complaint involving marketing contact;
• identity or contact-detail uncertainty; and
• a deceased-customer notification.

Each event should update the authoritative record, invalidate queued audiences and reach the systems used by email, SMS, dialling, VIP and outsourced teams. If a downstream platform cannot support immediate updates, remove the affected player from active queues until synchronisation is confirmed.

Protect outbound agents from stale lists

A dialler list or spreadsheet is a snapshot. The permission state can change after that snapshot is created and before an agent makes contact.

Introduce a final eligibility check when the record enters the dialler and again immediately before the call where the technology permits. Show the agent the allowed purpose and channel, not a vague “marketable” label. If eligibility cannot be confirmed, the record should not be presented.

When a player withdraws permission during a conversation, give the agent one clear action that records the request and suppresses future contact. Do not make the player repeat the request to another department.

Design governance around exceptions

Permission operations need an owner who can resolve mismatches across CRM, compliance, safer gambling, data protection and vendors. The owner should monitor:

• contacts attempted after a withdrawal or suppression event;
• differences between the source record and activation platforms;
• records rejected because permission evidence is incomplete;
• time from player request to confirmed suppression;
• manual overrides and their authorisation; and
• campaigns stopped because the control was unavailable.

Test with real journey scenarios, not only field mapping. Change one channel, change one product, self-exclude, reopen an eligible account where permitted, update a phone number and place an account into review. Confirm what every system and agent sees after each event.

Make the BPO part of the control

An outsourced CRM or reactivation team should never receive a broader audience than the operator can defend. Give the partner governed access to the current eligibility result, approved campaign purpose and required evidence—not an uncontrolled database export.

Quality reviews should verify that the agent followed channel and product permissions, respected stop-contact requests and used only the approved campaign language. Vendor governance should include suppression failures as control incidents, not ordinary list-cleaning issues.

A well-designed BPO can strengthen the model by giving one trained team responsibility for campaign preparation, outbound execution, preference capture and exception escalation. The operator must still retain policy, legal and player-protection authority.

A practical implementation checklist

1. Name the authority: define the system and team that own the current permission state.
2. Model granularity: capture channel, product, brand and applicable market requirements.
3. Layer decisions: separate preference, eligibility and campaign suitability.
4. Publish critical events: remove sensitive players from active queues quickly.
5. Check before contact: prevent diallers and agents from relying on stale exports.
6. Prove the journey: retain evidence and test changes across every activation system.

VERTICALLS builds modular CRM, sales and player-reactivation teams connected to support, KYC, payments and player-protection workflows in English, Spanish and Portuguese.