Evaluation method
Evaluation Criteria for Gambling CRM Platforms
A CRM platform for licensed gambling must store permissions by product and channel, give exclusions precedence over everything, keep an append-only history of changes and pass that state to every connected tool. These tests check each point in a trial account.
In short
- Tier 1: product and channel permissions, exclusion precedence and objection handling.
- Tier 2: append-only history, wording versions, event delivery and data minimization controls.
- Tier 3: segmentation, reporting and user experience.
- Run every test with your own seeded accounts and record the evidence level.
Scope and limits. Tests for buyers; not a review of any product. The evidence scale and weighting are explained in our evaluation method.
Tier 1: safeguarding and consent
| Requirement | Test in the trial account | Passing looks like |
|---|---|---|
| Product and channel opt-in (Great Britain, SR code 5.1.12) | Create a customer opted in to betting email only, then query eligibility for casino email | Casino email returns not eligible |
| Exclusion precedence (SR code 3.5.3) | Give a customer full opt-ins, then record a self-exclusion | Every marketing eligibility check returns not eligible; opt-ins stay on record |
| Objection to all marketing (UK GDPR) | Record "stop all marketing" through support | All channels blocked; permissions cannot be re-enabled by a campaign user |
| Write protection | Log in as a marketing user and try to change a permission or exclusion | The action is refused and logged |
The first test follows the matrix described in managing player preferences across products and channels.
Tier 2: evidence and integration
| Requirement | Test | Passing looks like |
|---|---|---|
| Evidence of consent (SR code 5.1.11) | Ask for the full history of one customer's casino email permission | Every change with time, source, actor and wording version |
| Append-only history | Change a permission three times, then correct an error | Four rows; the correction points to the original |
| Event delivery | Withdraw a permission and watch connected tools | An event is published within seconds and acknowledged |
| Data minimization | Ask which fields are sent to the email tool | Only fields you chose; safeguarding sent as a yes or no gate |
| Suppression after deletion | Delete a customer profile who had objected | A suppression entry remains and blocks a re-import |
The last two tests reflect guidance from the Information Commissioner's Office (ICO) that you "should not have more personal data than you need", and that suppression keeps "just enough information" to respect a refusal in future. The background is in data minimization in gambling CRM records.
Tier 3: operations
- Segments re-evaluate eligibility at send time, not only when built.
- Reports show suppressed sends with reason codes, not only delivered ones.
- Permissions can be exported per customer to answer a request.
Questions for the vendor
- Where are permissions stored, and which roles can change them?
- How are exclusions from national registers recorded and dated?
- Which events do you publish, in what format, and how are failures retried?
- Can we see the log entry for a suppressed send?
- How do you separate marketing, account and protective message types?
Use these with the CRM integration checklist once a platform is chosen. The structure these tests assume is described in CRM architecture for consent-aware marketing.
Red flags in a demo
- Permissions are stored as tags that any marketing user can add or remove.
- Self-exclusion is handled by moving the customer to a "do not contact" list that a campaign can override.
- The vendor cannot show who changed a permission and when.
- Deleting a customer also deletes the record of their objection, so a later import brings them back.
- Exclusion data from national registers is copied into campaign tools with the reason attached.
Each of these breaks a principle in the reference architecture, and each is cheaper to catch in a trial than after launch.
Questions
Should the CRM or the email tool own permissions?
The CRM or a dedicated permission store should own them, so that every channel reads one source. Treat a design where each tool keeps its own permissions as a tier 2 risk.
Is a single marketing opt-in field ever enough?
Not for remote casino, bingo or betting licensees in Great Britain, who must offer opt-in by product and channel. Elsewhere it may meet the law but makes evidence harder to produce.
Sources
- Gambling Commission, LCCP Condition 5.1.12 - Direct marketing preferences, no date shown.
- Gambling Commission, LCCP Condition 5.1.11 - Direct electronic marketing consent, no date shown.
- Gambling Commission, LCCP 3.5.3 Self-exclusion - remote SR code, no date shown.
- Information Commissioner's Office, Principle (c): Data minimisation, page dated September 9, 2025.
- Information Commissioner's Office, Right to object, page dated March 25, 2025 (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.