CRM guides
Designing a Customer Event Model for Consent Changes
A customer event model is the agreed list of things that can happen to a customer record, with the fields each event carries. For consent, it should include every grant, refusal, withdrawal, objection, exclusion and verification change, each with a time, source and actor.
In short
- Name events after what happened to the customer, not after the screen or tool that caused it.
- Every consent event carries product, channel, new value, time, source and the wording shown.
- Order events by the time they happened, not the time they arrived, and keep the latest value per product and channel.
- Exclusion events are never overwritten by a later marketing event.
Scope and limits. The event names and fields below are a suggested pattern for teams designing or reviewing a CRM. They are not taken from any vendor's schema, and they are not a legal standard.
Why an event model matters
Without an agreed model, each system describes the same change differently. One tool logs "unsubscribed", another sets a field to false and a third records nothing because the change came through customer support. When a regulator or a customer asks what happened, nobody can answer from a single record.
The Gambling Commission's social responsibility code 5.1.11 asks licensees to "be able to provide evidence which establishes that consent" was given. An event history is the most direct way to hold that evidence, as how to keep consent evidence explains.
The core events
| Event | Raised when | Key fields |
|---|---|---|
| permission.granted | A customer opts in to one product and channel | product, channel, wording_id, source, actor, occurred_at |
| permission.refused | A customer leaves an option unselected at registration | product, channel, wording_id, source, occurred_at |
| permission.withdrawn | A customer opts out of one product and channel | product, channel, source, actor, occurred_at |
| marketing.objected | A customer objects to all direct marketing | scope (all), source, actor, occurred_at |
| exclusion.started | Self-exclusion or a national register match is recorded | type, register_ref, ends_on, occurred_at |
| exclusion.ended | An exclusion period ends and is confirmed | type, register_ref, occurred_at |
| identity.verified | Age and identity checks pass | method, occurred_at |
| preferences.confirmed | An existing customer confirms preferences at first log-in | matrix snapshot, wording_id, occurred_at |
The last event exists because code 5.1.12 required remote casino, bingo and betting licensees to ask existing customers to confirm their marketing preferences at their first log-in after the code started. Keeping that confirmation as its own event shows when each customer moved to the new format.
Fields every consent event needs
- occurred_at: when the customer acted, in Coordinated Universal Time (UTC).
- source: the interface, such as registration, preference center, email footer, text reply or support call.
- actor: the customer, or the staff member who recorded a request on their behalf.
- wording_id: a pointer to the exact text and options shown. The consent guidance from the Information Commissioner's Office (ICO) says organizations should give "granular options to consent separately to separate purposes", and the stored wording proves which options were offered. Screen patterns that produce clean wording records are described in consent capture and preference center design.
- market: the license or jurisdiction the account belongs to, because the rules differ by market.
Ordering and duplicates
Systems receive events late, twice or out of order. Three rules keep the current value correct:
- Order by occurred_at, not by arrival time.
- Treat each event as idempotent: an event with an ID already processed is ignored.
- Keep exclusions and objections in a separate stream that marketing events cannot overwrite. A permission.granted that arrives after exclusion.started does not end the exclusion.
Example, illustrative only. A customer self-excludes at 10:00 and a delayed web form submits an opt-in stamped 09:58. Ordered by occurred_at, the opt-in comes first and the exclusion second, so the customer is excluded. Ordered by arrival, a naive system would show the opt-in as the latest fact.
From events to current state
Each consuming system builds its own current view from the stream: the latest value per product and channel, plus any active exclusion. How quickly those views must update, and what happens when a consumer is offline, is covered in propagating preference changes. For where each store lives, see CRM architecture, and check that a new vendor consumes these events correctly with the integration checklist for iGaming platforms.
Questions
Should support agents be able to record consent changes?
Yes, if the event records the agent as actor and the customer's request as the source, so the change can be traced to a real request.
Do we need an event when a customer leaves an option unselected?
It helps. A refusal event shows the option was offered and declined, which is different from never having been asked.
Sources
- Gambling Commission, LCCP Condition 5.1.11 - Direct electronic marketing consent, no date shown.
- Gambling Commission, LCCP Condition 5.1.12 - Direct marketing preferences, no date shown.
- Gambling Commission, LCCP 3.5.3 Self-exclusion - remote SR code, no date shown.
- Information Commissioner's Office, What is valid consent?, page dated August 4, 2026 (under review after the Data (Use and Access) Act).
Every source was read on October 28, 2026. How we choose sources: data sources.
Safer gambling support is listed on the safer gambling page.