Software evaluations in small schools tend to go the same way. Someone reaches the end of their patience with the spreadsheet, three products get shortlisted from a search, each gives a polished forty-minute demo, and the one whose demo felt best is chosen. Six months later the school discovers the thing that actually matters — that a class change has to be typed into three places, or that a percentage of every payment leaves the building, or that the export everyone assumed existed is a support ticket and a CSV of one table.
None of that is the vendor's fault. A demo is a sales presentation, and a good one shows the product doing what the product is best at. The fix is not to distrust vendors; it is to change who is driving. This cluster covers the three parts of that: requirements written down before you look at anything, a demo run on your own real scenarios, and a short list of answers that mean stop and ask again.
The most common evaluation error is starting from feature lists. Feature lists are written by vendors to be compared with other vendors' feature lists, and they all contain the same words — enrolment, attendance, reporting, payments — which means the comparison produces a tie and the decision falls back to the demo. Requirements written from your own operations do not tie, because they are specific enough to fail.
The unit that works is a scenario, not a feature. "Enrolment" is a feature. "A parent enrols a child in the Tuesday B1 group, pays a deposit, and receives a portal login without anyone at the school touching it" is a scenario, and you can watch a product succeed or fail at it in ninety seconds. The first article covers writing them, scoring them must, should and nice, and the discipline of being honest about which is which — a must is something you would reject an otherwise excellent product for lacking, and most lists have too many.
A demo on the vendor's sample school shows the product at its best: clean data, a timetable with no clashes, invoices that all paid. Your school is not that. Bring a real term timetable, three real enrolment scenarios including the one that goes wrong, an invoice with an instalment and one with a failed card, a teacher absence that needs cover, and a family asking what data you hold about their child. Ask the vendor to do each live.
Then watch two things that no feature list captures. How many screens and how much re-typing each scenario takes — because that is your Tuesday morning for the next five years. And what happens when something does not work, which it will: a vendor who says "that is not how it works, here is what we would do instead" is telling you something useful, and one who changes the subject is telling you something more useful still. The second article is the script, with what to count while it runs.
Beyond the scenarios, a small number of questions do most of the work, and they are the same for every product in this market. Does the student exist once, or once per module? When something changes — a class time, a level, a withdrawal — does everyone who needs to know find out, or does someone have to tell them? What does the platform take from what your students pay you, as a percentage, in writing, priced at the size you expect in three years rather than today? Can you leave with every student, payment, enrolment and attendance record, and is that in the contract? Where is the data, under which law, and is there a processing agreement you can read now? Who answers on a Tuesday morning, and how fast?
Each of those has a home elsewhere in this pillar — the fee question in pricing and total cost, the data questions in the vendor questions article, the comparisons themselves in the comparison pages. This cluster is about making sure they get asked at all.
In schools small enough that one person does the administration, that person must be in every demo, because they are the one who will discover the three-screen enrolment at nine on a Tuesday. Owners evaluate on price and vision; administrators evaluate on friction; teachers evaluate on whether they have to log into another thing. A decision made by the owner alone is usually made on the wrong criteria, and a decision made by committee takes a term. Two people in the room — the one paying and the one using — is the right size.
It is also worth deciding in advance what would make you say no, and writing it down before the first demo. Evaluations drift because enthusiasm accumulates: by the third demo everyone wants it to be over, and the product that is merely adequate starts to look decisive. A written list of deal-breakers, agreed while nobody is excited, is the cheapest protection against that.
SprintUp is a product you might shortlist, and this method is written to be used against SprintUp as well as against everyone else. The scenarios, the script and the red flags are all things we would rather you applied to us than skipped — a school that chooses us after running this process stays, and one that chooses us because the demo was pretty leaves in month six. Where we are limited, the pages in this pillar say so; where a competitor is cheaper, the comparison pages say that too, with their published figures.
Write the requirements, run the demo on your own data, and read the answers properly. Each ends with something you can print and take into the room.