Retail pricing optimization software: an RFP that works

Most retailers buy retail pricing optimization software through an RFP. Procurement wants a fair process. The board wants a paper trail. The vendors want a shot. Everyone gets a 100-line spreadsheet and three weeks to fill it in.

Then the answers come back. Every vendor is "compliant" on almost every line. The scores land within a few points of each other. The decision gets made on price, or on whoever gave the best demo. Twelve months later, the team is back in Excel.

This is not a rare outcome. Gartner surveyed 3,484 software buyers and found that 60 percent regretted a purchase made in the previous 12 to 18 months. The top vendor-side reasons were not missing features. They were a poor handoff from sales to implementation and expectations that were mismanaged during the sale. Both are things a well-written RFP can catch before you sign.

This memo is for the CCO, CFO or COO who has to run a pricing and promotion software tender and wants the answers to mean something. For what these tools do and how they differ, start with our complete retail guide to price optimization software. If a tender is required, here is how to write one vendors can answer honestly.

Why retail pricing optimization software RFPs go wrong

An RFP fails when it measures what vendors say instead of what they can do. Three design choices cause most of it.

Binary answers. A "Yes / No" column invites every vendor to write "Yes". A capability that works for one store and one category is a yes. A capability that ships next year is a yes with a footnote nobody reads. The column flattens real differences into noise.

Feature lists instead of decisions. "Supports elasticity modeling" tells you nothing. Every serious vendor has some elasticity model. What you need to know is whether your category manager can see why a price changed, and whether the model holds up on your sales history.

Equal weight for everything. When "multi-language interface" and "price approval workflow" carry the same score, the vendor with the longest list wins. That is rarely the vendor your team will use.

The fixes are not complicated. They do require procurement and the commercial team to agree on them before the document goes out.

Replace yes/no with a four-level compliance scale

Ask every vendor to place every requirement on one of four levels:

• Fully compliant - works in the product today, in production, with no custom development.
• Partially compliant - part of the requirement works today. The vendor must say which part, and what is missing.
• Roadmap - not in the product today. The vendor must give a release date it will commit to in the contract.
• Not compliant - not available and not planned.

This scale does two things. It makes partial answers visible, which is where most of the real differences between vendors live. And it rewards honesty. A vendor that marks 20 lines as Roadmap with dates is telling you more than a vendor that marks everything as Yes.

Add one rule: every Partially compliant answer must state what is met today and what is not. Every Roadmap answer must carry a month and year. Answers without these get scored as Not compliant. You will be surprised how many "Yes" answers turn into "Partial" once the vendor knows the follow-up question is coming.

Gate on a short list of Must-Haves

Split requirements into Must-Have and Desired. Then keep the Must-Have list short. A third of the requirements is already a lot.

Must-Haves should be gates, not points. A vendor that fails a Must-Have with no committed date is out, whatever its total score. This stops a long tail of Desired features from outweighing the few things the business cannot run without.

Good Must-Have candidates for a pricing tender are the decisions you make every week:

• A rule engine your team can change without the vendor - margin floors and ceilings, price endings, competitor positioning, size and brand ladders.
• Explainable recommendations. Each proposed price shows which rule or model drove it and the expected margin and volume impact.
• An approval workflow with an audit trail. Nothing goes live without a named person approving it.
• Zone and store-level pricing that matches how you actually price today.
• Competitor price data with matching confidence you can inspect.
• Integration with your ERP and point of sale, both for loading data and for writing approved prices back.

Everything else, from dashboards to language packs, can be Desired. It still gets scored. It just cannot decide the outcome on its own.

Make the roadmap a contract term

No pricing platform covers the full scope of a grocery or general-merchandise tender out of the box. Regular price, promotions, leaflets, supplier funding and markdown are five different problems. A vendor claiming all five are fully mature is either very large or not reading the requirements closely.

So expect Roadmap answers, and make them useful. Ask for a release date per requirement, not a vague "H2". Then write those dates into the contract, with a remedy if they slip. The remedy can be modest: a fee reduction, or an exit right at the first missed milestone. What matters is that the date stops being a sales promise and becomes an obligation.

This is the single best defense against the two regret drivers in the Gartner data. A date in a contract survives the handoff from sales to delivery. It also sets expectations in writing, which is the opposite of mismanaging them.

Write requirements as scenarios, not features

Feature requirements get feature answers. Scenario requirements get evidence.

Instead of "The system shall support promotional forecasting", write: "A category manager plans a two-week 25 percent discount on a top-20 coffee SKU. Show the forecast uplift, the cannibalization on the rest of the coffee shelf, the supplier funding applied and the net margin, before approval."

Instead of "The system shall support seasonal demand", write: "Show how the forecast for your top seasonal lines changes in the four weeks before your biggest seasonal event, and how that changes the recommended price." Every market has these weeks. Ramadan, Christmas, back-to-school and national holidays all move demand in ways a generic weekly seasonality curve misses.

Scenarios are harder to answer with a single word. That is the point. They also give you a ready-made script for the demo, which is where the next section starts.

Phase the scope instead of buying everything at once

The fastest way to fail a pricing project is to switch everything on at the same time. Regular price, promotions and markdown each need clean data, trained users and a change in how decisions get approved. Doing all three in one go multiplies the risk.

Ask vendors to propose a phased plan, and score the plan itself:

1. Regular price and market intelligence first. Rules, zones, competitor data and price optimization on a few pilot categories. This is where most of the margin sits and where results show fastest.
2. Promotions second. Promotion calendar, item selection, mechanics, forecast with cannibalization and supplier funding, and post-event evaluation.
3. Leaflet, supplier claims and perishable markdown last. These depend on the first two working and on batch and expiry data many retailers do not yet have in clean form.

A phased plan with dates per phase tells you more about a vendor's delivery capacity than any slide on methodology. If the vendor cannot say what goes live in month three, it probably does not know.

Score the demo on your data, not the vendor's

A demo on the vendor's sample data shows you the product on its best day. A demo on your data shows you the product on a normal Tuesday.

Send a sample dataset with the RFP: one or two categories, a year of sales by week and store, current prices and costs, and a list of competitor products. Add three or four of the scenarios from your requirements. Then tell vendors the shortlist demo will run on that data and those scenarios, and nothing else.

During the demo, have the people who will use the tool in the room. Category managers, not only IT and procurement. Ask them to score three things on the spot:

• Could they explain the recommended price to their director in one sentence?
• Could they change a rule themselves, without the vendor driving?
• Did the numbers look like their business, or like a textbook?

A vendor that asks for more time to load your data is telling you something about onboarding. A vendor that declines to use your data is telling you more.

Know where your data lives

Pricing data is commercially sensitive. It shows your costs, your margins, your promotion plans and your supplier deals. Treat hosting and security as Must-Have gates, not as a page in the appendix.

Ask four plain questions:

1. Where is the data hosted? Which cloud, which region. If local law or your own policy requires data to stay in-country, ask whether the vendor can provide a dedicated instance there, and by when.
2. Who can see it? Which vendor staff, under what access controls, and whether access is logged.
3. What is certified, and what is in progress? Ask for current certifications and for the date of any audit underway. "In progress" with a date is an honest answer. "Compliant" with no certificate is not.
4. How do you get your data back? Export formats, timelines and deletion on exit.

The same goes for the decisions themselves. If a regulator, an auditor or your own board asks why a price changed on a given day, you need a record of who approved what and why. We wrote up what a pricing audit trail should log. Make it a requirement, not an assumption.

What an RFP won't tell you

Even a well-designed tender has blind spots. It is worth naming them so nobody expects the scoring sheet to cover them.

Adoption. An RFP scores the product. It does not score whether your category managers will open it every Monday. The best predictor is the demo on your data, with them in the room. The second best is a reference call with a customer of similar size, where you ask what they stopped doing after go-live.

Your own data quality. If costs are stale or product hierarchies are inconsistent, every vendor will struggle, and the RFP will not show it. Budget for a data clean-up inside the project, not after it.

Your own pricing strategy. Software executes a strategy. It does not choose one. Decide which categories lead on price and which earn margin before go-live. Otherwise the tool will optimize toward a target nobody agreed on.

The team behind the product. A large vendor and a small vendor fail in different ways. A large one may put you in a queue. A small one may depend on a few people. Ask who will work on your account in month six, and meet them before you sign.

A scoring sheet that fits on one page

The final scoring should be simple enough that the steering committee can read it in five minutes. One structure that works:

1. Gates (pass or fail). All Must-Haves fully or partially compliant, or on the roadmap with a contracted date. Hosting and security requirements met. Any fail ends the evaluation for that vendor.
2. Capability (40 percent). Weighted compliance across all requirements. Fully compliant scores full points, Partial scores half, Roadmap with a date scores a quarter, Not compliant scores zero.
3. Demo on your data (30 percent). The category managers' scores from the three questions above.
4. Delivery plan (15 percent). Realism of the phases, dates per phase, and what the vendor needs from your team.
5. Commercials (15 percent). Total cost over three years, exit rights and how fees change as you grow.

Notice what carries the most weight after the gates: what the product does today, and how it behaves on your data. That is where the regret in the survey data comes from, and where a tender can protect against it.

Retailgrid answers RFPs this way, with a four-level compliance answer and a dated roadmap for every gap. If you are drafting a tender for pricing and promotion software, our price optimization software overview shows what each layer does today. Or send us a sample category and see your own data in the product before the RFP goes out.