Documentation Index
Fetch the complete documentation index at: https://setup.cevro.ai/llms.txt
Use this file to discover all available pages before exploring further.
AI Procedures (AIPs) define how Cevro should handle specific types of player requests—checking withdrawal status, explaining bonus terms, processing account changes, and more.
Not every conversation needs an AIP. Cevro can handle many requests using just your Knowledge Base, general escalation rules, or responsible gaming protocols. AIPs are for when you need a specific procedure—clarifying questions in a particular order, evaluating conditions, interpreting backoffice data, or branching based on outcomes.
Creating an AIP
Navigate to Workspaces → AIPs → Create New to open the AIP editor.
Core Fields
| Field | Purpose |
|---|
| Name | How the AIP appears in your list (e.g., “Withdrawal Status”) |
| Description | Tells Cevro when this AIP applies — what the player is asking or experiencing, in their language. The single most important field for correct routing. See Writing the Description for the full guidance. |
| Instructions | Step-by-step guidance for handling the request |
| Example Utterances | 3 sample phrases that would trigger this AIP |
| Category | Groups AIPs for organization |
| Tags | Labels applied to conversations when this AIP matches |
Group by Theme, Not by SymptomInstead of one broad “Deposit Issues” AIP (too vague) or hyper-specific ones for every variation, group by theme:
- Deposit Visibility — Player can’t see their deposit (pending, delayed, not showing)
- Payment Method Issues — Player can’t complete a deposit with a specific method
The test: Would the same procedure and backoffice lookups apply? If yes, group them together.
Writing Instructions
Instructions are the heart of an AIP. They tell Cevro exactly how to handle the scenario.
The Mention System
@ Mentions — Type @ in the instructions editor to open a dropdown with three tabs:
| Tab | What It Contains | Purpose |
|---|
| Player Context | Data from your backoffice | Look up player info, balances, transactions |
| Knowledge | Articles from your knowledge base | Reference specific help content |
| Actions | Things that change state | Escalate, route, close, add tags |
# to mention a human specialist for HITL requests. This is only visible if HITL is enabled for your workspace.
Example instruction using mentions:
Check @withdrawalStatus for pending withdrawals.
If found:
- Share the status and expected timeframe
- Reassure the player it's processing
If delayed beyond 7 days:
- @Transfer to Live Agent
If player disputes the status:
- #Payments Team: Player claims withdrawal was submitted but not showing. Please verify.
Best Practices
Be direct and sequential
Check @playerBalance for available funds.
If sufficient:
- Confirm withdrawal is possible
- Explain processing time
If insufficient:
- Explain the shortfall
- Suggest deposit options
If player provides a transaction ID:
- Look up that specific transaction
- Provide detailed status
If no transaction ID:
- List recent withdrawals from @recentTransactions
- Ask which one they mean
Escalate if:
- Issue is unresolved after checking all relevant data
- Player reports a discrepancy between their records and ours
- Request requires manual override
Behavior Settings
Below the instructions editor, you’ll find tabs for configuring AIP behavior.
Player Auth Tab
Toggle Require Player Authentication to verify the player’s identity before proceeding.
This toggle auto-enables when your instructions reference Player Context that requires authentication. You can’t disable it in that case.
Smart Delegation Tab
Controls how Cevro handles escalation for this AIP:
| Option | Behavior |
|---|
| Default | Cevro decides when to escalate based on the conversation |
| Escalate to Human | Immediately routes to a human agent |
| Do Not Escalate | Cevro handles fully, never escalates |
Referencing Knowledge Base Articles
When you type @ and select the Knowledge tab, you can reference specific Knowledge Base articles in your instructions. This is useful when:
- Procedures need reference data — A “Payment Method Issues” AIP might reference an “Accepted Payment Methods” article so the AI can look up which methods work and explain rejections
- Storing brand-specific info — Knowledge Base articles are segmented by brand, so you can store brand-specific details and reference them
Multi-brand awareness: The Knowledge tab shows which brands have each article using fuzzy matching (so “Accepted Payment Methods” and “Payment Methods Accepted” are grouped). You’ll see something like “10 brands have this, 2 brands missing”—helping you identify content gaps to fill.
Draft, Published, and Active States
AIPs have two dimensions of state:
Draft vs Published
| State | Used in Production | Editable |
|---|
| Draft | No | Yes |
| Published | Yes (if active) | No (read-only) |
Active vs Inactive
Published AIPs can also be toggled Active or Inactive:
- Active — Used in live conversations
- Inactive — Exists but won’t trigger
This is useful for:
- Temporarily disabling an AIP without deleting it
- Gradual rollouts (start inactive, activate when ready)
- Brand-scoped behavior (see below)
Brand-Scoped Patterns
Combined with brand variants, active/inactive enables powerful patterns:
- Default inactive + one brand active: AIP only applies to that specific brand
- Default active + one brand inactive: AIP applies everywhere except that brand
Available Actions
When you type @ and select the Actions tab, you’ll see:
| Action | What It Does |
|---|
| Transfer to Live Agent | Escalates to a human agent |
| Route to AI Procedure | Switches to a different AIP mid-conversation |
| Close Ticket | Ends the conversation |
| Add Tags | Applies labels to the conversation |
| Send External Message | Sends a message to an external channel |
Brand Variants
For multi-brand workspaces, you can create brand-specific variations of an AIP:
- Base AIP — Default behavior for all brands
- Brand Variant — Overrides for a specific brand (different instructions, Player Context, etc.)
This lets you maintain one AIP structure while customizing responses per brand.
See Brand Variants for details.
Example AIPs
With Player Context
Name: Withdrawal Status
Description: |
Player asking about a withdrawal that is still pending or processing.
Use only when the withdrawal hasn't yet been completed or sent. Do
not use for cancellation requests or for withdrawals already
approved but funds not received.
Instructions: |
Check @withdrawalStatus.
Look for withdrawals where status is "pending" or "processing".
If found:
- Share the withdrawal amount and request date
- Explain: pending = submitted, processing = being reviewed
- Provide expected timeframe (24-48 hours for pending, 1-3 days for processing)
If status is "failed" or "rejected":
- Explain the reason from the failureReason field
- Guide them on next steps
Authenticate: Yes
With Procedure (No Player Context)
Name: Bonus Terms
Description: |
Player asking about wagering requirements, bonus playthrough rules,
eligible games, or expiration dates for a specific bonus. Do not
use for missing-bonus issues, eligibility for a new promotion, or
generic bonus complaints.
Instructions: |
Ask which bonus or promotion the player is asking about.
Reference the Knowledge Base for relevant terms.
Explain:
- Wagering requirements
- Eligible games
- Expiration dates
If player disputes terms or claims terms are different than stated, escalate.
Authenticate: No
Name: Account Closure
Description: |
Player requesting to permanently close their account, including
self-exclusion requests. Do not use for temporary account locks
or password reset issues.
Smart Delegation: Escalate to Human
Design Tips
One AIP per intent, with conditional logic inside
A common mistake is creating two separate AIPs for the same core issue when one of them just adds an extra step before handing off to the other.
Example: A player reports a compromised account. Some players also ask for a refund. You might be tempted to create:
- AIP 1: “Refund request due to compromised account” — decline the refund, then route to AIP 2
- AIP 2: “My account has been compromised” — security steps, account closure
The problem: when AIP 1 hands off to AIP 2, important content from AIP 1 (like the refund decline) can get lost in the transition. The AI plans to send it but doesn’t always include it in the final response.
Instead, use one AIP with conditional handling:
Name: My Account Has Been Compromised
Description: Assist players reporting compromised accounts, including refund requests
Instructions: |
STEP 1 — If the player mentions a refund or compensation:
- Decline clearly, citing Terms & Conditions
- If they don't mention a refund, skip this step
STEP 2 — Escalate for account closure
STEP 3 — Provide security steps
STEP 4 — Ask if they have questions
Avoid overlapping descriptions
If two AIPs have similar descriptions, the AI may pick the wrong one. Each AIP should cover a clearly distinct scenario. When two AIPs cover related topics, add explicit “do not use for X” exclusions to disambiguate. When in doubt, merge them and use conditional logic in the instructions.
For the full description-writing guidance — the three-element formula, density window, and anti-patterns — see Writing the Description.
Troubleshooting
| Issue | Check |
|---|
| AIP not triggering | Is the description clear? Are example utterances accurate? Is it published (not draft)? |
| Wrong AIP matched | Is there overlap with another AIP’s description? |
| Player Context not working | Is authentication enabled? Is the backoffice integration configured? |
| Not escalating when expected | Check Smart Delegation settings. Review escalation criteria in instructions. |
| Content missing after routing | If AIP A routes to AIP B, check whether AIP A’s content should instead be a conditional step inside AIP B. See Design Tips. |
