How to choose an iGaming CRM platform.

The question behind the question

Platform selections usually start after a period of frustration: campaigns take too long to build, the data is not trusted, reporting disagrees with finance, something that ought to be simple is not. The conclusion is that the platform is wrong. Sometimes it is. More often the platform is a symptom.

Before running a selection, it is worth separating the complaints into categories, because only one of them is actually solved by buying something:

• Data problems. Events are missing, late, inconsistently named, or do not reconcile with the source of truth. A new platform inherits all of this on day one, and typically makes it more visible rather than better.
• Integration problems. The CRM cannot see the wallet, the bonus engine, or the game session data in usable form, so programme logic is built on proxies. Also inherited.
• Process and ownership problems. Campaigns are slow because approval is slow, or because one person is a bottleneck, or because nobody has decided who owns the calendar. Buying software does not fix this and occasionally makes it worse by adding a migration to the queue.
• Capability problems. The platform genuinely cannot do a thing you need — real-time evaluation, a channel, multi-brand separation, a required compliance control. This is the category that justifies a selection.

An honest audit before the selection usually reshapes it. Sometimes it cancels it. Either outcome is cheaper than discovering it eight months into an implementation, which is the usual alternative.

Four categories of platform, not one market

Vendors in this space are frequently compared as if they were interchangeable. They are not — they come from different origins, and the origin shapes what they are good at. Broadly, four categories:

Platforms we work across in client engagements include Smartico, Optimove, Xtremepush, Salesforce, and Customer.io, as well as in-house systems. We are not resellers or implementation partners for any of them, and we do not publish feature comparisons — vendor capability changes quickly enough that any table we wrote would be stale before it was useful, and the specifics that matter to your decision should be confirmed with the vendor and verified in a trial against your own data.

What we will say is that the category a platform comes from predicts its shape more reliably than its feature list does. A gaming-native tool will have opinions about players, bonuses, and jackpots baked into its data model, which is a large accelerator if those opinions match yours and a persistent friction if they do not. A general engagement cloud will make you model those concepts yourself, which is slower to start and more flexible later.

What actually differentiates platforms in practice

Selection processes tend to over-weight the campaign builder, because it is the part everyone sees in a demo, and under-weight the parts that determine whether the programme can exist at all.

The player data model

How the platform represents a player, and how much of your reality it can hold without custom fields everywhere. Multiple accounts, multiple brands, multiple currencies and wallets, self-exclusion state, KYC state, jurisdiction. If any of these have to be bolted on as attributes rather than being first-class, expect that to surface as a limitation later — usually at the point where a regulator asks a question about it.

Real-time event handling

The important number is not whether the platform claims real-time capability but what the end-to-end latency is from event occurrence to message dispatch, under your event volume, at peak. A trigger designed to catch a player mid-session is worthless at a fifteen-minute delay. Ask for the figure under load rather than in isolation, and ask what happens to ordering when a backlog forms.

Bonus and reward integration

Whether the platform can issue a reward directly or has to ask another system to, and what happens when that call fails. This is the single most common source of operational pain we encounter: the message goes out, the bonus does not land, and the player contacts support. Ask specifically about failure handling and reconciliation, not about whether the integration exists.

Multi-brand and multi-jurisdiction separation

If you run more than one brand or more than one licence, the ability to keep data, consent, suppression, and reporting properly separated while still operating a shared team is a hard requirement rather than a nice-to-have. Retrofitting it is expensive. Some platforms treat it as a core concept and others as a configuration convention, and the difference only becomes apparent under audit.

Compliance controls

Self-exclusion and cool-off enforcement, marketing consent by channel and jurisdiction, message-frequency caps, content restrictions where the market demands them, and an audit trail that shows what was sent to whom and why. Controls enforced by the platform are dependable; controls enforced by team discipline are not, and the difference matters most on the day someone asks you to prove it.

Deliverability and channel reality

Sending infrastructure, IP and domain reputation management, and how much of it you control. Gambling traffic attracts more filtering scrutiny than most categories, so a platform's deliverability posture is a commercial variable, not a technical footnote.

The integration reality

The most reliable predictor of whether a CRM implementation goes well is not the platform. It is the quality of the event stream feeding it.

Before committing to a platform, get concrete about what you can actually deliver to it:

1. Which events exist today, with what fields, at what latency, and how reliably. Not what the documentation says — what the production stream contains this week.
2. What the identity model looks like across registration, wallet, game session, and support systems. If the same player is keyed differently in three systems, that reconciliation is your project regardless of which platform you buy.
3. Whether the platform provider or the platform vendor owns the integration. On many operator stacks the gaming platform sits between the CRM and the data, and its roadmap becomes your constraint.
4. What happens on backfill. Historic data migration is where most timelines slip, and where value-band continuity is usually lost.

It is entirely normal for this exercise to conclude that the event stream needs work before any platform can help. That is a good outcome discovered early and a painful one discovered late.

Build versus buy

In-house CRM systems are common in this industry, more so than in most, because operators tend to have engineering capacity and an unusually specific data model. Some of them are genuinely good.

The honest case for in-house: it fits your data model exactly, there is no licence fee, there is no vendor roadmap between you and a change, and gambling-specific logic that a general platform makes awkward can be native.

The honest case against: every capability is now your backlog, competing with revenue-facing work. Compliance controls, deliverability tooling, and reporting tend to be built last because they are least visible. Key-person risk is real and usually unacknowledged — many in-house systems have one person who fully understands them. And the total cost is rarely compared honestly, because the engineering time is already on payroll and therefore treated as free.

The pattern we see most often is an in-house system that was the right decision when it was built and has since been outgrown — typically at the point of adding a second brand, entering a market with different rules, or needing real-time behaviour it was not designed for. The failure mode is not deciding to build; it is not revisiting the decision when the conditions that justified it have changed.

What migration actually costs

Migration estimates are almost always built around moving data, which is the smallest part of the job. The costs that dominate are elsewhere.

• Re-implementing programme logic. Every campaign, journey, segment, and suppression rule has to be rebuilt, and the old system is rarely documented well enough to make this a translation exercise. Expect archaeology.
• Running two systems in parallel. There is a period where both are live, and it is longer than planned. Suppression and frequency capping across two systems is the part that bites.
• Re-establishing sending reputation. New sending infrastructure means warming up, which means reduced volume for a period, which shows up as a revenue dip attributed to the migration.
• Retraining and lost fluency. A team that was fast in the old system is slow in the new one for a quarter or more, and this is almost never budgeted.
• Historic continuity. Value bands, lifecycle state, and reporting baselines need to survive the move, or you lose comparability at exactly the moment you need to prove the migration was worth it.

None of this is an argument against migrating. It is an argument for entering a migration with the real number, and for sequencing it so the parallel-running period is as short as you can make it.

Running an evaluation that produces a decision

Scorecards with forty weighted criteria tend to produce a number that everyone distrusts and a decision made on other grounds anyway. A tighter approach:

1. Write down the three to five things that actually have to change. If a platform does all of them, it is a candidate; if not, it is not, regardless of how it scores elsewhere.
2. Define hard constraints separately from preferences. Jurisdictional data residency, a required compliance control, an integration that must exist — these are pass/fail and should filter the list before scoring begins.
3. Run a real trial on your own data. Not a sandbox with sample events. Build one genuine journey end to end, including the reward issuance and the failure path.
4. Talk to a reference operating at your complexity — similar brand count, similar markets, similar volume. A reference running one brand in one market tells you very little about how the platform behaves under multi-licence separation.
5. Price the total, over three years. Licence, implementation, integration engineering, ongoing support, and the internal cost of running it. Licence fee alone is not a comparison.

Questions worth asking in a demo

Demos show the happy path by construction. These questions tend to surface the rest:

• What is the end-to-end latency from event received to message sent, at our peak volume — and what happens to event ordering when a backlog forms?
• Show us a reward issuance failing. What does the player experience, what does the operator see, and how is it reconciled?
• How are self-exclusion and cool-off enforced — in the platform, or by our team remembering to apply a suppression?
• How do you separate two brands under two licences while a shared team operates both? Show the permission and audit model.
• What does the audit trail contain if a regulator asks why a specific player received a specific message on a specific date?
• Which parts of the integration do you own, which do we own, and which depend on our gaming platform provider's roadmap?
• If we leave in three years, what leaves with us and in what format?

The last one is asked least often and is the most informative. A vendor that has a clear, unbothered answer is telling you something about how they expect to keep the account.