Why your first AI project should probably be the boring one
Operators with nothing in production usually want to start with the model that recommends games. It demos well internally and it is the hardest item on the list to get right cold: it needs behavioural depth per player, an experiment framework capable of proving lift, and a merchandising surface an algorithm can actually change.
A better first project is support deflection, answering the twenty or so questions that make up most of your ticket volume: where is my withdrawal, why was my bonus not credited, why does verification want another document. The reasons are structural, not fashionable.
- Ground truth already exists: ticket history is a labelled set of questions and the answers agents gave.
- The metric is unambiguous, and finance already tracks cost per contact.
- Failure is contained. A weak answer produces an escalation, not a mispriced market or a licensing incident.
- The team fits in one room: product owner, engineer, support lead.
Illustrative arithmetic, not industry data: suppose a mid-size operator handles 40,000 support contacts a month at a fully loaded cost of EUR 3.20 each, roughly EUR 128,000 monthly. Deflect 22% cleanly and you save about EUR 28,000 a month before licence and engineering costs. Whether 22% is achievable on your traffic is precisely what a first deployment exists to find out.
The twenty questions are not random. Support volume in gaming follows the money and the friction around it: withdrawals held for review, bonuses that did not credit because a wagering condition was still open, verification loops that ask for a document the player is sure they already sent. These repeat because the underlying processes repeat, which is exactly why they can be answered from a knowledge base rather than guessed at. The uncomfortable corollary is that the easy questions run out. The first tranche of deflection is cheap; the marginal ticket after that is longer, angrier and more specific, so a rate that looks healthy in week two can sag once the system is working the tail rather than the head. Plan for the curve to bend, not to hold.
The plumbing you need before anyone writes a prompt
Stalled AI projects in gaming are rarely model problems. They are integration problems discovered in month four.
One player identity. If the same person appears under different keys in the wallet, the sportsbook, the CRM and the helpdesk, every prediction describes a fragment of a person. Reconciling identity often takes longer than the modelling.
Event history with honest timestamps. Deposits, stakes, session boundaries, bonus grants, verification status, contact records. Six months is a workable minimum, and you need to know which columns were backfilled or changed meaning during a platform migration.
Written label definitions. "Churned" is a decision you make (no real-money session in 30 days, or 60) not something the warehouse hands you.
A residency map. Which tables may leave the jurisdiction, which a sub-processor may see, what must be deleted on request, and how that deletion reaches training sets and vector stores.
| Readiness signal | Why it decides the project | Warning sign |
|---|---|---|
| Unified player ID | Every feature depends on it | Tickets will not join to wallet history |
| 6+ months of events | Bonus cycles distort short windows | Only the current platform's data survived |
| Documented labels | Nothing to train or test against without them | Churn differs in CRM and BI |
| Residency map | Decides if a hosted model is usable at all | Nobody knows where inference happens |
None of this is glamorous, and that is the point. The teams that stall are not the ones that picked the wrong model; they are the ones that assumed identity, history and labels were already solved because a dashboard existed. A dashboard hides the joins that quietly drop the rows that do not match, so the numbers on screen look complete while the data underneath is not. Before trusting any of it, pull ten real players and trace them by hand across wallet, sportsbook, CRM and helpdesk. If you cannot reconstruct one person's month from the raw tables, nothing built on top of them will describe that person either.
Ninety days, shaped around evidence rather than milestones
The deployment exists to produce a number finance and compliance both believe.
Weeks 1 to 3: measure the baseline by hand. Categorise 300 to 500 recent tickets and record handling time and first-time resolution. Tedious, and the only thing that makes the later comparison meaningful. Write the intent taxonomy from what you find, not from a vendor template.
Weeks 4 to 7: build against retrieval, not memory. Ground answers in your current terms, bonus rules and payment timelines rather than model recall, and keep the document set versioned so that when a promotion changes, the answer changes with it.
Weeks 8 to 10: agent-assist before customer-facing. Let the system draft and let agents approve or reject: an accuracy signal from real staff at zero player risk, and the rejections are your best training data.
Weeks 11 to 13: limited live release with a holdout. One or two languages, one or two intents, 10 to 20% of eligible traffic, and a control group that never touches the system. Without it, seasonality takes the credit or the blame.
A holdout only earns its keep if it is large enough to separate signal from noise. When deflection moves by a few points, a control of a couple of hundred contacts a week will not settle anything before the quarter is out, so size it against the effect you actually expect rather than the traffic you happen to have. Resist the urge to shrink or disband it because the early numbers look good: the moment the control disappears is the moment you lose the ability to prove the thing paid for itself, and that proof is the whole reason the pilot was funded.
Decide early what triggers handover to a human and what the system must never attempt. Self-exclusion, affordability, complaints and account closure belong in the second list from day one.
What the first year actually costs
Vendor pricing is quoted per message or per thousand tokens, usually the smallest line in the budget. Illustrative planning figures for a hypothetical mid-size operator, EUR, twelve months:
| Line | Illustrative annual cost | Note |
|---|---|---|
| Model or platform usage | 25,000 | Often under a fifth of the total |
| Engineering time | 90,000 | Integration, retrieval, monitoring |
| Knowledge-base upkeep | 30,000 | Someone owns the answers permanently |
| Compliance and legal review | 20,000 | Impact assessment, per-market checks |
| Evaluation and QA | 25,000 | Sampling, red-teaming, regression sets |
Against roughly EUR 190,000 of cost, the deflection example returns about EUR 336,000 a year at full scale, but only after ramp, and only if quality holds once the easy questions are exhausted. Model a partial year and a 12% case too. If it only works at the optimistic number, it is a bet rather than a project.
Compliance is a design input, not a sign-off at the end
Responsible-gambling signals should flow one way. A model that can see markers of harm must not also feed marketing selection, and that separation belongs in the data layer, not a policy memo.
Keeping harm signals out of marketing selection reads like a policy line until you see how easily it breaks in practice. A shared feature store is the usual culprit: a churn or value model quietly reads the same behavioural aggregates that a responsible-gambling model uses to flag risk, and now the segment picked for a reactivation bonus overlaps with the segment showing markers of harm. Nobody chose that outcome, the plumbing produced it. The separation has to be enforced where the features live, with distinct lineage, or it will be re-broken every time someone adds a table and reuses a column that looked convenient.
Automated decisions affecting a player (refusing a payout, restricting an account, denying a bonus) generally need a documented human review path and an explanation the player can understand.
Everything must be reconstructible: model version, retrieved documents, prompt, output, timestamp, and who saw it. Auditors ask what the system told a named player on a given date, and "we have since updated the model" is not an answer.
Generated marketing copy takes the same approval route as human copy, and bonus terms must be verified against the source system rather than paraphrased by a model. Any conversational surface needs hard-coded behaviour for self-exclusion mentions, distress signals and complaint language: stop, hand over, log.
How to tell a real result from a dashboard illusion
Deflection measured as "chats with no agent involved" counts everyone who gave up and left. Pair it with re-contact within 72 hours and complaint volume: if re-contact rises alongside deflection, you moved cost rather than work.
The re-contact window matters because abandonment and resolution look identical at the instant a chat closes; only the player's next few days tell them apart. Deflection climbing while re-contact and complaints stay flat means you genuinely removed work. Deflection climbing while both follow it upward means you taught players to give up: cheaper this month, expensive the quarter after when they charge back, complain to a regulator, or simply stop depositing. A single deflection figure cannot distinguish the two, which is why it should never travel alone.
A retention model targeting the highest churn probability often spends bonus money on players who were staying anyway. What you want is uplift, the difference the intervention makes, which needs a randomised control inside the targeted segment.
Write the failure condition before launch: if deflection is under 8% or re-contact rises more than two points by week 10, the project stops or is rescoped. Pilots without a stopping rule survive on narrative.
What to leave until the second or third project
Real-time pricing needs latency guarantees, market-data quality and a risk framework most first-time teams lack. Autonomous campaign spend removes the approval step exactly where advertising rules bite. Individually generated bonus offers create terms legal never reviewed. Systems that can freeze, refund or close accounts should wait until logging and rollback are mature.
Harm-detection models are the partial exception: build them early if you can, but as decision support routing a case to a trained human, never as a gate acting alone.
If a summit is where you shortlist vendors
A trade show compresses vendor evaluation, and the separating questions are dull. Where does inference run, and can it be pinned to a region? Can we export the knowledge base and evaluation set if we leave? What does your logging schema look like?
Questions operators ask before their first deployment
Do we need a data scientist to start? Not for a retrieval-based support project: an engineer comfortable with APIs and evaluation, plus a support lead with authority over the answer base. Churn and fraud scoring do need modelling skills.
Build or buy? Buy the first one. The purpose is learning whether the use case pays, and a vendor gets you there in weeks.
How much data is enough? For support, a few thousand resolved tickets and current documentation. For churn, six to twelve months of behaviour and a written label. If the answer is "we will collect it as we go", fix the pipeline first.
Will regulators object to AI in player-facing channels? Objections concentrate on unexplained automated decisions, weak audit trails, and marketing that reaches players showing harm markers. Grounded answers, logged outputs and a handover path address most of it. Confirm the position for each licence.
What sinks these projects most often? No baseline. Without hand-measured before-numbers every later result is arguable, and arguable results are not funded twice.