There is a moment in every platform onboarding that feels like the hardest part is over.
The commercial agreement is signed. The scope has been discussed. The technical teams have been introduced. Everyone is excited. The operator is already thinking about its launch party...
And yet this is precisely the moment when the most consequential mistakes are made.
Not because the technology fails – though it sometimes does. Not because the platform is wrong – though that happens too. But because the onboarding phase has been handed to people who were never given the foundation they needed to succeed.
The same failures repeat across different platforms, different operators and different markets. The technology changes. The failures do not. And the reason is always the same: the onboarding phase is treated as an execution problem when it is actually a communication and planning problem.
Fix the communication and the planning, and the technology finds a way to work. Ignore them and no amount of technical quality will save the go-live.
1. The scope was never actually defined
There is a distinction that gets blurred in almost every platform onboarding – the difference between a project scope document and a project plan.
The project scope document belongs in the commercial phase – and not merely as a reference document. It should form an integral part of the signed agreement between operator and platform provider. Built during negotiations, agreed between commercial teams on both sides and attached to the contract before a single integration call begins, it is the document that defines what was promised, what was agreed and what both parties are legally accountable for delivering. By the time it reaches the project manager, it should already be locked – because the contract depends on it.
What happens in practice is the opposite. The scope arrives incomplete, loosely worded or optimistic. Developer optimism makes it worse. Developers estimate for the best-case scenario – the clean API, the cooperative counterpart, the absence of edge cases. They are not being dishonest. They genuinely believe the timeline they give you.
The project manager's job is to verify it. Cross-check every timeline with every department involved. Build the project plan from reality, not from aspiration. Flag discrepancies between what was promised commercially and what is technically deliverable before the client has been told a go-live date.
When the scope is wrong, the timeline is wrong, the budget is wrong and the expectations are wrong. In short, eerything that follows is wrong. No project management skill recovers a project that started from a false foundation.
2. Honesty traded for comfort
This is the failure that causes the most lasting damage to operator relationships – and the one least often discussed, because it feels like a people problem rather than a process problem.
Onboarding teams tell clients what they want to hear. A deadline slips – but instead of communicating it clearly and early, the team delays the conversation, hoping something will change. A technical problem emerges – but instead of surfacing it immediately, it is managed internally until it can no longer be hidden.
The client finds out anyway. They always find do.
But now they find out late, without context, and with the feeling that they were not trusted with the truth.
The alternative is not comfortable. Telling a client that their go-live is moving by three weeks, in writing, in the second week of an integration, feels like failure.
But it's not. It is professional practice.
Weekly meetings. Weekly written status updates. A transparent project plan visible to both sides. A clear escalation path for when things go wrong – because something always goes wrong. These are not bureaucratic overhead. They are the infrastructure of trust.
Operators forgive technical failures they were told about honestly. They do not forgive technical failures they discovered themselves
3. QA was treated as one side's responsibility
Quality assurance before go-live is almost always discussed as something the platform team does. They test the integration. They confirm the callbacks. They sign off on the wallet flows.
What gets missed is that a platform integration involves two environments – and only one side can test both of them.
Proper QA requires active participation from the client. The operator needs to test their own back-office configurations, their own KYC workflows, their own payment provider connections, their own regulatory reporting outputs. The platform team cannot test what they do not have access to. The operator cannot test what they do not understand technically.
When QA is treated as one side's responsibility, half the environment goes into production untested. The platform worked perfectly in testing. The client's environment had never been properly tested at all. This is not a hypothesis – it is the explanation for the majority of post-go-live incidents.
A joint UAT sign-off process – with defined test cases, defined acceptance criteria, and sign-off required from both sides – is not optional. It is the only way to know that what is being launched actually works.
Bojana Corovic, iGaming B2B Consultant and Global Gaming Insider contributor. Watch out for the June issue of Global Gaming Insider magazine for more of Bojana's articles.
4. Regulatory requirements arrived during onboarding instead of before
This failure is specific to a particular client model – the turnkey operator, where the client holds the licence and is therefore responsible for their own regulatory compliance requirements. It is also one of the most damaging failures in the entire onboarding lifecycle.
The pattern is consistent. Regulatory requirements – reporting formats, timezone configurations, transaction monitoring integrations, AML thresholds – are not shared during the scoping phase. They arrive during onboarding, sometimes weeks in, when the platform configuration is already underway.
Everything built to a generic standard now needs to be rebuilt to a jurisdiction-specific standard. Timelines collapse. Costs increase. In worst-case scenarios, the operator reaches go-live only to receive a formal compliance notice from their licensing authority within weeks of launch – because requirements that should have been in the scope document were never captured at all.
The fix requires discipline at the commercial stage: regulatory requirements are a scoping input, not an onboarding discovery. In any Turnkey engagement, the commercial team must obtain the full list of licence-specific technical and reporting requirements before the project scope is finalised – and before the agreement is signed. If the requirements are not available at scoping, that is the conversation to have. Not a problem to discover six weeks into delivery.
5. Scope changes accumulated without control
Every project has scope changes. One or two, managed through a formal process, are a normal part of a complex integration. Ten changes, introduced informally, without documentation, without impact assessment and without sign-off from both sides – these are a different thing entirely.
Scope changes in iGaming onboardings rarely arrive dramatically. They accumulate quietly. A client mentions in a meeting that they would also like a specific report format. A developer adds a small feature that was not in the original scope because it seemed straightforward. A payment provider is swapped mid-integration because the commercial team found better terms.
Each change is small. Cumulatively, they add weeks to a timeline the client believes is still on track. They add cost that was never agreed. And when the project runs over – as it inevitably does – neither side has a clear record of why.
Change control is not bureaucracy. It is the mechanism that keeps both sides honest about what was agreed, what changed, and who made the decision. Every change request should be documented, impact-assessed, and signed off by both sides before work begins. This protects the operator from unexpected costs. It protects the delivery team from indefinitely expanding scope. And it protects the relationship from the blame conversation that always follows a project that ran over without explanation.
The pattern underneath all five
Read these five failures and a pattern emerges. None of them are primarily technical. They are failures of definition, communication, honesty, collaboration and process discipline.
The iGaming industry spends considerable energy evaluating platform technology – wallet architecture, API performance, game library depth, regulatory certification. These things matter. But the difference between a smooth go-live and a painful one is almost never which platform was chosen. It is whether the people managing the integration were honest with each other from the first conversation.
The operators who consistently launch on time and on budget are not the ones with the most sophisticated technology. They are the ones who treat their platform partner as a partner – who invest in communication infrastructure before the first line of code is written, and who build the kind of transparency that makes problems solvable rather than political.
That is not a technology problem. It is a people problem. And people problems, unlike technology problems, are entirely within your control.
Bally's and Evoke confirmed talks over a £225m ($304.1m) deal this Monday. Global Gaming Insider explored whether the two could be assembling the "ultimate firefighting squad"
