Customer Support

Players open a support conversation without leaving the product, and agents answer from a real support console. The support surface is built in your design system — it is not an embedded third-party chat widget, and nothing on screen names the vendor behind it.

What the player sees

A Support section listing their conversations, split into active and resolved, each showing what it is about and whose turn it is:

Opening one gives a normal chat screen: message history, sender distinction, timestamps, a composer, and file attachments. On wider screens a compact launcher carries an unread count on every page and opens a help hub; on phones, Support sits in the navigation and account menu, with an unread dot. Either way a reply is noticed without the player going looking for it. The support screens are translated into all five player languages.

Status is written in product language, not the vendor's. A conversation the support team has not answered yet reads Waiting for support; one waiting on the player reads Waiting for you. The player is never shown a raw vendor status such as pending or snoozed.

Starting a conversation

The support panel opens on a hub titled "How can we help?": a grid of topic tiles that each start a request, the player's open conversations beneath them (unread badge or status, time), and a link to all conversations. The topics are:

Deposit or withdrawal · Verification / KYC · Bonus · Casino or game issue · Sports bet · Account · Responsible gaming · Something else

The category travels with the conversation, so the support team knows what a request is about before reading it.

Support that already knows the context

Support can be opened from the thing the player needs help with. Every withdrawal row carries a Get help action, and a crypto deposit that is held or failed offers one too; using it opens a conversation already tied to that withdrawal or deposit — the player never has to explain which payment they mean, and the agent does not have to ask.

Refusals the player cannot clear themselves (a verification block, a betting limit, a region block, a game that is unavailable) also offer Get help. These open a conversation with the right category preselected and the screen they came from recorded, but no entity is attached: the internal ids behind an error are deliberately never put in an error message.

Bets, games and other entities can use the same subject pattern; withdrawals and deposits are the ones wired today.

What the support team gets

Agents work in Chatwoot's standard console: an inbox, replies, assignment, transfers between teams, private notes, labels, conversation status, history, and canned responses. That is deliberate — support tooling is a solved problem, and building a second one would be a poor use of the budget.

Two things extend it:

Category routing. A verification question can go to the verification team, a payment question to payments, a responsible-gaming request to the team trained for it. Routing is configuration, not code.

A player context panel. Agents can see who they are talking to — player ID, account status, VIP tier, jurisdiction, KYC status, the transaction under discussion, and recent activity — read live from the platform at the moment the agent looks. It is never copied into the support vendor.

What is deliberately not shared with the vendor

The platform stays the system of record. Chatwoot holds the conversation and a small set of identifiers; it does not hold balances, deposit or withdrawal amounts, bet history, KYC documents, or responsible-gaming state.

What crosses the boundary is limited to support-useful, low-sensitivity fields: an internal player ID, jurisdiction, language, VIP tier, account status, KYC status, and — per conversation — the issue type and the ID of the entity being discussed. No monetary amount is ever sent. The agent sees the €500 through the context panel, read live from the platform, not because it was handed to a third party.

Player-to-player privacy is enforced on the platform side: a conversation is resolved against the signed-in player before anything is fetched, so one player's support history is unreachable from another's session.

Attachments

Players can attach an image or PDF to a message — a screenshot of an error, a receipt. Files are checked by content rather than by their name, size-capped, and passed straight through to the support console without being stored on the platform. Files an agent sends back are served through the platform behind the player's session, so a leaked link is not a leaked document.

Running it

Support is off by default and switched on per deployment with one setting (CHATWOOT_ENABLED). While it is off, the player site hides every live-support entry point — the sidebar and account-menu entries, the footer link, the floating launcher and the unread polling — and the contact page says support is off instead of linking to it. A direct visit to the support page, or a Get help link, shows "Live support is unavailable", and any attempt to start a conversation is refused cleanly rather than failing with a "please try again" that could never work.

The vendor's free tier is enough for the entire player-facing experience: conversations, messages, attachments, identity verification and live updates all work on it. Two things need a paid plan — routing conversations to teams and the agent context panel — because both use an API the free tier does not issue credentials for. Without them the support channel works normally and conversations land in a single shared inbox; enabling them later is a configuration change, not a rebuild.

The integration is written against the vendor's public API behind an internal boundary, so moving from their cloud to a self-hosted install is a change of address rather than a rewrite. Self-hosting removes the paid-plan limits above, at the cost of running the service yourself.

Operational setup — the inbox type, identity validation, the required credentials and the self-hosting path — is documented for whoever deploys the platform.

Scope & Roadmap

Implemented. In-product conversations in your own design system with categories, product-language statuses, attachments and unread counts; contextual Get help from withdrawals, held or failed deposits and blocking errors; a help hub with topic tiles; category routing and a live player context panel for agents (paid vendor plan or self-hosted); a strict data boundary that never sends monetary amounts to the vendor.

Partial. Contextual help carries an entity for withdrawals and deposits only; bets, games and other entities use the same pattern but are not yet connected.

Not built. No support tooling of the platform's own — agents work in the vendor's console. Support is off until a deployment configures it.