How to build a casino support knowledge base agents actually use
A knowledge base is useful when an agent can find the right answer during a conversation. A large folder of documents is not much help if nobody knows which version is current.
Start with the questions already reaching support
Group recent conversations by the problem the player is trying to solve. Account access, missing deposits, pending withdrawals, verification and bonus eligibility are useful starting points. For a new casino, walk through the product and list the questions each stage could create.
Prioritise frequent questions and situations where an incorrect answer has a serious consequence. Ten accurate, easy-to-find procedures can be more useful at launch than a long library of general explanations.
Keep public help articles separate from internal instructions. A player may need to understand the withdrawal process, while an agent needs the investigation steps, internal contacts and limits on what they can do.
Use the same structure for each procedure
A consistent layout lets agents find the next step without reading the whole document again. Put the conditions for using the procedure near the top, followed by the checks and possible outcomes.
Title: the problem in the player's words.
Use when: the case this procedure covers.
Check: the tools and information needed.
Next steps: what each possible result means.
Reply: wording that matches the confirmed result.
Escalate when: the boundary and the receiving team.
Owner and review date: who keeps the answer current.
Add screenshots where they help someone find a control or interpret a status. Use test data or properly redacted examples. Avoid screenshots that expose player records or internal credentials.
One article should answer one recognisable problem. Link to a separate payment or account procedure when the investigation branches, rather than copying the same instructions into several places.
Write titles people will search for
Use words an agent is likely to type during a chat. 'Withdrawal still pending' is easier to recognise than an internal project name. Include relevant alternative terms naturally in the article so agents can find it with different wording.
Ask a new team member to locate five answers without help. Watch where they search, which result they choose and what remains unclear. If they repeatedly open the wrong page, improve the title or navigation.
Give agents a simple way to report a missing answer. A request with the case type, the unclear step and the source conversation is more actionable than a message saying the documentation needs updating.
Tie macros to their source procedure
For every important macro, link to the procedure that explains when it applies. Mark details that must be confirmed before sending it, such as a payment status or whether an offer was active.
Do not let a saved reply become the only record of a policy. The internal article should explain exceptions and what to do when the normal answer does not fit. Our agent training guide includes an exercise for checking that judgement.
When the procedure changes, review its linked macros too. Updating an article while leaving an old response in the helpdesk gives the team two different answers to the same question.
Decide who approves changes
Support can write and organise the documentation, but the relevant operator team needs to confirm product rules and decision boundaries. Name an owner for payment flows, promotions, account restrictions and other topics where agents need an authoritative answer.
Keep a short change history for procedures that affect live cases. Note what changed, when it applies and whether older cases should follow a previous version. For promotions, preserve the applicable terms instead of overwriting them with the newest offer.
Brief the team on significant changes and make sure every shift receives them. An edit nobody notices does not change what players are told.
Maintain it through actual support work
Review articles when the product changes, quality checks reveal an error or agents repeatedly ask the same internal question. Also schedule a review of important procedures so neglected pages do not remain in use indefinitely.
Retire duplicate or outdated articles with a clear route to the replacement. Check links and screenshots after tool changes. Measure usefulness through successful lookups and fewer repeated questions, rather than the number of documents published.
You do not need to arrive with a finished knowledge base to work with Roundtide. We can build it with you as part of support onboarding, then maintain it alongside the live operation.