GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here!
Watch the launch videoWatch
The rules engine for
retail & e-commerce.
Pricing, promotions, loyalty, and commissions look like four systems and behave like one decision: read the context, apply the rules the business agreed on, return a number somebody can explain. Pick the one that is costing you now.
Your margin lives
in four different tools.
Every commerce team ends up with the same sprawl. A repricing script in the platform, a promo console from a vendor, an earn-rate sheet in finance, a comp plan in a PDF. Nobody can see the whole number a customer moves through.
A repricing job, a checkout hook, a plugin, an ERP condition table. Changing one rule means a ticket, a sprint, and a release window.
Category margin floors, promo stacking limits, earn rates, tier thresholds. Correct on somebody's laptop, copied into production by hand.
A promo tool, a loyalty SaaS, a commission app. Each with its own rule syntax, its own audit trail, and no view of the others.
four owners · four release cycles · one basket
Four decisions, four policies.
Each one runs as its own versioned policy with its own owner and its own release cadence. Start with the one that hurts, then add the rest on the engine you already trust.
Dynamic pricing
Strategy tables per category and segment, then a guardrail policy that can only narrow the result: margin floors, daily move caps, key-line locks, contract minimums.
Promotion engine
Discounts, codes, bundles, and campaign windows as decision tables, stacked in a fixed order with caps, exclusions, and a simulated cost before anything goes live.
Loyalty engine
Earn rates, burn rules, tier thresholds, and campaign multipliers your CRM team edits directly, with exclusions and channel bonuses in the same table.
Commission calculation
Marketplace take rates, vendor rebates, store bonuses, and sales comp run the same tier-and-accelerator math, versioned so a disputed payout can be replayed exactly.
One decision layer
under all four.
The same tables, the same test runs, the same approvals. The second policy takes a fraction of the time the first one did, because the integration is already there.
All four policies evaluate on the same MIT-licensed ZEN engine with a Rust core, embedded in your storefront service or called over REST, in well under a millisecond.
Pricing, trade marketing, CRM, and sales ops each own their own tables and edit them in the browser. Engineering integrates the decision layer once.
Branches, test runs on real baskets, approvals, and one-click rollback. A campaign change becomes a release with a name on it instead of a hotfix.
Retail teams usually pair these with fraud detection on the order, all on the same decision engine. Browse the full use-case library.
Start with the one
that is costing you.
Model your repricing sheet or promo matrix as a decision table this afternoon, replay last month's baskets, and see the number before anything reaches a storefront.