Will people have the time to learn? Can the information be trusted? Who decides how the process works? What happens when the person who set it up is away?
Answering those questions before committing gives you a clearer view of the investment. It can also reveal a smaller change that would solve the problem sooner.
Start with a piece of work
Choose a recent example of the work you want to improve. Follow it from the first request to the point where someone considers it finished.
For a customer enquiry, that might mean the website form, the inbox it reaches, the person who qualifies it, the quotation and the handover to delivery. Ask the people involved to show you what happened, including the spreadsheet or message thread that kept things moving.
Record where information was copied, where a decision waited and where somebody had to fill a gap from memory. Include the exceptions. A tool that handles the straightforward case beautifully may still leave the most difficult work untouched.
This gives you something specific to test in a demonstration. Ask the supplier to work through your example. Find out which steps are standard, which need configuration and which require another product or custom development.
- Real workFollow a recent example.
- ReadinessCheck ownership, people and information.
- Small testName an owner and review the evidence.
Agree what should improve
Write down the result you are buying the software to support. “A better CRM” leaves too much open. “Every accepted enquiry has a named owner and a recorded next action” gives the team something they can observe.
Take a baseline before changing the process. It could be the time between a request and its first useful response, the amount of rework, or the number of cases that need someone to chase missing information.
Keep the measure proportionate. A short sample, explained honestly, is more useful than a dashboard built from unreliable data. Pair the figures with what customers and colleagues experience.
The GOV.UK Service Standard makes a useful connection between defining success, measuring performance and listening to users. Its public-sector requirements do not apply to every business, but the underlying discipline is useful when choosing software.
Check the conditions around the product
Digital maturity describes how reliably the organisation can make digital choices and carry them through. Before a purchase, look for evidence in a few practical places.
Ownership. Name the person responsible for the process and the person who can resolve competing requests. Buying the system does not settle who can change a customer record or approve an exception.
People. Ask users what they will need to do differently. Allow time for practice and support after launch. Include people with different roles, levels of confidence and accessibility needs in the trial.
Information. Identify the records the new system will depend on. Decide which source takes priority when values conflict, who maintains it and what needs cleaning before migration.
Connections. Follow information into and out of the product. Check how integrations behave when a record changes, a connection fails or a duplicate appears. Establish who will notice and resolve the problem.
Security and privacy. Work out what information the service will hold, who needs access and what evidence you need from the supplier. The NCSC's supply chain guidance is a useful starting point for assessing supplier risk. Involve the people responsible for information security and data protection before committing.
These questions belong together. A reliable integration still needs somebody to own the information it moves. Training will struggle if the new process leaves an important decision unresolved.
Cost the work around the licence
A monthly subscription is only one part of the decision. Include configuration, migration, integrations, training, support and the staff time needed to run the change. Check what happens to the price when usage, storage or team size grows.
Look beyond the first year. Who maintains a custom integration? What happens when the supplier changes its product? How will you export usable information if you leave, and what will that cost?
Consider the alternatives alongside the purchase. You might simplify the existing process, make better use of a tool you already own, connect two systems or build a focused service. Each option has costs and responsibilities. A custom build also needs ongoing maintenance and somebody able to make product decisions.
Be precise about benefits. Time released from administration is useful capacity; it becomes a cash saving only if spending actually falls. Explain how the team will use the capacity instead of counting every saved minute as money returned.
Test a manageable change
Run a trial around a defined piece of work with a named owner. Agree what needs to happen before you expand it, and what would make you stop or change direction.
Include ordinary users and an awkward case. Check the handover, permissions and support route as well as the screen everyone liked in the demo. Use test information where possible and follow your organisation's controls before introducing real personal or confidential data.
Ask what the new process allows you to retire. If the team must keep the old spreadsheet indefinitely to make the new system work, find out why before adding more users.
Make a decision you can explain
A useful readiness review should finish with a decision: proceed, run a smaller trial, resolve a specific gap or keep the current approach for now.
Record the evidence, the remaining uncertainty and the person responsible for the next step. Set a review point that fits the work rather than an arbitrary launch anniversary.
The aim is to give a worthwhile investment the conditions it needs. Understand the work, make room for the change and choose software the organisation can use well.
Based on Yopla source material from 2023. Refreshed for this edition.
All insights