What the feature actually is
A casino bonus isn't a coupon code. It's a business rule with real economic stakes: who qualifies, under what conditions, which games count toward the wagering requirement, at what rollover multiplier, within which time window, up to what maximum payout. Configured wrong, the operator loses money to bonus abuse. Configured too narrowly, the promotion doesn't reach the players it's meant for.
The existing tooling at MakEntWin let operators configure basic bonuses: flat amounts, simple time windows, single conditions. Anything more complex meant either a rigid template or an engineering ticket. Every promotional campaign the operator wanted to run was a negotiation between what the business team imagined and what the system could express.
The ask was to close that gap. Build a configuration UI where the operator could express, in the product itself, the full range of business rules they wanted to run: without engineering involvement, without rigid templates, and without having to draw the rule tree on a whiteboard first.
Where I came in
I was the sole designer on MakEntWin's Backoffice, which made this project solo-owned from requirements through final handoff. The PM defined the business logic scope (which rule primitives to support, which variable types to expose). Engineering ultimately had to build a backend capable of evaluating arbitrarily nested rule trees. My job sat in the middle: translating a rule language into a UI that a non-technical operator could actually use.
"Non-technical operator" is the critical framing. The primary user isn't a developer, isn't an analyst, isn't a data person. It's a promotions manager. Someone who thinks in business outcomes ("I want a Weekend bonus that only triggers for players who deposited this week and haven't withdrawn in 48 hours"), not in boolean logic. The UI had to close the gap between business language and rule trees without asking the user to learn rule-tree syntax.
The shape of the solution
The feature is a three-step wizard that decomposes bonus configuration into three independent concerns:
Step 1. Bonus Template. Metadata: name, dates, risk group, KYC requirements, usability caps (N uses per day / week / month / year), timezone handling, per-language rich-text content, and asset uploads (desktop and mobile imagery). Everything the operator would set once and rarely revisit after launch.
Step 2. Activation rules. The rule engine itself. Activators (top-level triggers) hold sub-activators (nested conditions), each with their own rule configuration. Trees can go to any depth. The UI renders as a horizontal chip tree: each level is a row of chips, "R" badges on chips indicate a rule is attached, dashed outlines indicate empty slots waiting to be filled. Selecting a chip opens a master-detail configuration panel on the right.
Step 3. Eligible games. Which games this bonus applies to, and how each game weights toward the wagering rollover. Slots might count 1x, premium branded games 3x. Configured as a filterable game picker with a results table. Operators can add rules by game type, vendor, or specific title.
The three-step separation matters: metadata, logic, and game eligibility are three different cognitive tasks, and forcing them into a single form would have produced exactly the overwhelm I was designing against.
Three decisions that mattered
5.1. Chip tree over nested forms
Nested forms break at depth 3. The rule engine had to stay readable at depth 5+. So the UI is a horizontal chip tree: each level of nesting is its own row, selection opens a configuration panel on the side.
Read more
The default pattern for rule builders is a nested form: indented conditions, expandable groups, AND/OR combinators between siblings. It works at two or three levels. It breaks at five, because the human eye loses track of which sibling group it's looking at, and the scroll distance between related rules grows faster than the UI can absorb.
The chip tree flattens the depth dimension. Each nesting level is its own labeled row ("Available Activators," "Sub-Activator of 'Required Deposit'," "Sub-Activator of 'Weekend'"). Activators at each level are chips, which are small, uniform, scannable. A "R" badge indicates a rule is attached. A dashed outline indicates an empty slot the operator can fill.
The tradeoff: the chip tree hides the configuration details behind a click. You see the shape of the rule tree at a glance but have to select a chip to see its configuration. For a non-technical user configuring complex logic, that's the correct tradeoff. The shape matters more than the details at the scanning level, and details are one click away when needed.
The master-detail panel on the right handles that click. It surfaces the full rule configuration (variable type, thresholds, timing, modifiers) for the currently selected chip. Configure, save, move to the next chip.
5.2. Separating "Activator" from "Rule"
An Activator answers "when does this fire?" A Rule answers "under what conditions?" Separating them lets the operator reason about triggering and qualification as two distinct layers, not as one tangled boolean.
Read more
An obvious-looking design for a rule engine is to collapse activator and rule into a single concept: every node in the tree is "a condition." It's technically correct (any rule tree can be expressed that way), but it asks the operator to think like a developer. "Does the player deposit trigger this, or is it a requirement? Both?"
Splitting the concepts resolves the ambiguity before it happens. Activators are the triggers: the events that make the system evaluate whether a bonus should fire. Rules are the qualifications: the conditions the player must satisfy when a trigger fires.
The UI reflects the split. Activators live in the tree structure, forming the outline of "when." Rules attach to activators via the master-detail panel, describing "who qualifies." Non-technical operators took to the model quickly. It mirrors how they already think about promotions: "Every Saturday and Sunday (trigger), for players who've deposited $125+ (rule), who haven't withdrawn in the last 48 hours (rule)."
5.3. Eligible games as its own step, not a rule primitive
Game eligibility isn't a condition, it's a scope. Treating it as a separate wizard step keeps the rule engine focused on player-state logic and lets the operator configure game-level economics independently.
Read more
Game eligibility could have been expressed as rules inside the rule engine: "if game.type == 'slot'" etc. It would have been elegant from a technical standpoint.
It would have been terrible for the operator.
Game eligibility has completely different ergonomics than behavioral rules. It's a list-based operation, not a conditional one. Operators think about it as "which games does this bonus apply to, and how much do they count," not as "if-then" logic. Forcing them to express game selection as a rule tree would have required learning a logic they don't use for this concern.
So game eligibility is Step 3, not part of Step 2. It's a filterable picker with a results table. Add by game type, by vendor, or by specific title. Set the rollover multiplier per entry. No nesting, no combinators, no logic tree. The rule engine handles player-state logic; the game picker handles game-level economics. Two different tools for two different jobs.
This split is also what makes the rule engine cleaner. By pulling game eligibility out, Step 2 only has to express player-state and temporal logic, which keeps the chip tree from getting overloaded with game selectors that don't belong there.
What shipped, what changed
The bonus configuration system shipped and is in production across the operator's portfolio of casino brands. Non-technical promotions managers configure bonuses directly in the tool, without engineering tickets. Complex campaigns that previously required either a rigid template or a developer now get built by the business team in an hour.
I don't have quantified adoption metrics on this one. MakEntWin operates as a single-operator platform, which means "adoption" looks different than multi-tenant SaaS. What I can say is that the tool has been the primary way new bonuses are built on the platform since launch, and that the three-step decomposition has held up across every promotional campaign the operator has run through it.
Looking back
Operators don't build the deep rule trees the system supports. Most bonuses use two or three levels of nesting; the engine's unbounded-depth capability is rarely exercised. The feature shipped with more headroom than the use case needs, and that's worth thinking about.
Read more
When I designed the chip tree, I designed for the worst case: operators configuring promotions at 5+ levels of nested conditions. The UI had to stay legible there. I built the interaction around that ceiling.
In production, the ceiling doesn't get touched. Most bonuses that ship use two or three levels of nesting: a trigger, a condition or two, and a qualification. The rule engine's full depth remains a capability the operator knows about but doesn't reach for.
That's not a failure of the design. A flexible tool doesn't become wrong when users don't use its full range. But it is a useful observation. It tells me the actual operator mental model for promotions lives closer to templates than to arbitrary logic trees. Five or six common bonus patterns account for most of what they build; the rest is variation.
What I'd do differently: If I were scoping this project today, I'd pair the rule engine with a template layer. Operators would start from a named pattern ("Weekend bonus," "First deposit match," "Reactivation") and adjust parameters, rather than compose a tree from scratch. The rule engine would still exist underneath for the edge cases that don't fit a template, but the primary interaction would be template-driven. That's a cheaper, faster path to the same business outcomes for 80% of promotions, and it would respect the actual operator workflow instead of designing for a ceiling they don't use.