The pattern is consistent enough to be predictable. A problem becomes acute — usually in the last third of the year, usually after something went visibly wrong. Someone is asked to look into options. Three vendors demo. A decision is made, largely on the strength of the demos and the price. Rollout is scheduled for the start of the next academic year. And roughly a third of the time, eighteen months later, the school is looking again.
The failure is rarely the product. It is the process, and it goes wrong in four identifiable places.
The first is that the decision-makers are usually not the users. The people in the room are a business manager, a head, and possibly an IT lead. The people who will touch the software forty times a day are teachers and office staff, and they are typically consulted after the contract is signed. This is how schools end up with systems that are excellent for reporting to governors and painful for the person taking a register on a corridor phone in a corridor with poor signal. If the daily users have not tried it before purchase, you are buying on someone else’s behalf.
The second is that demos are optimised to avoid difficulty. A demo runs on clean sample data with no part-time contracts, no dual curriculum, no mid-year joiner with a complicated custody arrangement, no family paying in instalments across two currencies. Every product works well on the easy case; the easy case is not why you are buying. The fix is straightforward and almost nobody does it: bring your three hardest real scenarios, anonymised, and ask the vendor to demonstrate those specifically. How a vendor responds when the answer is "that is not supported" is itself extremely informative.
The third is that switching costs are systematically underestimated. The licence fee is the visible number, so it is the number that gets compared. The real cost includes data migration, retraining every member of staff, running two systems in parallel for a term, the productivity dip while people relearn their jobs, and the reporting continuity you lose when historical data does not come across cleanly. A cheaper product with a harder migration is frequently the more expensive decision, and the comparison spreadsheet almost never has a row for it.
The fourth is that the process asks "is this good?" rather than "is this better than what we have, by enough to justify the disruption?" Those are very different questions. Every product will be better than your current system in some respects. The question that matters is whether the improvement exceeds the cost of the change, and the honest answer is sometimes no.
A better process is not more elaborate. It is mostly a different order.
Write down the problem before looking at products. Specifically: what happens today, how long it takes, who does it, and what it costs when it goes wrong. "Our timetable takes two weeks in July and one person can do it" is a problem statement you can evaluate against. "We need better school management software" is not, and it will lead you to buy whatever demos best.
Involve the daily users early enough that their objections can change the decision. Not a demo they watch — a trial they use, on their own tasks, on their own devices, in their own building with its actual connectivity.
Test with real data. Most vendors offer a trial. Load one year group of genuine, anonymised data rather than the sample school. This single step surfaces more truth than every reference call combined, because it is the point at which the assumptions the product makes about how schools work meet the way your school actually works.
Ask about exit before you enter. Can you export everything, in a usable format, including history? How long does it take, and what does it cost? A vendor confident in their product will answer this comfortably. A vendor who becomes evasive has told you what the relationship will be like in year three.
And check the second year’s price. Introductory pricing is common, and a renewal at a materially different rate is much harder to refuse once your data and your staff habits are in the system.
One recommendation that costs nothing: talk to a reference customer the vendor did not choose. Any product can supply three delighted schools. Ask in a headteachers’ network, or find schools on the vendor’s customer list and approach them directly. The gap between the curated reference and the randomly selected one is where the truth usually sits.
We publish our full feature set and our pricing openly for this reason — the useful conversation for a school is a specific one about their hardest cases, not a general one about capability. If a product cannot handle your awkward scenarios, both sides are better off knowing during evaluation than during rollout.
The schools that buy well are not the ones with the biggest budgets or the most thorough scoring matrices. They are the ones who defined the problem before they looked at solutions, and who let the people doing the work test it before the contract was signed.