How to RFP a retail decision platform

Most retail decision-platform selections are decided before the contract is signed — by the structure of the RFP itself. A buyer assembles a requirements matrix and scores three or four vendors on model accuracy and a feature checklist. A proof of concept runs in a clean scope, and the highest total wins. Six months after go-live, the platform produces recommendations the floor ignores.

The RFP was rigorous. It simply tested the wrong things. A decision platform fails or succeeds on operational adoption and execution — and a feature-and-accuracy grid measures neither. This guide gives you a reusable RFP structure that selects on what actually determines the outcome.

What the RFP should actually test

The instinct in a technical RFP is to test capability: how accurate is the model, how many features does it carry, how fast does it run. Those questions feel objective and they produce clean scores. But they answer a question that production has already settled — every serious vendor on your shortlist can predict demand well enough. The variable that decides the project is what happens after the prediction.

What separates platforms in production is whether the decisions get executed, consistently, by people who didn't build the tool. A platform whose recommendations are executed at 80% on the floor beats one whose model is two points sharper but whose output gets overridden or ignored.

Adoption is the real currency, and it depends on things a capability test never surfaces. How cleanly the platform plugs into your systems. How it handles your business rules. Whether the output is an executable action or a screen someone still has to act on.

This is the same confusion that kills data projects after a successful POC — optimising the means instead of the end. We unpack the pattern in the three classic mistakes that kill retail data projects, and an RFP designed around accuracy quietly reproduces the first of them. So before writing a single requirement, settle the premise: the RFP exists to predict adoption and execution under your real conditions, not to rank predictive performance. Every section below follows from that.

It also helps to be precise about what category you are actually buying. A decision platform is not a sharper BI tool or a better forecasting engine — it is a distinct layer that arbitrates and executes. If your shortlist mixes the three, your scores compare unlike things. The distinction is drawn in decision platform vs forecasting platform vs BI, and it's worth resolving before the grid goes out.

The questions that separate vendors

A good RFP is mostly a short list of questions that vendors cannot answer with a demo. Generic capability questions get generic confident answers. The questions below force a vendor to either show real depth or expose a gap. Ask for evidence, not assertions — an architecture diagram, a reference, a recorded execution, not a slide that says "yes".

1. Integration depth — bidirectional, not export. Ask exactly how the platform writes decisions back into your ERP, WMS, and pricing systems, in what format, at what latency, and what happens on partial failure. A platform that only reads your data and emits a file or a dashboard has pushed the hardest half of the work onto you. The integration question is where most of the unbudgeted industrialisation cost hides, so make the vendor name the connectors and the failure modes.

2. Business-rule handling — embedded, not filtered. Your margin floors, supplier minimums, commercial calendars, and store-cluster logic are not optional context — they decide whether a recommendation is executable. Ask whether rules are embedded in the engine or applied as a filter after the optimisation. Ask how a new rule gets added six months after go-live, and by whom. A platform that needs a vendor ticket to change a margin floor will not keep up with your business.

3. The execution loop — decision to floor to feedback. Ask the vendor to walk one real decision from data to executed action to measured result. Make them show where a human validates or overrides, and how the outcome of an executed decision feeds the next one. A platform that produces recommendations but cannot close the loop leaves you with the same manual follow-up you have today. The closed loop is the difference between a recommendation and a decision — the architecture is described in what is a decision layer in retail.

4. Adoption track record — at your scale, in your conditions. Ask for a reference at comparable store count and assortment complexity, and ask that reference one question: what percentage of the platform's recommendations does your floor actually execute, and how did that number move over the first two seasons? A vendor who cannot connect you to a live reference able to answer that is selling a POC, not a production system.

5. Time-to-value — first executed decisions, not first dashboard. Ask when the platform produces its first executed decisions on a real scope — not when the first screen lights up. The gap between "deployed" and "producing decisions the floor acts on" is where projects stall for quarters. A credible vendor will name a timeline in weeks for a bounded scope and tie it to operational milestones, not to integration sign-off.

The structural traps in RFP design

Even buyers who ask the right questions undermine themselves with how the RFP is structured. Three traps recur, and each one quietly steers the selection toward the wrong vendor.

The ideal-condition POC. The most common trap is a proof of concept run on a clean, narrow scope with a dedicated team and hand-cleaned data. Almost every vendor passes it, because the POC removes exactly the conditions that break platforms at scale — messy data, fuzzy rules, heterogeneous teams, real latency. A POC in ideal conditions tells you a platform can work; it tells you nothing about whether it will work in your production.

Insist on a POC under real conditions — same systems, same data quality, same teams — on a restricted scope. If it doesn't hold there, it won't hold at scale.

The feature-checklist score. A long requirements matrix scored line by line rewards the vendor with the most features, not the vendor whose decisions get executed. Two platforms can tie on a 120-row checklist while one drives adoption and the other dies in a spreadsheet. Feature parity is real but secondary; weight it accordingly, and never let the checklist total be the decisive number.

Treating integration and change management as out of scope. RFPs routinely fence off integration as "a later IT workstream" and change management as "an HR or consulting matter". Both are then discovered, unbudgeted, at scale-up — and both determine adoption far more than the model does. Pull them inside the RFP. Score the vendor's integration plan and their co-deployment approach as first-class criteria, not appendices.

A fourth, quieter trap: scoring the vendor's slide deck instead of their system. Demos are rehearsed on perfect data. Anchor every score to evidence you can verify — a reference call, a real-data POC, a live execution — rather than to how convincing the presentation was.

A reusable evaluation grid

Translate all of this into a weighted grid before the first vendor responds. The weights are the real decision — they encode what you believe predicts production success. Bias them hard toward adoption and execution, the two factors that actually move the outcome, and treat predictive performance as a qualifying threshold rather than a differentiator.

Two rules make the grid honest. First, treat predictive performance as pass/fail above a threshold, not as a sliding score. Once a model is good enough that the decision doesn't flip on the second decimal, more accuracy buys nothing. The point is argued in from forecasting to decision: why ML isn't enough.

Second, make the adoption and integration rows depend on verifiable evidence, not vendor claims. A row that can be filled from a slide is a row that selects the best presenter.

Used this way, the grid puts roughly 60% of the weight on adoption and execution and about 15% on raw prediction — the inverse of a typical accuracy-and-feature RFP. That single reweighting is usually the difference between selecting the vendor whose decisions reach the floor and the vendor whose model wins the demo and loses the season.

Run the RFP that selects on outcomes

The vendors worth shortlisting will welcome this structure, because it lets a production-ready platform separate itself from a polished POC. The ones who resist a real-conditions POC, can't name their connectors, or can't connect you to a reference on adoption are answering the question for you.

Solya is built to be evaluated this way. Business rules embedded in the engine, native bidirectional execution into ERP, WMS and pricing, and a deployment measured on executed decisions rather than dashboards. The point of the grid, though, is not to favour any one vendor. It's to make your selection turn on the things that determine whether the platform produces margin a year from now.

If you're structuring a selection now, the most useful move is to write the weights first. Decide what you believe predicts production success before any vendor tells you — then let the grid hold the line.

---

Building a decision-platform RFP?

At Solya, we offer retail data and operations leaders a personalized 30-minute diagnostic. We pressure-test your selection criteria before they go out — vendor-neutral, grounded in your own systems and scale. You'll walk away with:

• A review of your draft RFP weighting against what actually predicts adoption
• The integration and rule-handling questions most likely to expose a gap on your shortlist
• A real-conditions POC design that won't flatter every vendor equally