At 3:14 in the morning, a player's deposit fails mid-transaction. The money has left their bank but has not landed in their account. They are awake, they are anxious, and they want an answer now - not at 9am when the support team logs in. For a regulated iGaming operator, that single moment is the entire argument for 24/7 support. Someone has to pick it up, verify the transaction, and either resolve it or escalate it with a name attached.
This is the part most round-the-clock support guides skip. They treat 24/7 coverage as a switch you flip once you can afford three shifts. In practice, the hard question is not whether to offer 24/7 support - it is deciding which of your hours actually need a human, and staffing only those hours properly. Get that wrong and you either burn out a five-person team or pay €150,000 a year for coverage that sits idle most of the night.
This guide breaks the decision into four parts: what 24/7 actually means for your business, the staffing math nobody shows you, the four ways to cover the clock, and where the line between automation and a human has to sit.
Decide what "24/7" actually means for you
"24/7" is not one product. It is a set of coverage tiers, and most companies only need full human staffing on one of them.
Split your support into three tiers. Critical real-time - a failed payment, an outage, a security or account-lockout event. These need a human immediately, at any hour, because the cost of waiting is measured in money or trust lost within the hour. Standard - account questions, how-to requests, status checks. These can wait minutes, and most can be deflected by a good help article or a bot. Low priority - feature requests, billing edits, cosmetic complaints. These can wait until the next business morning with zero damage.
Now pull 90 days of tickets and segment them by hour created and by tier. Almost every team that does this finds the same shape: 70–80% of overnight volume is standard or low-priority, and only 5–15% is genuinely critical real-time. That ratio - not your revenue, not your headcount - is what decides your coverage model. You are not staffing for 24 hours of uniform demand. You are staffing for a thin band of real overnight urgency sitting on top of a large pile of things that can wait.
The staffing math nobody shows you
Covering 24 hours with one human on shift at all times is not three people. It is 4.2.
A week has 168 hours. One agent working a sustainable 40-hour week covers 40 of them. To keep one seat filled around the clock you therefore need 4.2 full-time agents on paper - before you account for holidays, sick days, training, and the overnight attrition that quietly eats support teams. In practice you need 5 to 6 people for a single always-on seat with any redundancy. Want two people on overnight for safety? Double it.
The cost follows. A fully loaded support seat in North America runs roughly $72,700 a year once you count salary, benefits, equipment, software, and management overhead. That puts genuine single-person-always-on coverage somewhere between $300,000 and $435,000 a year. Overnight roles turn over at 30–45% annually, and each replacement costs $10,000–$20,000 to recruit and ramp. This is the math that makes in-house 24/7 unworkable for most companies under a few hundred employees - and the reason the real decision is almost never "hire three people."
The four ways to cover the clock
There are only four structural ways to cover off-hours. Most companies end up combining two of them.
| Model | Best for | Real monthly cost | Main risk |
|---|---|---|---|
| In-house shift rotation | High overnight volume, sensitive data you will not send outside | €15,000–25,000+ | Burnout and overnight attrition; you carry all hiring risk |
| Follow-the-sun (distributed team) | Global user base, teams already in 2–3 time zones | Salary cost across regions | Handoff gaps between regions; no one owns the night |
| Automation plus on-call | Low, non-urgent overnight volume | Tool cost plus on-call stipends | Automation answers things it should escalate |
| Outsourced dedicated team | 200+ tickets/month needing extended or 24/7 coverage | €7,000–14,000 all-inclusive | Fails fast if your knowledge base is thin |
The model that fits is dictated by the tiering exercise above. If your critical real-time band is genuinely thin and predictable, automation plus a paid on-call rotation covers it cheaply. If that band is wide - payments, regulated transactions, real incidents - you need humans on the clock, and the only honest question left is whether you build that team or rent it.
Where the AI-human line has to sit
The generic advice - "use AI for off-hours" - is not wrong, but it is dangerously incomplete, because it never says where the boundary belongs. Here is the rule that holds up in operation: automation owns the predictable, a named human owns the exceptions, and the handoff between them is written down, not improvised.
A bot is excellent at Tier 0 deflection - frequently asked questions, status checks, password resets, order lookups. It fails the moment a situation is non-standard, high-stakes, or regulated. When a payment fails at 3am in a licensed jurisdiction, a chatbot replying "I have created a ticket for you" is not an answer - and in some jurisdictions it is not even compliant. Someone with a name, a shift, and the authority to act has to step in. The category of work AI has not touched, and will not touch soon, is exactly this: the 3am exception that requires a human who can be named on a service agreement and held accountable for the outcome.
What 24/7 actually looks like in operation
We run 24/7 L1 support for a regulated iGaming operator, and the overnight shift is where quality silently degrades unless you engineer against it. Two things break most often, and neither shows up in a sales deck.
The first is shift handoff. Context is lost between the agent going off at the end of a shift and the one coming on. A player mid-conversation, a half-investigated transaction, a known incident - if it is not recorded, the next agent starts cold and the customer repeats themselves at the worst possible hour. We fix this with a written handoff log in Jira at every shift change. It is unglamorous and it is the single highest-impact habit in 24/7 operations.
The second is escalation ambiguity. The overnight agent often does not know what they are allowed to decide alone versus what must wake someone up. Without a hard, written escalation boundary, they either over-escalate (and your engineers stop trusting the pages) or under-escalate (and a real incident waits until morning). The boundary has to be explicit before anyone works a night shift. The outcome the client actually pays for is simple: the 3am incident gets a named owner and a resolution path every time - not just during business hours.
So do you actually need 24/7?
You need genuine round-the-clock human coverage if regulated or financial transactions happen at all hours, if your users are spread across global time zones, or if an incident has real cost within the hour it occurs. If your overnight volume is low and nothing is time-critical, you can run lighter - automation for deflection plus a paid on-call rotation for the rare exception - and revisit when the critical band grows.
The expensive mistake is binary thinking: deciding you must either staff three full shifts or offer no overnight support at all. The right answer is almost always in between, and it comes straight out of your own ticket data once you segment it by hour and criticality.
If you are trying to work out which coverage model fits your volume, your risk profile, and your budget, that is the scoping conversation we have with every client. We map your ticket data to a coverage model and tell you honestly whether you need full 24/7, an on-call layer, or something in between. Book a call and get a quote →