Sportsbook Software: What to Ask Beyond the Odds Screen

There is a moment in almost every sportsbook demo where the presenter lands on the event page — live odds ticking, markets in rows, a bet slip animating — and waits for approval. Approve it if you like. But recognise what you have seen: the display layer, the part of the system with the least operational consequence. The parts that determine whether your sportsbook survives its first month — acceptance logic, settlement evidence, service boundaries, staff permissions — are all behind that screen.

A sportsbook software evaluation should cover what happens before a bet is accepted, while it is open, and after settlement. This checklist walks through each stage with the questions that matter, plus the combined-operation issues that appear when casino shares the account. It assumes you have already written down the sports, markets and operating model you need — treat catalogue availability as something to verify for your project, never assume it from a generic presentation.

Map the service boundaries first

A sportsbook is not one thing. It is, at minimum: an odds data feed, a pricing and trading operation (which may be your staff, the vendor's managed service, or a third party), the betting software itself, and the account and settlement layer. Before any demo, ask the supplier to state in writing which of these the offer includes and which sit outside:

• Who supplies the data? The odds and results feed is a commercial relationship of its own. Included, or contracted separately?
• Who sets and manages trading rules? Margins, limits, market suspension behaviour. If a managed trading service is involved, identify exactly which decisions it takes on your behalf.
• Who escalates operationally? When a market is mispriced or a feed fails mid-event, which party owns the response, and what do your staff see of it?

These boundaries determine everything downstream. If your intended operating model involves your own traders adjusting liability, say so before the demo — the vendor should not have to infer your staffing, risk responsibilities or market coverage from a slide deck. And ask each answer to come with the contract that backs it. "The feed is available" and "the feed is included" are different claims.

Test a change in state before acceptance

Here is the scenario that separates a scripted demo from an examination, and it takes five minutes to run. Agree a test in which the available terms change between the player viewing a market and submitting the bet. Then ask:

• What does the player see — a re-offer at new odds, a rejection, or silent acceptance at the revised price?
• How is the decision recorded, and can support retrieve that record later?
• Where is the acceptance behaviour configured, and can it be set to match the rules you intend to operate under?

Run the same scrutiny on an illustrative in-play sequence (marking it as synthetic): a bet placed in-play, the market suspended seconds later, the bet still open. What does the player's history show during suspension? What can support say to the player from the back office without contacting anyone else? The purpose of these tests is validation — learning how the system behaves under your intended rules — not catching the vendor out. A platform that handles the scenario transparently and documents the rules it applies has told you something genuinely useful.

Set the risk and limit questions in writing

Acceptance behaviour connects directly to risk controls, and risk controls are where "the platform manages that" most often turns out to mean "a separate service manages that, under terms you have not seen". Cover these in writing before the demo, then watch them operate:

• Player-level limits. Stake limits, win limits, per-market restrictions, and profiling rules. Who can set and change them — your risk staff, a managed trading desk, or only the vendor?
• Market and event liability. How is aggregate exposure viewed, and can your team set thresholds that trigger suspension or referral?
• High-stakes handling. What happens above a defined stake level — accepted, referred for manual approval, or rejected — and what does the player see while the referral queue is pending?
• Trading responsibility. If a managed service is bundled, which of the above it operates on your behalf, and what visibility you retain of its decisions.

None of these questions presume that one operating model beats another. They presume you know which model you are buying. An operator with in-house traders needs configuration access; an operator outsourcing trading needs contractual delegation with auditable records. The demo must prove whichever applies to you.

Examine settlement — the record, the correction, the void

Settlement is where operators feel the difference between platforms most acutely, because every sport generates exceptions: postponed fixtures, results amended on appeal, official sources disagreeing. Ask to see a settled bet's full record, then a corrected or voided one:

• What links the bet to its result — the specific feed event and settlement timestamp, or a manual action?
• If a correction or void is required under your operating rules, who is authorised to initiate it, and does the player's account history explain the adjustment to them?
• Can finance reconstruct settled turnover by event and market for a given day, with adjustments itemised — in an export, not a chart?

The last point matters more than most buyers expect. A settlement report you cannot tie to the wallet ledger is a support ticket generator. Your finance team will reconcile these numbers monthly; make sure the fields exist before the contract does. The reporting and reconciliation guide covers the output formats worth demanding, and applies to the sports side just as much as casino.

A worked settlement exception (illustrative) frames the test well: a settled win is reversed because the official result feed later amends the event outcome. Walk the trace. The original settlement entry, the reversal, the adjustment, the player notification — does each step carry a timestamp, a source, and an operator or service attribution? Can support replay that chain to the player in plain language, and can finance filter exactly these correction events out of the monthly reconciliation rather than discovering them inside a variance? If corrections arrive invisible, your support and finance teams will find each other waiting.

Pre-match breadth means little; your markets mean everything

Suppliers quote the size of their fixture catalogue the way supermarkets quote aisle length. The number that matters is narrower: availability, margin structure and limits on the specific sports and markets you intend to promote, in the jurisdictions you will operate. Take your own top-ten event list — the fixtures your acquisition plan actually depends on — and have the demo run against it. For each, confirm the market depth offered, who provides the pricing, any market-level restrictions in your jurisdiction, and how the fixture behaves when the feed degrades: does the market suspend cleanly, or does it stay open on stale prices?

This is also the moment to test in-play handling properly. In-play is where acceptance latency, suspension timing and settlement source quality all interact at once. An illustrative check: bet submitted in-play, price moves during the acceptance delay, event resolves moments later. The record should show the price at submission, the acceptance decision, the timing and the settlement source — all retrievable by support without escalation. If any step requires contacting a trading desk you do not control, that handoff belongs in your dependency register with an SLA question attached.

Put your operations lead in the chair

Have the person who will run day-to-day operations attend, and have them drive. Give them a realistic support question — a player disputing a settled accumulator, say — and let them work it through the back office while the presenter observes. What you learn from this is not the vendor's competence; it is your workload. Count the systems touched and the handoffs required. If an investigation needs three external tools and an email to a trading desk, document that as an operating cost of the offer and name the escalation owner.

Review staff permissions while you are there, and treat view and change authority as separate requirements. Can support see the trading rationale for a suspension? Can they re-grade a settled bet, and if so, does the audit trail capture who did it with what reason? Structure this however you like, but write it down — the operator scorecard has sections for exactly this. Permissions discovered after go-live tend to be discovered by a regulator or an angry player first.

Where casino shares the account

If your project combines casino and sportsbook, do not leave the relationship between them to assumption. Shared login is not shared wallet, and shared wallet is not shared restriction logic. Have the supplier demonstrate, with synthetic accounts, three specific behaviours:

• A balance moving between verticals — one ledger, a transfer step, or separate balances entirely?
• A bonus restriction — does wagering progress on casino games count against a sports bonus, and what does the player's view claim?
• A self-exclusion or account restriction applied on one side — does it propagate to the other, and what happens to an open bet slip at that moment?

Any dependency that could change your launch scope goes on the record, classified as demonstrated, configurable, third-party, or development work. Keep that distinction clean: a demonstrated function and a development request must never merge into one line called "available". The shared wallet guide expands these tests, and the casino demo checklist covers the casino-side scenarios that pair with this one.

From demo to decision

Close the evaluation the same way you would for casino: a written record of demonstrated behaviour, open questions with owners and due dates, and the service boundaries confirmed in writing. Leave with evidence, not with impressions of the event page. If you are still at the shortlist stage, the platform selection guide sets this demo inside the full buying sequence.

ScaleBets is a casino and sportsbook SaaS supplied as-is, with custom modifications scoped separately — so the answers it gives to this checklist arrive in the same categories the checklist uses: what is demonstrated is what is supplied, and anything beyond it is a separately defined item. Review the platform against your requirements, and bring these scenarios with you when you do.