v2.0

GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here!

Watch the launch videoWatch
gorules
Book a demoGet started

A loyalty engine
your CRM team can edit.

Earn rates, burn rules, tier thresholds, and campaign multipliers live in visual decision tables instead of your commerce platform's checkout code. Your CRM team edits the rules, replays real baskets to see the accrual impact, and ships the change the same day with approvals on the record.

From tier-down list
to retained, same day.

Watch a Monday in a CRM team: 412 Gold members flagged to tier down, a one-cell change to the save window, a replay over 3,180 historical tier-downs, a signed release - and a membership card that updates itself before the member notices it was ever at risk.

scroll to play
Monday, 08:15

412 Gold members are on their way out.

The nightly run flags every Gold member short of the retention threshold. M-41706 is 380 qualifying points short, with 12,400 points expiring in 30 days.

The member

Four years Gold. Short by 380 points.

C. Mensah has spent $18,240 with the program, $630 of it in the last 90 days, down from $1,180. The save email goes out with nothing in it.

One cell

The head of CRM gives the save offer teeth.

The failing rule opens the live tier rules. For Gold with points expiring, earn goes from 1.0x to 2.0x for a 30 day window - on a branch, Platinum untouched.

Proof before production

3,180 tier-downs replay.

Last quarter's tier-downs re-run against the draft while you watch: 64 percent re-engage at the historical save-offer response, at $8.40 per retained member against a $12 cap.

Sign-off

CRM approves. v2.6.0 ships.

Priya Shah signs the release, it promotes through staging to production with the full trail recorded. Rollback stays one click away.

Same day

The pass updates itself.

C. Mensah spends $210 at 2x, clears 12,000 qualifying points and keeps Gold. Gold at risk goes from 412 to 96 - except the member who has been quiet for 180 days.

The program is marketing's.
The rules are engineering's.

A loyalty engine is supposed to be the one place earn, burn, and tier rules live. In most retailers it is three places at once: accrual logic inside the commerce platform's checkout code, a redemption service someone wrote for the app, and a spreadsheet of campaign multipliers the CRM team keeps for the quarter. So a double points weekend is a deploy, a category boost is a ticket, and the person accountable for the program cannot change the rules the program runs on.

Both of the usual escapes cost more than the problem. Build the logic into the commerce platform and it belongs to one channel: POS, app, call center, and partner sites either duplicate the rules or go without them, and they drift within a quarter. Buy a monolithic loyalty suite and the engine arrives bundled with a member database, a rewards catalog, a portal, and a messaging tool you already have, plus a replatforming project and a vendor queue standing between your team and every threshold change.

Then finance asks questions the code cannot answer. Points issued are a balance-sheet obligation: under IFRS 15 and ASC 606 unredeemed points are deferred revenue, and the breakage estimate behind them has to be supportable. Which rule version awarded the points on this quarter's accrual? Who approved the 5x weekend? Which basket lines counted toward tier and which were excluded?

When the answers live in a checkout service and someone's spreadsheet, every campaign post-mortem, every audit, and every replatform starts with archaeology.

Program logic out
of the checkout path.

GoRules is the decision layer of your loyalty stack: transaction in, points and tier movement out, every rule readable by the people who own the program.

01

Earn, burn, and exclusions as decision tables

Accrual is naturally a matrix: member tier by product category by channel by campaign window, resolving to an earn rate and whether that spend counts toward tier. GoRules decision tables are that matrix, edited spreadsheet-style. Rows evaluate top to bottom under the first-hit policy, so exclusions like gift cards, shipping, tax, and returned lines sit above the rates and win by position. Burn is the mirror table: redemption eligibility, point value, minimum balance, blackout windows, and partial-pay limits. ZEN expressions handle rolling-window math such as trailing 12-month qualifying spend, and typed TypeScript function nodes cover anything custom.

02

Tier progression you can retune without a migration

Model qualification as a Policy, an ordered set of blocks: the qualification window (calendar year, rolling 12 months, or anniversary), what counts as qualifying spend, the threshold per tier, and the downgrade rule, including soft landings where a member drops one level instead of falling to base. Natural-language rendering turns each rule into a sentence the program manager, the finance partner, and the member-services agent all read the same way, which matters the day someone calls to ask why they lost Gold.

03

Campaign overlays without a release train

A double points weekend, an app-exclusive 1.5x, a category boost on slow-moving stock: each is a branch on the live program, not a change to checkout. Git-like version control gives every campaign its own history, approval workflow, and one-click rollback, and the simulator replays real baskets through the change so you see points issued and tier movements before members do.

Keep the ledger.
Move the rules.

Your commerce platform still takes the order and your loyalty ledger still holds balances. GoRules owns the decisions between them.

01

Connect

Checkout, POS, the mobile app, and your CRM call GoRules over REST at accrual and at redemption, or you embed the MIT-licensed open-source ZEN Engine in the service that owns the points ledger, with SDKs for Node.js, Python, Java, Go, C#, and Rust. One ruleset serves every channel instead of a copy per codebase.

02

Model

Rebuild the program as tables and graphs: the earn matrix, the exclusion rows above it, tier qualification and downgrade, and the burn rules that price a redemption. Member attributes, basket lines, channel, and campaign flags arrive as plain inputs, so the outcome stays deterministic and reviewable.

03

Simulate

Branch a change and replay last quarter's transactions through both versions. Compare points issued, tier upgrades and downgrades, and projected liability before anything reaches a member, then trace any single basket through every node that touched it.

04

Operate

Promote through dev, staging, and production with an approval recorded at each step. Every accrual returns the rules that fired, so member services can explain a balance instead of guessing, and a campaign that misprices rolls back in one click.

Built for production,
not proof of concept.

  • Sub-millisecond evaluation with the open-source ZEN engine (Rust core), fast enough to sit inline in checkout and show earned points before the customer confirms the order
  • Git-like version control on the program: a branch per campaign, full commit history, approval workflows, and one-click rollback when a multiplier misfires
  • Self-host with Docker or Kubernetes so member profiles and transaction data stay in your infrastructure and inside your data-residency scope, or run on GoRules Cloud
  • Every accrual, redemption, and tier movement traces to the rules that fired, and every rule change records who changed what and when. SSO, RBAC, and SOC 2
  • No lock-in: the core engine is open source under MIT, and 70+ industry templates, retail among them, give your program a working starting point instead of a blank canvas

Questions, answered.

What is a loyalty engine?

A loyalty engine is the rules layer of a loyalty program: the component that decides what a transaction earns, whether that spend counts toward tier, which tier a member holds, and what a redemption costs. It is separate from the member-facing program, the points ledger that stores balances, and the catalog that fulfills rewards. Most engines ship as configuration buried inside a larger suite or as code inside the commerce platform, which is why earn-rate and threshold changes usually mean a vendor ticket or a release. GoRules provides the engine on its own, as visual decision tables and graphs your CRM team edits directly, called over REST or embedded in your service.

What is the difference between a loyalty engine and a loyalty platform?

A loyalty platform is the whole product: member database, points ledger, rewards catalog, member portal, campaign messaging, analytics, and an engine somewhere inside it. The engine is only the decision part, and it is the part that changes weekly. Buying the platform to get the engine means a replatforming project and a vendor between your team and every threshold change, while building the engine into your commerce platform ties the rules to one channel. GoRules replaces the engine and nothing else, so your ledger, catalog, CDP, and commerce platform stay where they are.

Can our CRM team change earn rates and tier thresholds without an engineering release?

Yes. The earn matrix, exclusion rows, tier thresholds, and campaign multipliers are decision tables edited in the browser, and natural-language rendering keeps every rule readable for whoever signs off on it. GoRules AI can draft a rule change, run the tests, and explain why a given basket earned what it earned. Changes still move through branch, simulation, approval, and versioned promotion, so nothing reaches production without sign-off and any release rolls back in one click.

How do you stop campaign multipliers from stacking into runaway accrual?

Precedence is row order. Under the first-hit policy a decision table evaluates top to bottom and stops at the first match, so an exclusion row above the rates cannot be overridden by a campaign below it, and a campaign row placed above the tier defaults replaces them rather than compounding with them. Where a program genuinely does stack, a collect-policy table returns every match and a capping rule bounds the total, for example a points ceiling per basket or per member per month. Before any of it ships, replay historical baskets through the change and compare points issued against the current program.

How does GoRules support points liability reporting and audits?

Unredeemed points are deferred revenue under IFRS 15 and ASC 606, and the breakage assumption behind them has to be supportable, so finance needs to know precisely which rules issued which points. Every evaluation returns the rules that fired, every rule change is versioned with author, timestamp, and diff, and every release is a numbered snapshot you can point at when reconstructing a period. You can also simulate a proposed change against historical transactions to see the accrual impact before it reaches the balance sheet. GoRules supplies the traceability; the accounting judgments and reporting obligations remain yours.

The same engine,
next door.

One decision layer serves the whole institution - these use cases run on the same tables, versioning, and audit trail.

Promotion EngineDiscounts, stacking, and margin floorsDynamic PricingThe same decision layer for priceCommission CalculationTiers and accelerators for payouts

Change the multiplier.
Not the release train.

Model your earn matrix and tier thresholds in the visual editor today, or send us the accrual rules you run now and we will show them back as decision tables.

Get started Book a demo