“Buyer's remorse” is defined as “a feeling of regret (a wish that you had not done something) after making a choice or decision.”
It's not uncommon to experience buyer's remorse, especially when buying expensive items like a house or car. For example, as reported by CNBC in August 2022, “72% of recent homebuyers have regrets about their purchases.” Many of the homebuyers surveyed felt they spent too much money on the house and/or they felt they rushed the buying process.
Timeshares, gym equipment, extended warranties, a boat, exercise equipment — the list of things that people often regret buying is long.
Buyer's remorse also occurs in the business realm, especially when it comes to procuring IT solutions. In a survey conducted by Gartner in late 2021, 56% of the organizations surveyed “said they had a high degree of purchase regret over their largest tech-related purchase in the last two years.”
Considering that many technology solutions require a significant amount of time, money, and resources to procure and implement, an investment that fails to meet expectations can have a damaging impact on business performance. Hershey's failed ERP implementation in July 1999 is an infamous case. As highlighted in a case study published by Pemeco Consulting, “Business process and systems issues caused operational paralysis [at Hershey's], leading to a 19 percent drop in quarterly profits and an 8 percent decline in stock price.”
The stakes are also high for leaders in charge of procuring or implementing technology solutions. For example, in a March 2016 post in Proformative titled “Tech Implementation Failure Cost Me My Job,” a CFO (posting anonymously) shared some lessons learned from a failed ERP implementation. “In the end, the buck has to stop somewhere and I accept that,” the CFO concluded. “Of course, no one likes to lose [their] job.”
It's not surprising, therefore, that the phrase “Nobody ever got fired for buying IBM” became a popular saying in IT circles. As software executive Brian Welsh writes in an April 2021 LinkedIn post, the saying “has become the 'better the devil you know' cop-out clause for risk-averse software buyers. Rather than choose the product of another tech company even though they know it offers a better solution, buyers are still going with [the incumbent megabrand] because they'll be better shielded from any negative consequences.”
The irony, of course, is that by embracing this philosophy and short-circuiting the technology evaluation and selection process, the risk for failure and buyer's remorse actually increases, as we highlight later in this report.
Understanding Buyer's Remorse
The phenomenon of buyer's remorse is linked to cognitive dissonance — that is, “a mental conflict that occurs when your beliefs don't line up with your actions,” as defined by Psycom.net.
In a paper published in the journal Psychology & Marketing in November 2000 (“Cognitive Dissonance after Purchase: A Multidimensional Scale”), the authors describe “the development of a 22-item scale for assessing cognitive dissonance immediately after purchase.” The table below highlights these 22 items categorized into three key elements of buyer's remorse: Emotional, Wisdom of Purchase, and Concern Over Deal.
Elements of cognitive dissonance
Anyone who has been involved with purchasing supply chain/logistics technology can certainly relate to many of the elements listed in the table above.
In fact, in a survey we conducted in December 2022 with members of our Indago supply chain research community (who are all supply chain and logistics executives from manufacturing, retail, and distribution companies) and executives from leading parcel/package delivery companies, national postal carriers, public works, and other companies with last-mile delivery operations, almost three quarters of the 38 executives who responded (74%) said that they have experienced buyer's remorse with the purchase of a supply chain/logistics technology solution.
Either at your current company or at a previous one, have you ever experienced “buyer's remorse” with the purchase of a supply chain/logistics technology solution (e.g., software, hardware, web services, etc.)?
The only good news, therefore, is that if you have experienced buyer's remorse after purchasing a supply chain/logistics technology solution, you are not alone.
Internal vs. External Contributing Factors
Of the survey respondents who have experienced buyer's remorse, about two thirds (67%) said that, overall, it was due more to reasons related to the technology vendor or solution than to internal reasons.
Overall, would you say the buyer's remorse was due more to internal reasons (e.g., we didn't do enough due dilligence) or reasons related to the technology vendor or solution (e.g., software lacked promised capabilities)?
Topping the list of reasons was “Technology did not meet our functional requirements,” with 52% of the respondents selecting it, followed by “The implementation took much longer and required more resources than the vendor had indicated” (44%).
What were some of the vendor/technology reasons, if any, that led you to experience buyer's remorse?
With regards to internal reasons for experiencing buyer's remorse, “We didn't assign enough resources to the implementation” topped the list with 41% of the respondents selecting it, followed by “We didn't conduct enough due diligence” (37%).
What were some of the internal reasons, if any, that led you to experience buyer's remorse?
When reviewing the reasons for a project's failure (or in this case, buyer's remorse), it is arguably easier to point the finger at others than at yourself. Therefore, it is not surprising that most of the survey respondents attributed their buyer's remorse to reasons related to the technology vendor or solution. However, as the chart above highlights and the respondent comments below illustrate, it is clear that buyers of supply chain/logistics technology have as much responsibility for preventing or causing buyer's remorse than their vendor counterparts.
Key Takeaways from Survey Results
Conduct Thorough Due Diligence Process
First, what can we learn from those who have not experienced buyer's remorse? For the relatively few survey respondents who fall in this category, the top reason (by a large margin) they didn't experience buyer's remorse was “We conducted a very thorough due diligence process,” selected by 63% of the respondents.
When you have been satisfied with a technology solution purchase, what are some of the main reasons why you or your organization have not experienced buyer's remorse?
Ask to see demonstrations using your data and real business scenarios,”
recommended one executive respondent. Another executive added,
Extensive testing needs to be carried out involving all possible scenarios and not limited only to the 'usual' ones.”
Here are some additional recommendations submitted by other executives related to due diligence:
Biggest lesson learned has been to always look for customer references and ask a lot of detailed questions of current users. Do very thorough demos of the software and ensure all potential users or impacted teams have some form of representation in the room.”
Ask for references in an industry similar to yours. Be sure to speak to those references about their experiences to really get a feel for the functionality of the product relative to your needs away from the sales push.”
Ask the nagging questions that are on your mind [during] the sales demo!”
Assume that what you see today is what you're going to get. Promises about future functionality may not materialize. Get several customer references including one from a company no longer using the system. Follow your gut.”
You must develop detailed scripted demo requirements for potential vendors and take the time to conduct due diligence to ensure the product can deliver and meet the business requirements.”
Technology due diligence also comes into play when evaluating and selecting third-party logistics (3PL) partners, as this executive highlights:
The issue was that the technology the 3PL 'demonstrated' during the selection process turned out to be not how they managed our business. We thought we were partnering with someone who had strong technology capabilities and what we got was a lot of spreadsheets and manual processes. My sense is that we allowed the 3PL to do a lot of PowerPoint [presentations instead of us] viewing their actual systems. To my knowledge, there were no site visits or vetting of similar solutions they were providing to other similar shippers. There was also no meaningful reference checking.”
It is important to note that before putting together a Request for Proposal and compiling a detailed list of desired features and functions, companies first need to define their needs and goals. To quote Yogi Berra, “If you don't know where you are going, you'll end up someplace else.”
Applying this logic to a transportation management system, for example, if you don't know what you want to achieve with a TMS, both today and in the future, you might end up disappointed with the final outcome.
Therefore, the first step to selecting and implementing a TMS successfully is making sure you have done all of your homework upfront to select the “right” solution and partner. The “right” TMS for one company might be the “wrong” TMS for another. Determining which solution and vendor is right for you begins by thoroughly understanding your current processes and defining your desired future state.
What are our capability gaps? Which metrics do we need to improve? Do we plan to redesign our distribution network? How are our customer delivery requirements changing? Which systems does the TMS need to integrate with, and what type of data needs to be shared? What would our power users like to see in a TMS solution?
The more questions you ask and the more thorough the analysis is from the start, the greater the odds for implementation success. Simply put, if you want to prevent buyer's remorse, don't short circuit the upfront analysis and evaluation process.
Involve Power Users in Evaluation and Selection Process
In a November 2013 Harvard Business Review post titled “IT Can No Longer Afford to Ignore Its Users,” Aaron Levie, CEO of Box, writes:
The history of enterprise technology has been fairly unforgiving to the people intended to use it. For the past half-century, most information technology models propagated two unassailable truths: that enterprise technology was purchased by a select few, and the technology was bought for the company. As for the delight of the individuals using the technology itself? They'll deal.”
He adds that companies need to “start looking at the users' needs first and expand outward from there.” Levie's point was echoed by several of our survey respondents:
Leadership must include the subject matter experts (SMEs) who will be using and implementing the technology.”
Need to involve all stakeholders, from the operators to decision makers. Most of the time, decision makers do not have hands-on experience in operations and thus are unable to [define] the requirements properly.”
Engagement with the appropriate level of users and subject matter experts (SMEs) is critically important to avoid buyer's remorse with a new technology solution / implementation.”
Properly identify the need or desired result and then confirm with the end users that this will solve the need prior to purchase.”
Actually have the power users involved.”
The bottom line is that enterprise technology users, specifically those on the frontlines of day-to-day operations, need to have power and influence in selecting the solutions they want to use at work. The old formula of the CIO and corporate IT dictating what frontline workers will use is not going to work anymore.
Assign Enough Resources to Implementation
As highlighted earlier, “We didn't assign enough resources to the implementation” topped the list of internal reasons for experiencing buyer's remorse. One of the biggest mistakes a company can make with any technology implementation is to outsource the responsibility for success. Yes, you can engage with a third-party firm to lead or assist with the implementation, but this does not mean that you wipe your hands clean of all responsibility. You also have to roll up your sleeves and actively participate in the implementation process.
“Leadership did not listen to the IT department on resource requirements and timeline to implement; they listened instead to the vendor's sales pitch, but the vendor also did not fully understand our business requirements,” shared one of the survey respondents.
He also added, “Our IT resources were not up to par with what the vendor expected, which required us to hire contract employees to complete the work because we lacked the necessary skills to create and implement XML files.”
Here are some other comments related to implementation:
Integrations always take longer than anticipated; [keep this in mind] to ensure the right quantity and quality of internal resources are assigned to the implementation.”
Be more realistic about the level of complexity [involved in implementing a new solution] to improve cost estimations and project timelines.”
Our company HAS NOT actually learned to not rush projects and implementations. If the vendor tells us 6 months, we still try to do it in 6 weeks!
Be sure to invest in training, anticipate issues with the new system, and do not rush to go live.”
Who needs to participate in the implementation process? Ideally, companies will dedicate a person fulltime to the project. This project leader doesn't necessarily need to be a subject matter expert; they just have to know enough about the process, requirements, and goals to lead the effort successfully. They also need to have strong communication skills, have the ability to identify bottlenecks and resolve them quickly, and keep everyone involved with the project motivated and on track.
Various internal stakeholders, including IT, Operations, Finance, Procurement, Sales, and Customer Service need to be involved during the purchase process. Surprises and disappointments can be eliminated by anticipating who will be affected at various stages and including those teams throughout the process.
Of course, the selected technology vendor has an important role in the implementation process too. As highlighted earlier, “Technology vendor invested time and resources to ensure our objectives were met” ranked second on the list of reasons why companies didn't experience buyer's remorse.
That said, the buck ultimately stops with the buyer. If they don't invest the time and resources necessary to adequately support the implementation project, then they're setting themselves up for failure — or at best, an implementation that will take much longer and cost much more than planned.
"The last time I purchased supply chain software there was absolutely no remorse given that we were so clearly deficient in the area the software would improve that we were nothing but excited for the solution," said one of the executives surveyed. This case, however, is the exception rather than the rule.
The majority of our survey respondents have experienced regrets after purchasing and implementing technology solutions that have a significant impact on their business, and although most point to reasons related to the technology vendor or solution as the main cause, the truth is (as reflected in their responses and comments) that buyers also bear responsibility for causing or, ideally, preventing buyer's remorse.
The good news is that it is possible to avoid these pitfalls.
The top reason for experiencing these regrets related to a technology vendor or solution was "Technology did not meet our functional requirements." Meanwhile, for the relatively few survey respondents who have not experienced buyer's remorse, the top reason why (by a large margin) was "We conducted a very thorough due diligence process." Simply put, if you want to prevent buyer's remorse, don't short circuit the upfront analysis and evaluation process.
It is also critically important for companies to involve power users and subject matter experts in the evaluation and selection process, and to invest the time and resources necessary to adequately support the implementation project.DOWNLOAD THIS REPORT