Switch pricing toolswithout repeating his mistakes
.avif)
Before switching to a new pricing tool, it is important to determine why the first one was not adopted: most of the reasons are related to project management and will persist as the company transitions to the new tool. Usage data from the old tool is the best source of information for this analysis.
Re-enter the data and review the rules: copying them all at once carries over the workarounds from the first project. Running both tools in parallel through a pricing cycle is better than a lengthy set of specifications.
An initial pricing tool that was never fully configured or truly adopted is not an isolated case; it is a scenario that occurs regularly in specialty retail. When the contract expires, a new partner must be chosen, with one explicit goal: to avoid repeating the same failure.
This guide explains what needs to be assessed before reissuing a request for proposals, how to build on what already exists rather than starting from scratch, and why the timeline for the change is just as important as the choice of service provider.
It doesn't have to be the case that a first tool goes underutilized
To switch pricing tools without repeating past mistakes, you must first determine why the first one wasn't adopted, and then retain only the valuable aspects of it. Choosing the new software comes next.
It’s a common scenario: a tool deployed a few years ago, never fully configured, and rarely used. The contract is about to expire, and the temptation is to run another comparison of features and pricing.
It's often the same instinct that guided the initial choice. Switching software without understanding why it failed is like switching cars without knowing why the first one never left the garage.
Why Software Migration Projects Fail So Often
The issue goes beyond pricing. Many tools are delivered without ever delivering the expected value.
Only a few companies have been able to move beyond the proof-of-concept stage in AI and derive tangible value from it.
(BCG, “Where’s the Value in AI?”, October 2024, 1,000 executives, 59 countries)
According to the same study, about 70% of the challenges stem from people and processes, and 20% from technology. In a significant number of failures, therefore, the software is not to blame.
The problem lies in how the project was managed: training, support, and buy-in from the teams that were supposed to use it. These issues follow the company from one tool to the next.
The Right Assessment Before Making a Change: Tool or Adoption?
| Observed symptom | Probable cause | Involvement |
|---|---|---|
| Few active users | Insufficient training; absences on the part of the project team at launch | Project Management |
| Configuration remains incomplete | Insufficient data to complete the intended configuration | Data Reliability |
| Missing feature confirmed | Actual limitation of the software despite full utilization and clean data | Justified tool change |
| Launch During a Busy Period | The project began at the same time as another operational peak | Project Timeline |
To put it this way: only the third point alone justifies switching tools. The other three are related to how the project was carried out, and will recur with new software if nothing changes.
The old tool is your best resource
The first instinct is to compare the features of the two software programs. The most useful information, however, lies elsewhere: in the actual usage of the old tool, which the retailer can still access before the contract ends.
Which screens were open, which recommendations were manually corrected, which rules were never triggered: these records provide objective evidence of failure, whereas a workshop primarily gathers impressions.
Booper Team, Pricing Consulting and Implementation
So here's a practical tip: ask to have these usage records exported before the contract ends. After that, they're often lost, and the assessment relies on memory.
Build on what already exists, but not everything
Switching tools doesn't mean starting from scratch. Price history, the catalog, and the product-matching table with competitor SKUs are assets that can be carried over.
As for the rules, they can't be copied over in their entirety. Some were written to work around the limitations of the old tool, while others were never triggered. Copying them over would mean carrying that rule debt over into the new system.
Our approach: review the data and re-examine the rules. Every rule we review must be able to be justified by someone on the current team.
What can be recovered depends on the contract signed at the outset. The reversibility clauses that should be negotiated before signing are detailed in the article below.
What the new project must demonstrate before signing
A new data editor must be able to determine, before signing the contract, which parts of your data can be used as-is and which need to be validated. If it can only determine this after configuration, the risk associated with the first project remains unchanged.
It must also be a tool that your teams can use, not just an in-house expert. A tool reserved for just one or two people replicates the fragility of the previous system.
Finally, we recommend running the old and new tools in parallel on the same scope for the duration of one pricing cycle. We’re migrating a decision, not just data: comparing the two proposals is worth more than any set of specifications.
The Schedule: Why Timing Matters Just as Much as the Choice
A migration project launched during the annual rate review, a seasonal peak, or another major IT project often has its implementation postponed and then abandoned.
A realistic timeline is divided into three phases: selecting the service provider, ensuring data reliability, and providing training in advance, followed by the start of configuration once the peak period has passed.
Mistakes That Cause a Second Attempt to Fail
Choosing based solely on price. An attractive price doesn't make up for a project that isn't properly supported.
Excluding future users from the decision-making process. A tool selected solely by management will replicate the lack of buy-in that likely contributed to the initial failure. Preparing for their adoption begins at the selection stage—and is key to successfully managing change.
Start over completely, or don't start over at all. Copying all the rules over carries over the errors; starting from scratch on the catalog and history makes the project more cumbersome.
Launch at the worst possible time in the business calendar. Even an excellent tool, if launched at the wrong time, will suffer the same fate as its predecessor.
For more information:Before deciding to make a change: reversibility clauses to negotiate before signing.
See also in this feature
- The Booper Solution: Managing Change in a Pricing Project
- Selecting and Implementing a Pricing Tool: From Identifying the Need to Going Live
- ROI of a pricing solution: time savings or increased profit margins?
- Pricing Tool: Definition, How It Works, and Everyday Uses
- Excel Is No Longer Enough to Manage Pricing: The Limitations of Spreadsheets
Frequently Asked Questions
Determine the cause before making a decision. If the tool has never been fully configured, or if the team isn't using it due to a lack of training, the problem lies with project management.
Only a genuine functional limitation—observed despite full use and accurate data—is, in and of itself, sufficient justification for switching tools.
Generally speaking, yes, at least in part: price history, catalog, product mapping table. The rules are reviewed rather than rewritten, since some of them were used to work around the limitations of the old tool.
What can be recovered also depends on the reversibility provisions in the original contract.
During periods of high workload—such as annual rate reviews, seasonal peaks, or other major IT projects—prepare your options, data, and training in advance, and begin configuration once the peak has passed.
There is no one-size-fits-all timeline. Diagnosing failures, ensuring data reliability, providing training, and conducting a parallel pricing cycle for both tools cannot be rushed.
What really speeds up the project is reusing the history and catalog rather than rebuilding everything from scratch.
The teams that will use it on a daily basis—not just the management who approve it. Involving them in the decision-making process is one of the best ways to avoid the lack of buy-in that has often caused the first tool to fail.
The billing model is less important than what it encourages. Billing based on the number of simulations or recommendations can lead teams to run fewer simulations—and thus make poorer decisions.
Compare the total cost based on your actual usage, and see what you'll get back if you switch providers.
A market signal describes what competitors are doing. A profitable decision tells you what you need to do, and how it will affect sales, margins, and inventory. The two are not part of the same tool.
The decision-making process relies on five key components that external data does not provide: sales forecasts, price elasticity, cannibalization, business rules, and impact simulation. A signal infrastructure feeds these components; it does not replace them.
When choosing sales forecasting software, there are five key points to check before conducting any tests: demand hidden by stockouts, the forecast granularity, an explanation of each figure, the relationship with prices and promotions, and an honest assessment of accuracy.
A demonstration doesn't prove anything on these points. Only a test using your own data, compared to a simple baseline, will show whether the forecast truly improves your decisions.
A pricing proof of concept (POC) does not require perfect data, but rather data that is appropriate for what it needs to demonstrate, with known limitations. The product catalog, sales data, prices and promotions, purchase costs, and inventory levels form the foundation; the granularity and depth of this data depend on the test’s objective.
Before calculating a profit, the recalculated revenue, volumes, and margin must match those in management accounting. A known and documented error does not skew the comparison; a hidden error does.