An iGaming Platform RFP Your Team Can Actually Compare

Most iGaming platform RFPs fail in a predictable way: they are long enough to look thorough and vague enough to be unanswerable. The responses come back padded with marketing, the evaluation team cannot compare one supplier against another, and the decision defaults to whoever presented most confidently. A useful RFP is the opposite of that. It asks every supplier the same operational questions, in the same format, and it is short enough that an honest supplier can complete it without guessing what you actually care about.

Done well, the document functions like a filter as much as a questionnaire. Suppliers who cannot answer it are saving you a demonstration slot. Suppliers who answer it quickly are telling you their product knowledge lives in the company, not in one salesperson. Both signals arrive before you have spent an afternoon on a call.

Before drafting a single question, confirm what decision the RFP exists to support. Are you selecting a complete platform, replacing one part of the stack, or testing whether a project is feasible at all? Those are three different documents. Mixing their objectives produces responses that cannot be compared — and a comparison you cannot make is a decision you have not really made.

Start with the project boundary

Open the document with two pages of context, no more. Describe the intended entity, the markets you plan to serve, the products you will offer, and the target timing. Identify what is already decided — jurisdiction, brand structure, an existing licence — and what remains open. Then name the roles involved in the evaluation: operations, technical delivery, finance, and the commercial decision maker who will actually sign.

Keep that context honest about volume and ambition, too. Suppliers staff a project differently when they read "first launch in one market" versus "multi-market rollout over two years," and the difference in response quality is real. The boundary section is where a serious supplier decides how seriously to treat you.

Next, state your current constraints. A replacement project may depend on a data export from the incumbent. A new operation may be waiting on licence approval or payment provider onboarding. These are planning inputs the supplier needs for an honest answer, not embarrassing details to reveal after selection. Teams that hide constraints until after the decision discover them again during onboarding, at a worse moment. If you are early in this process, our iGaming platform buyer brief covers how to frame this context, and the platform selection guide covers the decision sequence it feeds into.

Give the suppliers response instructions

Response quality is partly a function of your instructions. Specify the submission format (the response matrix, completed in your template), the deadline, a single point of contact for questions, and what happens to questions raised — answered to all suppliers, or answered privately. Invite suppliers to flag ambiguous questions rather than guess at them; a flagged ambiguity usually means your requirement needs rewriting, which you want to know while there is still time.

Set expectations about what you will do with the answers. If demonstrations will follow the written round for shortlisted suppliers, say so. Suppliers write differently when they know a demonstration, not a procurement meeting, is the next gate. And keep the document owned by one editor regardless of how many stakeholders contribute — RFPs assembled by committee read like it, and suppliers price the confusion back into their risk margin.

Design an answer format that requires evidence

This is the template's core. For every requirement, request five things: current availability, evidence, dependencies, accountable party, and exclusions. Explicitly instruct suppliers to distinguish standard functions from configuration, additional development, and roadmap ideas. Ban free-form essays; a response matrix with defined columns is what makes suppliers comparable.

The question wording matters as much as the format. "Does your platform have an advanced back office?" is an invitation to say yes. A question you can actually compare describes the workflow and asks what record supports it. The table below shows the pattern, with rows you can adapt directly.

RFP question (adapt to your operation)	What a good answer contains	Mandatory?
"An authorised operator can investigate an unresolved transaction using an identifiable record. Describe the record and demonstrate the workflow."	The record's identifier, which systems hold it, and a demonstration route in the current release	Yes
"A finance user can export the agreed transaction set for reconciliation without technical assistance. Show the export and its fields."	Field list, filters, format, and whether it is standard, configured, or modified	Yes
"Casino and sportsbook balances share one wallet. Describe the ledger and how transfers are recorded."	Ledger behaviour, transfer records, and the evidence available for each movement	Yes / No (decide per operation)
"On agreement end, the operator retains access to defined records. State what remains accessible and in what form."	Export scope, format, retention terms, and who performs the export	Yes
"During an incident affecting player funds, describe the support route, response targets, and status communication."	Named severity levels, response commitments, and where they appear in the proposed terms	Yes

Notice the discipline: every row is testable. "Describe and demonstrate" appears constantly. A supplier that cannot demonstrate a mandatory row in the current release has told you something valuable — believe it.

A worked example: one vague ask, one comparable row

Suppose — an illustrative case — your operations director contributes the requirement "the back office must handle payments properly." As an RFP line, that produces five incomparable essays. Rewrite it as three rows in the matrix: one asking how an authorised user investigates an unresolved transaction, one asking how pending and reversed states appear in reporting, and one asking which identifiers connect the platform record to the payment provider's record. Now every supplier answers the same operational questions, evidence fills the columns, and the differences between products become visible in an afternoon instead of a quarter.

The row count stays manageable because granularity moves into definitions, not into question volume. A well-built row replaces a dozen vague bullets, so aim for the dozens of rows that really test your operation rather than hundreds that test your patience.

Run the same transformation for every "must be user-friendly" and "should support growth" in your draft. If a requirement cannot be expressed as an observable behaviour with evidence, it is not ready for the RFP — park it in a discovery list rather than diluting the document.

One more sourcing trick: have each internal contributor — operations, finance, compliance, technical — write their top five mandatory questions independently, then merge. The questions a team would never have thought to ask are usually the ones that would have blocked the launch. Finance tends to contribute reconciliation rows. Operations contributes exception handling. Compliance contributes access and audit records. The draft above from the operations director reads thin because the other functions had not weighed in yet.

Include the uncomfortable questions

Every platform looks strong in the demo. The RFP's job is to find out what happens everywhere else. Include at minimum:

• Incident handling: What happens during an incident affecting player funds, which support route applies, and what response commitments appear in the proposed terms — not in the sales deck.
• Change approval: How are changes to the service approved, communicated, and scheduled? Who can veto a release?
• Audit and access: What activity records exist, who can see them, and how far back?
• Exit: What records remain accessible when the agreement ends, in what form, and who performs the export? This question alone has killed more deals than any feature gap — ask it early.

Require each answer to refer to proposed contract terms or a demonstration. An unsupported assurance is not an answer; it is an annotation saying "unverified." Our article on iGaming platform support SLAs supplies the specific service questions, and the platform migration checklist covers the exit side in detail. On references: ask for them only where permission exists. A supplier willing to expose confidential customer information to win your business is telling you how it will treat yours.

Also test administrative reality. Who signs the agreement — the entity you will trade with, or a paper entity? Where is the service delivered from, and what does jurisdiction mean for your regulator's view of outsourcing? These are diligence answers, and the RFP is the cheapest place to collect them before counsel gets involved.

Score it, then run the decision meeting

Score in two passes, in a strict order. First pass: mandatory gaps only. Any missing launch-blocking requirement eliminates that option, regardless of its aggregate score — a platform that cannot provide your reconciliation export does not become viable by having an excellent lobby builder. Second pass: weight the survivors on demonstrated capability, quality of evidence, dependencies named, and ownership clarity.

Then hold one decision meeting with the response matrix on the screen. Review mandatory gaps before any preference discussion. Assign an owner and a next decision date to every unresolved item — "unclear" with an owner and a date is progress; "unclear" without them is the meeting failing in real time. Structure that meeting with the operator scorecard, and if the shortlist is still contested, our vendor comparison framework shows how to break the tie on evidence rather than presentation quality.

Whatever weighting you choose, decide it before reading responses. Teams that pick weights after seeing proposals unconsciously tune them toward the salesperson they liked. Agree the rubric in the kick-off meeting, when everyone is still impartial.

A note on scale: pass marks and weights are an internal administrative detail. What matters externally is that the mandatory set exists, that it was tested on the responses, and that the rejection reasons are written down. Procurement theatre begins the moment nobody can say why a qualifier was kept.

Send it

An RFP like this takes discipline to write and very little time to answer honestly. That asymmetry is the point — it moves the supplier's effort from persuasion to evidence. Keep the document under weekly review with the response matrix, and retire rows that produce nothing but essays.

ScaleBets is a casino and sportsbook SaaS supplied as-is, with custom modifications scoped separately. Send your RFP to Trade Lab Solutions and we will respond against the current product in exactly this format — availability, evidence, dependencies, owner, exclusions.