Switch pricing toolswithout repeating his mistakes
.avif)
One underutilized tool contains valuable information (the specific causes of adoption failure, which must be identified before making changes), and the Standish Group’s CHAOS Report notes that only 31% of IT projects are fully successful, 50% are delivered with compromises, and 19% fail completely. The migration of existing data (history, catalog, rules) must be an explicit requirement in the specifications, not an option.
Ensuring successful adoption is the role of BOOPER’s Change Management module: to support business teams so that a new tool does not suffer the same fate as the previous one.
An initial pricing tool that was never fully configured or truly adopted is not an isolated case; it’s a scenario that occurs regularly in specialty retail. The contract expires, and a new partner must be chosen—with one explicit goal in mind: 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
It’s a familiar scenario in the specialty retail sector: a pricing tool deployed several years ago, never fully configured, and never truly adopted by the teams. The contract is about to expire, and there’s a strong temptation to treat the renewal as a simple comparison of features and pricing (the same mindset, at times, that guided the initial choice).
It’s a missed opportunity. An initial deployment failure provides valuable insight: the specific reasons why adoption didn’t take place. Ignoring this analysis to focus on the new software is like switching cars without understanding why the first one never left the garage.
Why Software Migration Projects Fail So Often
31% / 50% / 19%, breakdown of IT projects according to the Standish Group CHAOS Report (2020 edition, an industry benchmark since 1994): 31% are fully successful within the planned time frame and budget, 50% are “challenged” (exceeding the time frame, budget, or scope), and 19% fail completely.
This figure applies to all IT projects—not just pricing—but it highlights a key point: half of the projects that are “successful” in the strict sense of the term achieve that status by making significant compromises on scope or actual usage. A tool that is delivered but never fully configured typically falls into this gray area.
According to Prosci, a leading firm in change management (which has been conducting ongoing research since 1998), 30% of change project leaders cite employee resistance as the number one obstacle to a project’s success, ahead of a lack of sponsorship or budget.
In other words: in a significant number of deployment failures, the software itself is not to blame. The problem lies in how the project is managed (training, support, and buy-in from the teams who will be using it on a daily basis).
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 relate to how the project was carried out, and will recur with new software if they are not explicitly addressed.
Build on what already exists rather than start from scratch
Switching tools doesn't necessarily mean starting from scratch. The price history, the existing product catalog, and the business rules already developed with the first service provider—even if they haven't been fully utilized—represent a wealth of business knowledge that is worth building on rather than rebuilding from scratch.
A criterion that is often overlooked in migration specifications: the new service provider’s ability to quickly restore a functional environment based on what already exists, rather than requiring a new data collection project to be started from scratch.
The Specifications That Help You Avoid the Pitfalls of Your First Project
1. Require a data assessment before configuration. The service provider must be able to specify, before signing the contract, which data can be used as-is and which data needs to be validated.
2. Prioritize usability for non-experts. A tool reserved for a handful of in-house experts replicates the dependency and fragility of the previous system.
3. Include the import of existing data as an explicit criterion. Price history, catalog, and predefined rules should be considered a selection criterion in their own right.
4. Align the change management process with the company's actual schedule. Training, support, and implementation should be planned for periods outside of operational peaks.
To compare offerings based on the same criteria, our comparison of retail pricing software reviews five categories of solutions across ten criteria.
The Schedule: Why Timing Matters Just as Much as Choice
Best practice: One of the most common reasons a project is abandoned partway through is poor scheduling. Launching a migration project in the middle of the annual rate update period, during peak season, or at the same time as another major IT project greatly increases the risk that the configuration will be postponed and then abandoned.
A realistic timeline clearly distinguishes three phases: selecting the service provider, ensuring data reliability, and training teams in advance; followed by the actual start of configuration once the period of heavy operational workload has passed.
Mistakes That Cause a Second Attempt to Fail
- Don't base your decision solely on budget considerations. An attractive price does not make up for a poorly supported project.
- Do not involve future users in the selection process. A tool chosen solely by management will replicate the lack of buy-in that likely contributed to the initial failure.
- Underestimating the effort involved in data migration. Starting from scratch with the catalog and history makes the project more time-consuming.
- Launch the configuration at the worst possible time in the business calendar. Even an excellent tool that is poorly timed will meet the same fate as the one before it.
Frequently Asked Questions
Assess the situation 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 is often the project management, not the software. Only a genuine functional limitation—one observed despite full use of the tool and clean data—justifies switching to a different tool; other common causes will recur with new software if they are not explicitly addressed.
In most cases, yes, at least partially: price history, product catalog, and predefined business rules can be reused to avoid starting from scratch. One criterion that is often underestimated in migration specifications is the new service provider’s ability to quickly restore a fully operational environment based on the existing data, rather than requiring a new data collection process from scratch.
During a period of high operational workload, annual rate updates, seasonal peaks, and another major IT project underway, a realistic timeline clearly distinguishes three phases: selecting the service provider, ensuring data reliability, and training teams in advance, followed by the actual start of configuration once the period of high operational workload has passed.
There is no one-size-fits-all timeline: identifying the causes of the initial failure, ensuring data reliability, training teams, and launching the system outside of peak periods are steps that cannot be rushed. What truly speeds up the project is leveraging the price history, catalog, and business rules already developed with the first service provider, rather than rebuilding everything from scratch.
At the very least, the teams that will use the tool on a daily basis—not just the management team that signs the contract. A tool selected solely by management often leads to the same lack of buy-in that contributed to the initial failure; involving future users in the selection process is one of the best predictors of successful adoption the second time around.
See also in this series:Before deploying a pricing tool, ensure your data is reliable · Integrate your pricing data without a major IT project · Pricing, procurement, category management: Move Beyond Separate Files.
Goal-based pricing starts with the target outcome (margin, revenue, category competitiveness) and lets AI calculate the prices needed to achieve it, rather than piling on rules one product at a time.
The engine simulates thousands of scenarios by factoring in business constraints, purchasing behavior, and product cannibalization; if the objective is unattainable, it identifies the best compromise.
For retailers supported by Booper: +0.5 to +3 percentage points of margin in a few months and -70 to -90% reduction in price preparation time . The pricing manager retains the final decision.
The key takeaway: An AI-generated price recommendation without an explanation falls on deaf ears with pricing teams, who refuse to apply a score they don't understand.
Explainability and auditability are two distinct requirements: the former justifies a recommendation at the time it is proposed, while the latter makes it possible to trace who approved what, when, and why—even several months later. A key finding: Explainability is identified as a key AI risk by a large majority of executives, but very few organizations are actually taking steps to address it.
Fixed-rule dynamic pricing is giving way to autonomous AI agents that make decisions in real time—on both the seller and buyer sides—without waiting for a human approval cycle.
90% of B2B purchases will be handled by purchasing agents by 2028 (Gartner), and 47% of the retail sector has already adopted agent-based AI (NVIDIA): competition between agents is becoming the norm, not the exception.
The real risk is not speed but the lack of safeguards: price floors, price ceilings, and explicit governance are becoming the priority, lest algorithmic collusion—which regulators are already scrutinizing—occur.