Before Buying a New System, Follow a Customer Through the Old One

The software demonstration works beautifully. A booking moves through the process, information appears in the right place and the dashboard answers questions that currently take a manager half a morning to resolve. The leadership team can already imagine the relief.

Before signing, it needs to establish which part of that relief comes from better technology and which depends on decisions the business has not yet made. A new system can enforce a process more efficiently. It cannot decide whether the process is sensible or whose answer should prevail when two departments disagree.

Document what happens, including the workaround

Choose a real customer journey and follow its information through the current operation. Include the spreadsheet outside the official system, the printed note and the message sent to a colleague who knows how to resolve the exception. These are part of the operating reality, even if they are absent from the process map.

Ask why each workaround exists. It may compensate for missing functionality, a poor configuration, an unclear rule or a lack of training. Those explanations lead to different requirements. Buying a platform to solve an authority problem can leave the organisation with the same unresolved decision and a larger subscription bill.

The review should also capture what the old arrangement does well. A flexible note or local judgement may protect an important customer need. If migration removes that capability, the new design needs a credible replacement. Efficiency should not be measured only by how closely employees follow the default route.

Make the supplier demonstrate your awkward cases

A generic demonstration establishes what a product can do under the conditions chosen for the demonstration. A purchasing decision needs evidence about the conditions in your business. Present a small number of realistic scenarios, with appropriate use of anonymised or synthetic information.

Include an amendment after payment, a change that affects more than one department and an exception requiring approval. Ask to see how the information moves, which person can act and what happens if the task remains unresolved. A promise that the system supports a feature is less useful than understanding how that feature works in the proposed configuration.

This is not an invitation to build an enormous wish list. Rank requirements by customer consequence, operating necessity and commercial value. Distinguish essential capabilities from habits the business would be better off changing. Otherwise procurement becomes an attempt to reproduce every weakness of the existing process in more expensive software.

Budget for the transition, not just the licence

Implementation requires decisions about information quality, responsibility, training and the point at which the old process stops. Running two sources of truth indefinitely can increase the very confusion the purchase was meant to remove.

Give the transition a realistic owner and protect time for the team to learn. Define what must be demonstrated before a stage goes live and what the business will do if the change causes a material problem. The appropriate safeguards depend on the system and its risks; they should be agreed before the busiest trading period becomes an involuntary test.

After launch, assess whether the original customer and operating problem has improved. Completion of the technical project is useful evidence of delivery, but it is not proof that the business case has been realised. Look for work genuinely removed, information made dependable and decisions made easier.

Q Branch's FUSION approach helps connect digital decisions to the experience the organisation is trying to deliver. If you are preparing to replace a system, a Q Branch operational diagnosis can start with the journey it must support. The strongest buying brief describes a business requirement clearly enough that the technology can be judged against it.