The One-Page Brief to Send Before an iGaming Platform Call

The first call with a platform supplier usually goes one of two ways. Either the supplier runs a generic demo to a room of strangers and everyone leaves politely uncommitted, or the supplier arrives having read one page of context, brings the person who can actually answer the hard questions, and the meeting resolves something real. The difference is almost never the supplier. It is whether the buyer sent a brief beforehand. A single page, structured properly, changes who shows up and what gets decided.

After two decades on the advisory side of these conversations, I have seen the brief compress evaluations by weeks. You do not need to hand over your business plan or any confidential player data to get this effect. You need to state the operational scope clearly, separate what you know from what you are still deciding, and name the decision the call is meant to move. Here is the structure, block by block.

What the Brief Deliberately Excludes

The page works because of what it leaves out. Do not include player personal data, internal financials, or the full business plan; nothing in the structure above requires them, and a first call does not grant that level of disclosure. Do not include invented requirements to test the supplier, because a fabricated entry corrupts every later comparison. And resist the urge to pad: the moment the brief grows past one page, it joins the pile of documents nobody reads before a meeting. If a workflow cannot fit, it is by definition not one of your decisive three. Detail belongs in the follow-up materials — the RFP template when you formalise, or the operator scorecard when you grade evidence — not in the opener.

Block 1: The Project in Two Sentences

Open with what the project is, in plain terms. Are you planning a new operation, adding a brand to a group, or assessing a replacement for an existing platform? State the intended product mix — casino, sportsbook, or both — and the target markets at the level of geography and regulatory regime, since that determines which version of the product and which integrations are even a candidate.

Then address timing honestly. Is your launch date a preference, or tied to a real dependency such as a licence approval, a contract renewal, or a seasonal event? Suppliers plan resources around what you tell them, and a date that is real for a specific reason gets treated differently from a date that is a wish.

For a replacement project, add one precise line on why the review exists. "The current platform feels outdated" is useless to everyone. "We cannot reconcile sportsbook settlements without manual exports" or "our provider deprecates the API version we depend on next year" tells the supplier exactly which problem the new platform must solve — without assuming they can solve it before anyone has shown anything.

Block 2: Three Essential Workflows

Pick the three workflows that will decide whether the product fits, and write each as user, action, expected outcome. Three is a discipline, not a limit — it forces you to identify what genuinely decides the fit rather than narrating the whole operation. A supplier who sees your decisive workflows can prepare them; a supplier who sees forty requirements prepares a generic demo.

Make at least one workflow operational rather than player-facing. Player-facing screens are the easiest part of any platform and the least informative. Your decisive workflow is more likely to be a back-office settlement run, a failed-deposit recovery path, a self-exclusion enforcement, or the way your finance team consumes reporting. If an integration is essential to one of those workflows, name the provider and the required flow. If the provider is still being selected, say that too, because a defined requirement and a discovery area need different handling, and the supplier needs to know which is in front of them. The casino demo checklist and sportsbook demo checklist are good sources for which workflows tend to separate products.

Brief Section	What to Write	Illustrative Example
Project	New build, added brand, or replacement; product mix; markets; timing reason	Casino operator adding a sportsbook brand, targeting two licensed markets, launch tied to licence grant
Three workflows	User, action, expected outcome; at least one operational	Finance controller runs daily settlement across casino and sportsbook in one export
In place	Entities, advisers, contracted suppliers, technical resources — with status marked	Licence application submitted; PSP shortlisted, not contracted; internal dev available for API work
Buying decision	Evaluator, commercial approver, evidence needed, expected next step	COO evaluates, CFO signs, decision requires written scope and support terms
Open questions	Unresolved items you want the call to answer	Shared wallet behaviour between products; incident escalation path

Block 3: What Is Already in Place

List the operational reality at the right level of detail: the entity or entities involved, any adviser or operational owner, suppliers already contracted, and the technical resources your side can contribute. Then mark each item's status without flinching. An entity that is applied for is different from an entity that exists. A payment provider that is shortlisted is different from one that is contracted. A licence in progress is different from a licence held. Nothing here is confidential, and the accuracy matters enormously: suppliers build proposals on what you assert, and a proposal that assumes approvals you do not yet have will need to be rebuilt at the exact moment you have the least patience for it.

For a replacement project, add your migration position. What do you actually know about exporting balances, player records and historical transactions from the current platform? Uncertainty here is normal, but it has to be visible from the first conversation, because it changes the plan materially. The migration checklist shows the questions a supplier will ask anyway; answering them in the brief is faster.

Where two entities are involved — say, an existing licensed operation and a new group structure — say which one would contract. Suppliers need to know whose name will sit on the agreement before they can prepare anything meaningful, and ambiguity on this point stalls more evaluations than any product question does.

Block 4: The Buying Decision

End the page by naming how a decision gets made. Who evaluates the product and against what evidence? Who approves the commercial agreement, and is that the same person? What does that approver need in their hands before they can say yes — a written scope, support terms, a demonstration of one specific workflow, a reference conversation? Stating this is not a sales tactic; it is what allows a useful call to conclude with an agreed next step and a named owner rather than a vague commitment to reconnect.

Assign the page itself a single owner on your side, usually whoever runs the evaluation. Multiple editors turn a one-page brief into a committee document within two rounds, and the whole point is that it stays sharp enough to send without a meeting about it.

This block also protects you internally. When the brief says the COO evaluates and the CFO signs, nobody mistakes an encouraging demo for progress toward signature. Our piece on comparing vendors when every demo looks good covers how to grade what the call produces once you have this structure in place, and the RFP template is the natural expansion when one page is no longer enough.

Worked Scenario: A Brief That Did Its Job

Illustrative composite, not a specific client. An established casino operator wants to add a sportsbook brand and has shortlisted three platforms. Before any calls, the COO sends one page: the project is an added brand on an existing licence, timing tied to a renewal date; three workflows covering a combined settlement export, a shared wallet between casino and sportsbook, and a bonus-abuse intervention path; status notes showing the PSP contracted but the odds provider still shortlisted; and a decision line naming the COO as evaluator and the group's finance director as approver, with written scope and support terms as the evidence required. Two suppliers respond to the brief; the third sends a generic deck and is quietly dropped. In the first call with each remaining supplier, the wallet workflow is demonstrated live against the written scenario, the unresolved odds-provider question is explored by someone who knows the integration layer, and the call ends with a dated next step. Total elapsed time from shortlist to evidence-graded comparison: under three weeks. The brief did not create that outcome alone, but without it the same three weeks would have produced three demos and no decision.

One Brief, Every Supplier

If you are running several platforms in parallel, send the identical page to each. This is not laziness; it is what makes the responses comparable. When every supplier answers the same three workflows and the same status notes, their replies grade cleanly against one another, and the differences that matter — existing product versus scoped work, precise answers versus generalities — become visible without any interpretation on your part. The brief then feeds the wider comparison method in our guide to comparing vendors when every demo looks good, where the responses you collect turn into evidence grades rather than impressions.

Avoid tailoring a different version per supplier. The moment the page diverges, you are no longer comparing suppliers; you are comparing your own summaries of suppliers.

Use the Brief as a Living Document

Leave a section for open questions, and keep it honest. After each call, update the same page: answers received, evidence shown, actions and owners, and the questions still unresolved. The document then carries you through the entire evaluation — the next meeting starts from it, support and incident questions slot into it alongside product questions, and by the time you reach contract the page has become your decision record. That is the operator scorecard philosophy in miniature: same requirements, same evidence, every supplier.

When you are ready to test the format, send your brief to Trade Lab Solutions before your first platform call. ScaleBets is a casino and sportsbook SaaS supplied as-is, with custom modifications scoped separately, so the response you get will mark each workflow in your brief as existing product, scoped modification, or open question — which is exactly what a first call is for.