POC pricing: How can you tell if a solution really creates value?
A pricing proof of concept (POC) is a test that is limited in both time and scope, conducted using a retailer’s actual data, which compares the pricing decisions recommended by a solution to a baseline scenario measured in the same way. It provides evidence when five elements are established before the test begins: the scope, the baseline scenario, the metrics, the duration, and the resources allocated.
The method described here distinguishes between three categories of indicators that are too often conflated (model performance, economic gains, and team usage), explains how to test multiple vendors using the same dataset, and explains why a proof of concept (POC) should be conducted without altering the existing price-dissemination tool.
A pricing software demo is always impressive: the data is clean, the recommendations are spot-on, and the interface is responsive. Three months later, the team that launched the POC still doesn’t know whether the solution actually boosted the margin by one percentage point or if the market was simply favorable. The test produced screenshots, not proof.
This article is intended for pricing, procurement, and finance departments that are preparing to test one or more pricing solutions. It describes what a proof of concept (POC) should include to measure actual value creation, and how to compare multiple vendors without favoring the one that presents itself best.
Short answer: What a pricing POC must demonstrate
A pricing POC (proof of concept) is a test—limited in both time and scope—conducted using a retailer’s actual data, which compares pricing decisions generated by a solution to a baseline scenario measured in the same way. It creates demonstrable value when five elements are established before the first recommendation: the scope of the test, the baseline scenario, the selected metrics, the duration, and the resources committed by both parties.
Anything missing from this list at the outset will cost you in the end. Without a baseline, a margin gain may be due to market conditions or the season. Without usage metrics, a solution may generate good recommendations that no one follows. Without sufficient duration, the test ends before the models have experienced a peak sales period. The rest of the article details each of these points, followed by instructions on how to compare multiple software providers using the same dataset.
Why So Many POCs Don't Prove Anything
Retailers testing a pricing solution lack neither rigor nor goodwill. They run into three areas of confusion that creep in right from the outset.
A demonstration is not a POC
The demonstration is conducted using the vendor’s data or a carefully prepared subset of your own data. It shows what the product is capable of. The POC is conducted using your data as-is—with all its gaps and duplicates—and shows what the product will do in your environment. The former can be evaluated in an hour; the latter takes several months. Many “POCs” are actually extended demonstrations: access to the platform, a dataset loaded once, a few workshops, and no metrics.
A model's performance is not a gain
A sales forecast that is 90% accurate and a product reconciliation that is 95% reliable are good news, but these are technical results. They do not indicate whether the recommended prices increased the margin without damagingthe price image. The classic mistake is to evaluate the POC based on the first set of indicators and draw conclusions based on the second.
A free POC is not a cost-free POC
Many software vendors are willing to offer a trial without charging a fee. The real cost of the POC lies elsewhere: in the time spent by the data, pricing, and management control teams preparing data extracts, answering questions, and validating figures. This time remains the same regardless of whether the vendor charges a fee, and it multiplies by the number of vendors being tested. This is why a retailer cannot test five solutions simultaneously, regardless of its size.
88% of artificial intelligence proof-of-concept projects never reach large-scale deployment: for every 33 POCs launched, 4 go into production. The reasons cited include an unproven return on investment, insufficiently prepared data, and a lack of internal expertise.
(IDC for Lenovo, CIO Playbook 2025, global survey of IT and business decision-makers, 2025)
These figures pertain to artificial intelligence in general, not to pricing specifically, but the causes they identify are exactly the same as those found in tests of pricing solutions: a metric that was never measured, data that wasn’t ready, and no one on the retailer’s side to drive the initiative over the long term.
Choose a scope that speaks to people
The scope of a POC must meet two criteria: it must be small enough to be prepared and monitored with limited resources, yet large enough that any deviation in results is discernible and not merely a matter of chance.
Categories that sell—and sell consistently
A slow-moving or highly seasonal category yields too few data points over three months to draw conclusions. The ideal scope includes a few product families with regular weekly sales, active competition, and real pricing leverage (products where the retailer has room to maneuver, not just items whose prices are dictated by the market). A few hundred to a few thousand SKUs are sufficient.
Similar stores or channels
If the test focuses on retail locations, it’s necessary to find comparable stores: same format, same catchment area, same local competition, and similar sales figures. A proof of concept (POC) based on the top five stores in the network proves nothing because no other stores can serve as a benchmark. The same reasoning applies to channels: testing the e-commerce site alone requires a benchmark structured differently—by time period or by control category.
A schedule without any disruptive highlights
A POC that includes Black Friday or sales primarily measures the impact of Black Friday or sales. It’s best to start after a peak period, during a typical sales period, and to include a medium-sized promotional event to see how the solution handles it. Our article on the price testing protocol details how to choose an observation window that is not skewed by seasonal factors or one-time promotions.
Establishing the baseline
The baseline is what the POC results will be compared to. Without it, any gain is questionable and any loss is excusable. There are two possible approaches, and the best POCs combine both.
Before and after, within the same area
The indicators are measured in the months leading up to the test and then during the test. It’s simple, but fragile: a change in economic conditions, a supplier rate increase, or the entry of a competitor is enough to skew the results. This measurement must therefore be supplemented.
Test and indicator, at the same time
The solution’s recommendations are applied to a group of stores or categories, while a comparable group continues to operate under the usual pricing strategy during the same period. The difference between the two groups isolates the effect of the solution from any factors that affect both groups simultaneously. This method allows for the measurement of incremental gains rather than mere volume shifts, and it applies to both regular prices and promotions.
The opening figures approved by management accounting
Before running the test, revenue, volumes, and margins for the scope must be calculated in the solution and reconciled with those from management accounting, month by month and category by category. A discrepancy of even a few percent indicates a data issue (incorrectly valued purchase costs, unlinked promotions, ignored returns) that must be addressed before any measurements can be taken. At Booper, this reconciliation is part of the data integration process: the test does not begin until the figures from management accounting and those from the platform tell the same story. Preparing this dataset follows its own set of rules, which are described in our article on the data required for a pricing POC.
Three categories of indicators that should not be confused
A POC is evaluated on three distinct levels. Mixing them leads to false conclusions in both directions: a technically brilliant but unused solution, or a solution adopted with enthusiasm that yielded no results.
| Family of indicators | What it measures | Examples | What She Doesn't Say |
|---|---|---|---|
| Model Performance | The technical quality of the solution's calculations | Accuracy of forecasts for past weeks, reconciliation rate and reliability, and plausible elasticities by category | If the store makes money |
| Economic Benefits | The difference between the test scope and the baseline | Markup, revenue, volumes, price index relative to competitors, remaining inventory, promotional incremental sales | Whether the teams will use it after the test |
| Use by Teams | Actual adoption of the tool in everyday life | Percentage of recommendations implemented, time required to prepare a price wave, recommendations understood without the publisher's assistance | Nothing, if the other two families are measured as well |
Model Performance Metrics
They are evaluated based on past performance, even before a price is set. Does the solution accurately forecast sales for the past twelve weeks based on historical data? Is the comparison between your products and those of your competitors accurate, and for what portion of the product assortment? Are the calculated elasticities consistent with what the teams know about their categories? These checks take a few weeks and already eliminate solutions that don’t hold up against your data. The accuracy of a competitive product benchmarking tool is evaluated, for example, using a manually verified sample.
Economic Gain Indicators
These are the factors that matter most for the final decision: the test scope’ Markup s compared to the control group, revenue and volumes (to verify that the margin wasn’t gained by selling less),the price index compared to tracked competitors (to verify that it wasn’t gained by raising prices), and the remaining inventory at the end of the period. Booper reports margin gains of 0.5 to 3 points for its clients within a few months: it is precisely through a POC of this type that the order of magnitude is verified, and our article on the return on investment of a pricing solution explains why the gain in decision-making is harder to measure—and more significant—than the time saved.
Usage Metrics
These are the factors most often overlooked and the most predictive of what will happen after the POC. What percentage of the recommendations did the teams implement, modify, or reject, and for what reasons? How long does it take to prepare a pricing wave using the solution, compared to the old process? Do category managers understand why a price is recommended without having to call the vendor? A solution whose recommendations are not understood will not be implemented, regardless of its statistical quality; this is the rationale behind the requirementsfor explainability and auditability of price recommendations that major retailers now include in their requests for proposals.
The recommendation adoption rate is a metric that Booper displays on its dashboard, alongside the estimated margin impact. A high adoption rate in a POC indicates that teams find the recommendations to be logical and relatable; a low rate, even with strong financial results, suggests that a full rollout will be challenging.
Duration and resources: three to six months, no less
The duration of a POC is determined by the time required for the economic benefits to become apparent. It takes several weeks to load and reconcile the data, a few weeks to validate the models using historical data, and then at least two full pricing decision cycles that are implemented and measured. Three months is the minimum for high-turnover categories; six months is more realistic if the test must span a sales campaign or if the data requires cleaning. A shorter test measures the speed of implementation, not value creation.
On average, it takes eight months to move from an AI prototype to production, and only 48% of projects succeed in doing so. The primary obstacle cited by 49% of respondents is the difficulty in estimating and demonstrating the project’s value.
(Gartner, survey of 644 organizations in the United States, Germany, and the United Kingdom, May 2024)
On the brand side, three resources are essential, and their absence accounts for most POCs that get bogged down: a data specialist capable of extracting, documenting, and correcting data flows; a business specialist (pricing manager or category manager) who applies the recommendations, provides feedback, and makes final decisions; and a contact in management control who validates the baseline figures and results. A quarter of each person’s time for the duration of the test is a common estimate. Our article on the actual time allocation of a pricing team explains why this time is rarely available without explicit decision-making.
Compare Several Publishers on an Equal Footing
When a retailer considers replacing its current solution, it rarely evaluates just one candidate. A comparison is only meaningful if the conditions are the same for everyone.
The same dataset, prepared once
Each publisher receives exactly the same data extracts, documented in the same way, with the same reference figures validated by management control. Preparing a common data set before selecting candidates avoids having to redo the work for each one and, above all, prevents any one publisher from having a “cleaner” dataset than another. Any discrepancies observed afterward stem from the solutions, not the data.
The same grid, the same questions
The three categories of indicators listed above form a common rating framework, supplemented by criteria that cannot be measured using POC: ability to integrate with the information system, compliance with French pricing regulations, reversibility conditions, and business model. Our comparative guide to pricing software provides a set of criteria that each retailer can adapt to its specific context.
Evaluating Artificial Intelligence Beyond the Demonstration
This is the point where comparisons most often come down to a gut feeling. An AI feature that looks impressive in a demo is evaluated in a proof of concept (POC) based on three simple questions. Is it useful in day-to-day operations—that is, has it been used weekly by teams without prompting from the vendor? Does it produce analyses that the teams would not have done on their own (an anomaly detected, a drop in margin explained, a trade-off between two scenarios)? Are its recommendations accompanied by the factors that explain them, the constraints applied, and the expected impact? At Booper, every forecast and every recommendation comes with an explanation of the factors that influenced it—precisely so that this third point can be verified by the teams rather than simply asserted by the publisher. Our article on general-purpose AI versus dedicated pricing solutions helps distinguish between what constitutes a true business model and what is merely window dressing.
Free POC or Paid POC
Both approaches exist. A free POC lowers the barrier to entry but places less commitment on the vendor, who can allocate limited resources to it; a paid POC—often deductible from the contract if the client signs—commits both parties to a timeline and deliverables. The key factor isn’t the price but what’s written in the agreement: scope, data provided, metrics, duration, resources from each side, and decision criteria at the end. A free POC without this framework ends up costing more than a well-defined, paid POC.
A proof of concept without altering the existing tool
Many retailers considering a change in their solution are still tied to their current vendor by a contract, integrations, and established practices. This is not an obstacle to a POC, provided that two things are kept separate: the generation of recommendations and the distribution of prices.
During the test, the candidate solution receives the data, performs calculations, and makes recommendations. The selected prices continue to pass through the existing tool, which remains the infrastructure for distributing them to the cash registers, the website, and the stores. Nothing changes for downstream systems, and the POC can even be conducted without affecting the current software vendor. This temporary coexistence allows for a comparison of the recommendations from both tools for the same products and the same weeks, providing an additional benchmark that is highly meaningful to senior management.
It also allows you to prepare for a potential transition without rushing it. Issues related to resuming rules, restoring historical data, and terminating contracts are addressed in our articles on switching pricing tools and on the reversibility of a pricing solution; the POC, however, is not intended to resolve these issues. Its purpose is to determine whether the candidate solution adds value to your data.
The Ten-Point Framing Grid
The ten questions below—submitted in writing before the project begins and signed by the retailer and the publisher—are sufficient to turn a POC into proof.
- Objective: What decision should the POC enable, and who makes it?
- Scope: Which categories, which stores or channels, and how many SKUs?
- Data: What data is extracted, at what level of detail, covering how far back in time, and validated by whom?
- Baseline scenario: before and after, test group and control group, or both? What are the baseline figures, as compared with management control data?
- Model metrics: forecast accuracy, fit quality, elasticity consistency—with what thresholds?
- Economic indicators: margin, revenue, volume, price index, inventory—how and by whom are they measured?
- Usage metrics: adoption rate of recommendations, preparation time, understanding of explanations?
- Duration and milestones: dates for data upload, model validation, the first round of pricing, interim review, and final review?
- Resources: Who on each side is responsible for what, and who resolves conflicts over priority?
- Decision: Which results lead to continuing, expanding, or discontinuing the project, and under what contractual terms?
This framework is what Booper offers its prospective clients when defining the scope of a test. It is intentionally solution-agnostic: a retailer can require all vendors it consults to follow it, and that is what we recommend. The price diagnostic process that often precedes a POC is used to identify the scope where the value gap is most likely to emerge. For the complete project workflow following a successful POC, our guide on implementing a pricing tool in eight steps takes over, and our article on change management addresses the transition from the test scope to the entire network.
FAQ: Defining and Evaluating a Pricing Proof of Concept (POC)
A pricing proof of concept (POC) is a test that is limited in both time and scope, conducted using a retailer’s actual data, during which a pricing solution calculates price recommendations that are applied and measured against a baseline scenario. It differs from a demonstration—which uses prepared data and does not measure anything—and from a pilot deployment, which takes place after the purchase decision has been made. A POC generally lasts three to six months and covers a few product categories and a few comparable stores or channels.
By applying the new prices to a test group of stores or categories, while comparable groups (same format, same area, same competition) maintain their usual pricing over the same period. The difference in margin, volume, and price index between the two groups isolates the effect of the change from any factors affecting the entire network: season, economic conditions, and supplier price increases. At least two full decision cycles are needed to draw conclusions, and the timeline should avoid peak periods. A pricing solution allows you to simulate the expected effect even before the test begins, and then compare it to the observed results.
A pricing platform that combines pre-decision simulation (the impact of a price or promotion on sales, margin, and inventory), the application of prices to a selected scope, and the measurement of results compared to a control group. Price monitoring tools alone provide competitor prices but do not simulate or measure. Booper offers all three functions on a single platform, with a dashboard that tracks the estimated margin impact and the rate at which teams adopt recommendations—two metrics that are directly useful for evaluating a POC.
Between three and six months. This timeframe breaks down into a few weeks of data loading and reconciliation with management accounting, a few weeks of back-testing the models (forecasts, product reconciliation, elasticities), and then at least two cycles of price decisions that are implemented and measured. Three months are sufficient for fast-moving categories with data that is already clean; six months are required whenever the test involves a sales campaign or the data requires cleaning. If the timeframe is less than three months, we’re measuring the speed of implementation, not the value.
The order of magnitude figures published by vendors range from a few tenths of a point to a few points in profit margin. Booper reports a gain of 0.5 to 3 points in profit margin within a few months, depending on the retailer’s starting point and scope, and a 70 to 90 percent reduction in price preparation time. For example, a multi-brand retailer in the French Caribbean achieved a one- Markup -point gain in a single quarter on the products tested, before rolling out the initiative company-wide. The POC is specifically designed to replace these rough estimates with a figure based on your own data and your own scope.
Two or three at most, rarely more. Each POC involves a data lead, a business lead, and a contact person from the brand’s management control department, and the time required is multiplied by the number of candidates. The comparison is valid only if all candidates receive the same dataset—prepared and validated just once—and are evaluated using the same criteria: model performance, economic gains compared to a baseline scenario, and actual usage by the teams. An initial screening of proposals (compliance with French regulations, integration, reversibility, and references in your industry) helps limit the POCs to solutions that meet these criteria.
Yes, and this is actually the most common setup when a retailer is still under contract. The tested solution receives the data, performs calculations, and makes recommendations; the selected prices continue to flow through the existing system, which remains the infrastructure for distributing them to the checkout systems, the website, and the stores. Nothing changes for the downstream systems. This coexistence also makes it possible to compare the recommendations from both tools for the same products and the same weeks. Issues regarding the adoption of rules and contract termination are then addressed, if the POC concludes that value is being created.
Based on three questions, which are open-ended rather than prescriptive. Did the AI assist the teams each week without being prompted by the editor? Did it produce analyses that the teams would not have conducted on their own—for example, detecting an anomaly or explaining a decline in margins? Is each recommendation accompanied by the factors that explain it, the constraints applied, and the expected impact, so that a category manager can validate or reject it with full knowledge of the facts? A feature that looks brilliant in a demo but fails to address these three points has no place in the decision-making process.
A pricing proof of concept (POC) is a test that is limited in both time and scope, conducted using a retailer’s actual data, which compares the pricing decisions recommended by a solution to a baseline scenario measured in the same way. It provides evidence when five elements are established before the test begins: the scope, the baseline scenario, the metrics, the duration, and the resources allocated.
The method described here distinguishes between three categories of indicators that are too often conflated (model performance, economic gains, and team usage), explains how to test multiple vendors using the same dataset, and explains why a proof of concept (POC) should be conducted without altering the existing price-dissemination tool.
A SaaS pricing management platform centralizes a retailer’s prices, rules, competitor data, and sales forecasts in a browser-based tool—with no servers to install or versions to maintain. For the retail industry, its benefits include the ability to respond quickly to market changes, measurable margin gains, built-in compliance with French regulations, a predictable subscription cost, and scalability across thousands of retail locations.
Booper, a French pricing software provider since 2014, exemplifies this model with a platform that manages more than 4,000 retail locations for chains such as Magasins U, E.Leclerc, and Castorama, and aims to increase profit margins by 0.5 to 3 percentage points within a few months.
Reversibility must be negotiated before the contract is signed—never after. Once the contract is signed and the system is live, the balance of power has completely shifted. Four assets are at stake: your raw data, your rule set, your trading history, and your competitive matching table. Only the first is generally covered by contracts.
The gap between perception and reality is well documented: 89% of executives believe they can switch suppliers in less than a month, but among those who have tried, 58% report that the effort failed or took much longer than expected (Zapier, 2026). The goal isn’t to leave, but to have the option to do so: that’s what maintains a healthy supplier relationship throughout the contract term.