Responsible Gambling Operations

The function's anatomy

Element	What it is	The test
Ownership	A named senior owner with authority to override commercial pressure, plus trained handlers	Can they hold a decision against the VIP team's objection — and has that ever happened?
Detection	Rule-based markers plus model ranking — the markers page	Markers fire on defined behaviours, not on staff intuition alone
The queue	Daily, ranked, SLA-clocked; each case carries its signals and history	Queue age is monitored like uptime; nothing sits unworked
Playbooks	Interventions matched to signal strength — the playbook page	Two handlers given the same case take the same first step
Hard controls	Limits, cool-offs, self-exclusion — instant, cross-brand, register-integrated where one exists	The controls survive re-registration, brand hops and payment-path edge cases
The trail	Every marker, decision and action as append-only events — reporting and audit	Any player's protection timeline reconstructs in minutes

The authority structure that makes it real

The design question that decides everything else: what happens when protection and revenue disagree about one specific player? In a functioning setup, the RG hold wins mechanically — suppression enforced at the platform gate (the same single-gate architecture as tracking and CRM), do-not-disturb visible to every outbound team, and the override path running upward to accountable seniority, in writing, rarely. An RG function that wins arguments only when the player is low-value is decoration with a queue.

Staffing and the support seam

Front-line support sees risk earliest and owns it least — the seam that fails most reviews. The operating answers: support is trained to recognise and route (not to counsel), the routing is one click with the conversation attached, and the RG queue treats support referrals as first-class markers. The same seam discipline applies to VIP managers, whose personal relationships with players are exactly where informal exceptions breed: their surface shows the do-not-disturb state, and the cockpit pattern removes protected players from their worklists entirely.

Measured like an operation

Marker-to-intervention time — the function's core SLA; distribution and tail, not just the median.
Coverage completeness — markers with no recorded action: zero, audited weekly.
Behaviour change after intervention — matched-window reads, honestly censored, per the cohort discipline.
Voluntary tool uptake — offered-and-accepted rates for limits and cool-offs; the leading indicator of a culture working.
Escalation and repeat rates — cases returning tell you which playbook steps are theatre.

Revenue effects are reported beside these — visible, never optimised. An RG dashboard whose objective function includes revenue has already answered the regulator's hardest question, badly.

Why this is on a platform vendor's Academy

Because most of the failures are integration failures, and integration is where the platform lives: the marker engine and the queue, the gate that suppression enforces, the cross-brand identity that exclusion depends on, the event trail the audit reads. An operator evaluating platforms should ask RG-operations questions with the same weight as payments questions — the pages that follow give the checklist.

Continue reading: Detection markers — what fires the queue. The interventions playbook — what happens next.

RG operations — common questions

What makes RG an operating function rather than a policy?

A queue, a clock and a name. Operationally mature RG has a daily intervention queue with SLAs, named ownership senior enough to override commercial pressure, documented playbooks per signal strength, and an evidence trail per player. A policy describes intentions; the function produces artefacts — and regulators increasingly review the artefacts, not the policy.

How should the RG team relate to CRM and VIP teams?

Structurally able to say no, and structurally informed. The suppression authority is absolute — an RG hold removes a player from every promotional flow regardless of value, enforced at the platform gate rather than by inter-team memo. The information flow runs the other way too: VIP and support teams see the do-not-disturb state (not the reasons) so no personal outreach routes around the system. The one-way rule from the data classes applies: protection signals flow into protection, never into marketing.

What does a day in the function actually look like?

A worked queue: overnight markers ranked by urgency, each case opening with the signals that placed it there, the playbook match, and the player's intervention history. The handler executes the matched step — message, call, limit conversation, escalation — records the outcome, and the case either closes with a review date or escalates. The shape is identical to every well-run queue in this Academy; the difference is that the SLA here is a duty of care.

How do you measure RG effectiveness honestly?

By outcomes the function can defend, not activity it can count. Core set: time-from-marker-to-first-intervention (the SLA that matters most), intervention-to-behaviour-change on matched windows, tool uptake when offered versus imposed, repeat-escalation rate, and the audit-facing completeness numbers — markers with no action is the one that must be zero. Revenue impact is reported alongside, never as the objective function.

Where do operators most often fail an RG review?

In the gaps between systems, not in the absence of tools: markers that fired with no recorded action, exclusions that lapsed at a brand boundary or a re-registration, promotional sends to protected players through a side channel, and an inability to reconstruct the timeline for a specific player. Every one is an integration failure — which is why this cluster keeps pointing at gates and event trails rather than at intentions.

RG as an operating function.