iGaming Platform Support: Read the Incident Process Before Signing

Every iGaming platform sales deck has a slide that says 24/7 support. After two decades of watching operators sign contracts, I can tell you that slide tells you almost nothing about what happens at 21:40 on a Saturday when your sportsbook odds feed freezes during a live match. What matters is the incident process: who you call, what the clock measures, who owns the problem when the cause is unclear, and what you get in writing afterwards. None of that is on the slide. All of it is discoverable before you sign.

Support quality is the clause operators skim and the one they live with daily after launch. The checks below cost you one honest conversation with a prospective supplier and a careful read of the service schedule. Do them, and you will know more about the working relationship than any reference call will tell you.

Define the Service Being Supported

Before you read a single response-time figure, write down which parts of the proposed service the supplier actually owns. A typical iGaming stack involves hosting, the platform application itself, and a ring of external integrations: game providers, payment processors, odds feeds, KYC services. Each of those can fail independently, and the support answer differs for each.

Ask the supplier to draw the boundary explicitly. Which components do they operate and support directly? Which are third-party services they host or broker on your behalf? Which are relationships you hold separately, where their role ends at an API endpoint? This is not pedantry. When a payment provider's API starts rejecting deposits, the first question is whose job it is to find out why.

The hardest incidents are the ones where nobody yet knows the cause. Players cannot deposit. Is it your PSP, the platform's payment orchestration layer, or a routing change somewhere between them? Your operation needs a route for investigation before fault is established. Confirm that route exists, confirm what information the supplier needs to start working, and confirm they will engage even while responsibility is still being determined. A supplier who only acts once you have proven the fault is theirs has handed you the triage job.

Read Response Commitments Carefully

Three different outcomes get called support targets, and suppliers are not always precise about which one they are quoting:

• Response: someone qualified acknowledges the ticket and starts work. Fast, cheap to promise, and the most commonly quoted number.
• Workaround: service is restored by a temporary measure. The root cause is still live. This is often the outcome that actually saves your trading day.
• Resolution: the underlying fault is fixed. This is the slowest and the one that matters for recurring problems.

When a document says severity-1 issues get a one-hour target, ask which of those three the hour measures. Then ask when the clock starts: on your ticket, on their acknowledgement, on the next business morning? Which hours apply, and in whose time zone? A target that runs Monday to Friday, 09:00 to 17:00 in the supplier's home office, is a very different product from one that runs around the clock.

Severity classification deserves the same scrutiny. Most agreements use a three- or four-level scale. The definitions need examples, and they need a rule for disagreement, because there will come a day when your team calls something severity-1 and the supplier's duty manager reads it as severity-2. Who arbitrates, and how fast? A workable severity table looks something like this:

Severity	Typical Definition	Illustrative Example	What to Confirm
Severity 1	Service down or core revenue path blocked	Bets cannot be placed; deposits rejected across all methods	Response, workaround and escalation targets; who can declare it
Severity 2	Major function degraded, workaround exists	One payment method failing; reporting delayed but trading live	Update frequency and who owns third-party liaison
Severity 3	Limited impact, no immediate revenue risk	Back-office display fault; single-user access issue	Queue position and typical fix cycle
Service request	No fault; a change or question	New admin account, configuration query, report request	Whether requests sit inside or outside the SLA entirely

One more trap: do not treat the sales chat window as the contractual support service. During evaluation, everyone answers fast. The question is which channel the signed agreement names, who on your team is authorised to use it, and whether severity-1 requires a phone call, a ticket keyword, or a named duty contact. Write the authorised-contact list into your onboarding plan and keep it current when staff change.

A Worked Scenario: The Saturday Night Odds Feed

Illustrative scenario, not a client story. Your sportsbook is live. At 21:40 on a Saturday, in-play odds stop updating across all football markets. Players can still log in, so it does not look like a full outage. Your duty manager raises a ticket.

Run the clock through your draft agreement. If the agreement measures response from ticket creation around the clock, and a feed issue with betting still open qualifies as severity-1, you should have a qualified engineer engaged within the stated window. If the definitions only count full service unavailability as severity-1, the supplier may legitimately classify this as severity-2, and your response target just doubled or tripled while live betting exposure grows. If the clock pauses overnight or outside business hours, you may be waiting until Monday for what your business needed in twenty minutes.

Now add the ownership question. The odds feed comes from an external provider. If the platform hosts that integration, their team should be driving the investigation and the provider liaison while keeping you updated. If the feed contract is yours, you may be the one calling the provider, in which case you need the platform's diagnostics to even describe the fault. Two operators with the same platform and the same incident can have completely different nights, purely because of how the boundary was drawn in the contract. That is why this conversation belongs before signature, not during the incident.

Check Change and Incident Communication

Incidents are only half the communication problem. The other half is planned change. Ask how your team learns about scheduled maintenance: how far in advance, through which channel, and addressed to whom. A notice that lands in a sales contact's inbox does not reach the people staffing your trading floor at 06:00. Ask whether maintenance can run during your peak hours and whether maintenance time counts against any availability commitment in the agreement.

During an incident, who receives updates and how often? For anything player-facing, your support and social teams need a cadence they can rely on, because silence from the platform becomes angry players on your public channels. If multiple suppliers are involved, ask who consolidates the status. Somebody has to be the single source your operation reads while it decides whether to suspend a market or message players.

After a significant incident, ask what investigation record you receive. The document you want states what failed, when it was detected, what was restored and when, and which follow-up actions have named owners and dates. Some suppliers call this a post-incident review or root-cause report; the name matters less than the commitment. If it is promised, it belongs in the written agreement. Recovery objectives are worth the same treatment: if the agreement references recovery time or recovery point objectives for your data, make sure both are defined in language your technical team can verify, not left as initials in a schedule.

Uptime Numbers Without the Fine Print

An availability percentage is only as honest as its exclusions. When a proposal quotes a figure, ask three things. First, the exclusions: does scheduled maintenance count against the number, and do third-party provider failures get carved out? Second, the measurement: is availability measured from the supplier's own monitoring or from a page you can see, and does a player-facing status page exist that your team can check without filing a ticket? Third, the remedy: if the figure is missed, what actually happens? Some agreements offer service credits; others offer a report and an apology. Neither is necessarily disqualifying, but you should know which one you are signing. The same discipline applies to recovery commitments: if the documents mention RTO or RPO for player data and balances, have your technical staff confirm the definitions and how they are evidenced, rather than accepting the acronyms as reassurance.

Prepare Your Side of Support

Support is a two-party process, and suppliers can only meet their side if yours is organised. Before launch, settle these items internally:

• Named operational contact and backup. The person authorised to declare a severity-1 and reach the supplier's escalation path, with a deputy for leave and shift boundaries.
• Evidence discipline. Define what your staff capture when something breaks: timestamps, affected player segments, transaction references, screenshots. Agree what can be shared safely, and strip unnecessary player personal data before it goes into a ticket.
• Access for the people on duty. The severity-1 route is useless if only your CTO has the credentials and your CTO is asleep. The on-duty team needs the channel, the credentials, and the runbook.
• An internal escalation mirror. Who inside your business gets told, at what severity, and who has authority to suspend markets, pause campaigns, or message players while the supplier works.

Then, during onboarding, run a tabletop exercise. A team member follows the documented process end to end using a clearly labelled test request agreed with the supplier in advance. You are not trying to catch anyone out; you are checking that the route works, the evidence requirements are workable, and the right people answer. Gaps found here are free. Gaps found during a live incident are not. Do not manufacture a real production failure to test a supplier; a labelled test achieves the same learning without the player impact.

Fold the exercise results into your launch readiness checklist alongside the rest of your operational sign-off, and score the supplier's incident process as part of your wider evaluation using the operator scorecard.

Where This Leaves You

A support agreement you can rely on has four properties: the service boundary is drawn, the targets say which outcome they measure and when the clock runs, the communication plan covers maintenance and incidents in both directions, and your own side is staffed and authorised to use it. Everything else is decoration.

When you evaluate ScaleBets through Trade Lab Solutions, bring this list. ScaleBets is a casino and sportsbook SaaS supplied as-is, with custom modifications scoped separately, and the support terms are confirmed against your proposed agreement before you commit, including the incident process, the escalation path and the maintenance arrangements for your specific setup. That is the conversation to have before signing, not after the odds feed freezes.