Why 80% of retail business rules are misused in data systems

In every chain I meet, the same scene eventually replays. A merch director opens a report produced by the planning tool or a predictive model, looks at the recommendation, and drops a weary "no." "We never mark down this brand before W+10." Or: "That supplier doesn't take returns within 60 days." Or: "On this store cluster, the margin floor is 35%, not 25%."

The recommendation is technically correct. Statistically optimal. And, in practice, unusable. Because it ignores part of the context the merch director carries in their head, and that the system never integrated.

This scene, multiplied a thousand times across every chain, is one of the most stubborn causes of retail data project failure. You invested in models, platforms, dashboards — and you keep steering by hand, because systems don't know how to factor in real business rules. "Optimal" recommendations get sidelined, tools get bypassed, Excel files persist. And nobody really understands why.

The explanation holds in a few words: in most chains, business rules are neither formalized, nor integrated, nor executable. They live in people's heads, in PowerPoint files, in email chains. They get bypassed by data systems, not applied. And it's this blind zone — less technical than organizational — that separates a stack producing slides from a stack producing performance.

This article looks straight at this business-rules question: what they really are, why they're so badly used, and what to do so they stop being the blind spot of data projects.

What a retail business rule really is

Before going further, let's set a definition. A business rule isn't a technical parameter. It's not a simple preference either. It's an encoding of operational experience, which constrains, orients, or forbids certain decisions based on what the chain has learned over the years.

A few concrete examples among hundreds:

• "On brand X, we don't mark down before week 10 — price image is too sensitive."
• "Premium-cluster stores never apply the same markdown tiers as the standard network."
• "Supplier Y takes back up to 8% of invoiced volume, but only within 60 days after season end."
• "On sub-family Z, we protect a 38% margin floor, even if it means holding stock."
• "Inter-store transfers in this category are allowed, except between different regions — unless logistics cost is under €3 per unit."
• "During official sale periods, we don't run private markdowns — we respect the legal framework."
• "We never apply a discount above -50% in the first phase — beyond, we send to outlet."

Each of these rules has a history. It came from a past mistake, a supplier negotiation, a positioning strategy, a legal constraint, customer feedback, a commercial arbitration. Taken in isolation, each looks innocuous. Combined, they form the chain's operational nervous system — what makes it itself, and not another.

The problem is that this nervous system is almost always unwritten, unformalized, not executable by a system. It lives in the heads of a few experienced people, and gets transmitted, poorly, by apprenticeship. Data systems don't know about it.

Why data systems fail to integrate these rules

You have to understand the failure mechanics, because it's almost always the same. Four reasons chain together.

Reason #1: rules are never exhaustively collected

When a data project starts, rules obviously get collected. Business sponsors are involved, workshops organized, a list is drawn up. This list typically contains thirty to fifty rules — what participants have in mind that day.

Except in operational reality, the chain applies hundreds, even thousands. Many never surface in workshops because they're too tacit — "obviously we do it this way" — or too specific to a case not raised in the session, or carried by teams that weren't invited. Result: the system is calibrated on 5 to 10% of real rules. For everything else, it produces recommendations that silently violate the house know-how.

Reason #2: rules are hard-coded, not parameterized

When rules do get integrated into a system, they often go in hard — written in a script, frozen in an initial setting, entangled in application logic. Consequence: as soon as a rule evolves (supplier change, new positioning strategy, seasonal adjustment), it takes development, an IT ticket, a release cycle. Several weeks, sometimes months.

In modern retail where rules constantly move — every supplier negotiation, every commercial operation, every regulatory shift produces adjustments — this delay leaves systems structurally out of phase with reality. Teams end up bypassing the tool because it can't keep pace.

Reason #3: rules are treated as uniform constraints

Classic data systems treat rules as global parameters. "Margin floor at 30%", "minimum delay before markdown of 8 weeks", etc. But reality is almost always contextual. Margin floor isn't the same depending on brand, store cluster, sub-category, the product's commercial history. The delay before markdown depends on seasonality, positioning, local competition.

When a system doesn't carry this contextual granularity, it produces two symmetric error types: it applies the rule where it shouldn't (too restrictive), and ignores it where it should be applied more strongly (too permissive). Teams see both errors, lose trust, and take back manual control.

Reason #4: rules conflict, and nobody arbitrates

The last reason, the subtlest: in real life, business rules contradict each other. The margin floor says "don't mark down past -35%." The cover rule says "don't hold more than 12 weeks of stock." On a dormant product, these two rules become incompatible — you have to violate one or the other.

In a human organization, these conflicts get arbitrated case by case, by an experienced merchandiser who knows which rule wins in which context. In a classic data system, the conflict produces either a deadlock (no recommendation possible), or a silent violation of one rule (without knowing which). Both are bad — and durably erode team trust in the system.

The hidden cost of permanent bypass

What happens when a data system doesn't know how to factor in business rules? Teams bypass it. Quietly, systematically, without saying it too loudly in steering committees.

Concretely, here's what the real life of a data project poorly aligned with business rules looks like. The platform produces its recommendations daily. The merchandiser opens them in the morning. They look, filter, discard 60% of the rows because they violate constraints the platform doesn't know about. They re-export the remaining 40% to Excel for processing with their own rules. They end up producing a final decision combining, in an opaque mill, what the platform suggested and what their experience corrects.

This bypass has four major costs.

First cost: you lose most of the productivity gain. The point of an automated platform is to handle low-stakes decisions at scale to free human time for high-stakes decisions. If the merchandiser has to review every row, the gain disappears. The platform becomes an additional layer of work, not a layer of efficiency.

Second cost: you lose consistency. Manual corrections, made in Excel, don't follow uniform logic. Tuesday, the merchandiser applies rule X. Thursday, distracted, they apply it differently. Over a year, the network accumulates inconsistent decisions no reporting surfaces because they're drowned in the mass.

Third cost: you lose traceability. When a decision is taken in Excel after platform bypass, there's no audit trail. Nobody can, six months later, understand why a particular markdown was at -35% rather than -25%. Any possibility of retrospective learning disappears.

Fourth cost: you lose trust. The more bypass takes hold, the more teams consider the platform "can't do it" — when in reality, it was never given the means to. The consequence is durable: even if the system is improved later, trust, once lost, is extremely long to regain.

At a chain's scale, these cumulative costs amount to hundreds of thousands of euros in lost productivity, and several margin points left on the table — without anyone ever linking these losses to the root cause: poorly integrated business rules.

The wrong fix: encode more rules

Faced with this observation, the natural temptation is to say: "we need to encode more rules." You launch a new project, document, develop, update the parameterization. It's useful, but almost always insufficient. For three reasons.

First, encoding more rules into a static logic doesn't solve the update problem. If every rule evolution requires an IT ticket, the initial encoding effort will be cancelled by the drift of subsequent weeks. Six months later, the system will again be misaligned with reality.

Next, multiplying rules in a system that doesn't know how to arbitrate their conflicts worsens the problem. The more rules there are, the more they contradict, the more deadlocks or silent violations multiply. At some point, the system becomes unmanageable.

Finally, the key point: business rules aren't a secondary layer to stack on a system. They must be a first-class citizen in the architecture, designed to be declared, versioned, tested, arbitrated, monitored — like code, but accessible to business teams. It's an architectural choice you can't catch up with late-added parameters.

What to build: a real business-rules layer

A modern retail decision platform can't settle for a "settings" tab with a few sliders. It must carry a real business-rules layer, organized around five principles.

Principle 1: declarativity. Rules must be writable by business teams themselves, in a language they understand — "on brand X, margin floor at 38%, outside sale periods" — without needing development. It's the condition for rules to keep pace with reality.

Principle 2: contextual granularity. A rule must be able to apply at a precise level — that brand, that store cluster, that sub-family, that period — and have variants by context. Not one uniform rule, but a family of parameterized rules.

Principle 3: hierarchy and arbitration. When two rules contradict, the system must know which wins, and make it explicit. No silent violation, no absolute deadlock: documented arbitration, based on configurable hierarchy.

Principle 4: observability. Teams must be able to see, at any moment, which rules are active, which were triggered on which decision, and which were violated (and why). Without this observability, trust doesn't settle in.

Principle 5: versioning and history. Rules evolve. The system must keep version history — who changed what, when, with what consequence on decisions — to enable retrospective learning and rollback if needed.

A platform carrying these five principles radically changes project dynamics. Business teams are no longer at the system's periphery — they're at the center, because they define the grammar of decisions. Data scientists provide the predictive bricks, but it's the business rules, formalized and executable, that turn these predictions into actually applicable decisions.

The organizational question: who owns the rules?

You have to complete this analysis with a point often forgotten. A modern business-rules layer is useless if nobody is explicitly responsible for its quality.

In most chains, business rules are the diffuse property of several people — a bit of merch, a bit of pricing, a bit of buying, a bit of commercial leadership. This dispersion means nobody carries responsibility for their formalization, update, arbitration. As long as this situation persists, any platform — however sophisticated — will end up drifting from reality.

Chains that succeed in their data transformation almost all share a characteristic: they identified an explicit role — sometimes called Business Rules Owner, sometimes attached to a Retail Operations function — whose mission is to keep the business-rules layer alive. Not to code it themselves, not to replace business experts, but to orchestrate their formalization, ensure their consistency, and ensure that evolutions flow in real-time into the system.

It's a modest organizational investment, but it's the key factor separating data projects that durably produce value from those that run out of steam after six months.

The Solya approach: making business rules the system's heart

That's exactly Solya's philosophy. Not a platform "with" business rules added as an option, but a platform built around business rules as a first-class citizen.

Concretely, Solya integrates the chain's rules — margin floors, supplier constraints, commercial calendars, brand- or store-cluster specific handling, regulatory arbitrations — into its decision engine. These rules are declarative, accessible to business teams without technical intermediary, parameterizable by context, hierarchizable in case of conflict, and fully traceable.

The result is concrete. Recommendations produced by Solya respect the chain's rules by construction — not as a filter applied after the fact, but as a constraint embedded from formulation. Teams no longer spend 60% of their time correcting inapplicable recommendations: they arbitrate the truly complex cases, where their expertise creates value. And when a rule evolves — new supplier contract, new positioning strategy, seasonal adjustment — the update happens in minutes, not weeks.

Beyond the technical, it's a stance shift. Solya considers that the chain's know-how isn't an obstacle to automate, it's the main asset to industrialize. Business rules aren't frictions to minimize in models — they're the foundations that let the system produce decisions both optimal and applicable.

The real question to ask

How many of the rules your teams apply daily are effectively encoded in your data systems? If the answer is "a fraction", you understand why your data platforms, however sophisticated, haven't produced the expected operational impact.

The problem is almost never model quality. It's the system's inability to integrate real operational know-how — the kind that turns a theoretically optimal recommendation into a concretely applicable decision.

Fixing this gap isn't perfecting algorithms. It's making business rules what they should always have been: a first-class component of the architecture, declarative, contextual, versioned, observable. It's this transformation, more than any other, that separates retail data projects durably producing margin from those that end up as unused dashboards.

---

Are your business rules really in your systems?

At Solya, we offer retail leadership teams a personalized 30-minute diagnostic to assess, on your own context, the gap between the business rules actually applied by your teams and those embedded in your data stack — and quantify the productivity and margin potential recoverable by closing that gap.

👉 [Book your Solya diagnostic] — 30 minutes, by video, with one of our retail experts.

You'll walk away with:

• A map of business rules currently outside your data systems
• An estimate of time lost in manual bypasses by your teams
• The first high-ROI use cases to integrate your business rules as first-class citizens in your steering