Survey Says...
We were interested in the thoughts from our LinkedIn audience on who should pay the re-implementation costs - the vendor or the buyer? Here are the results from that poll:
Other Opinions
- "To me this is where you identify the true level of a partnership/ relationship. Is the shipper/buyer a transactional account with the tech owner or is there more to their relationship. A blanket policy won’t properly support the different business relationships. Some consumers won’t see the additional cost for reimplementation as a negative, while others will seek to move to a competitor. The burden of decision rests with the tech owner and how much business they want to maintain without rocking the boat too much in any one direction. It needs to be a mixture of a client retention strategy with a long term competitiveness outlook for the software vendor. The goal is not to eliminate a number of clients, it is to ease the transition with the majority of your customers while becoming more competitive and efficient in the market." - Scott T.
- "Like any business investment, a buyer of technology should re-evaluate their options. Vendors will unlikely pay for reimplementations outside of a few strategic customers. In the case of the Kuebix solutions, Trimble must have had business reasons for sunsetting and pivoting. Ideally, and I believe this to be the case, Trimble and their partners are actively communicating with their customers ensuring they have a known path forward with Trimble or a partner solution. This won't be the last in Freight Tech, given the necessary innovations still to be developed." - Marc B.
- "It would depend on the cost/benefit to both parties. I have been in situations where the benefit clearly lies with the software provider as they do not have to support as many versions however the implementation did not come free. On the flip side, through the upgrade, we were able to make changes and improve processes which ultimately provided cost savings. I think it is a shared cost as long as both parties benefit." - Robyn V.
- "It certainly matters to pay attention to the long-term track record of the vendor to add a qualifier in the original software selection around long-term stability of the vendor. Features, cost are important but platform instability are killers in the long term. Credible vendors will always publish a roadmap that shows how long software versions will be supported. One should pay attention how long these support cycles are outlined when making decisions. Final thought. We all see the major shifts in the TMS market with so many vendors coming, going or merging." - Bjorn B.
Pivoting On...
Imagine the nightmare scenario horror if Apple were to announce an acquisition of Blackberry, followed up with a notice to all customers that “as of January, all customers will be transitioned to the new Blackberry device platform,” and “thanks for your business.”
Think anyone would mind?
Or what about if Boeing sells multi-million dollar airplanes to United, who then restructures their entire network and gate operations to the configuration of the new Boeing aircraft.
After delivering the planes, and maybe a few years of usage - Boeing comes back to United and says...
"We've decided to pivot, and move to this other product with a different configuration. Sorry United, but you'll have to redo your network all over again, as we're taking back the planes we sold you."
I don't think Boeing would be in business for very long after an event like this.
The Do's and The Don'ts
What I believe software vendors should do for customers should they decide to sunset an application and transition customers to a new platform:
- Vendors Should: Ensure feature-function parity with the product being sunset.
Customers that are forced into a new platform AND have to accept a loss of feature functionality should immediately begin due-diligence on available market alternatives. JBF can help here.
- Vendors Should: Invest the time and capital necessary to develop ‘scripted migration’ to transfer as much customer master data, configuration and transactional history as possible from ‘old-to-new’ platform. This minimizes the disruption and investment on the buyer’s side, while providing an easy means to retain more customers (see my note 1.A above).
Customers should pointedly ask vendors to provide scripted migration at their own expense. This is technically possible, but rarely provided. Note – it’s very rare that a scripted migration between two different applications is ‘seamless.’ Set expectations that the migration will alleviate some reimplementation effort, but not all.
- Vendors Should: Be eliminating re-implementation fees, or at a minimum provide services at cost to help customers transition into the new platform. Justify this investment using ‘Customer Acquisition Cost’ as a guide, as vendors are highly likely to see customers explore packages from competing software providers.
Customers should negotiate free or heavily discounted services with their software vendors. Too often are they ‘rolling over’ and simply accepting the transition cost, when – in my opinion – the vendor should bear the cost and responsibility.
