Every term, a school somewhere pays for software that ends up sitting unused while the bursar goes back to a spreadsheet and the class teacher goes back to a hardcover register. The software was not broken. It was simply built for a school that does not exist — one with fast internet, a full-time IT officer, and staff who enjoy filling forms.
We build and deploy school systems, so we have watched this failure happen up close. Here is the checklist we now apply before recommending anything.
1. Start from the term calendar, not the feature list
A school does not run on modules. It runs on a rhythm: registration, resumption, continuous assessment, mid-term, exams, results, fees, vacation, repeat. Any system you consider should map onto that rhythm without you inventing workarounds.
Ask the vendor to walk you through one complete term in the software. Not a demo of the dashboard — an actual term. Enrol a student, record three CA scores, run an exam, generate a result sheet, publish it to a parent, and collect a fee. If any of those steps requires exporting to Excel and re-importing, the system will be abandoned by week six.
2. Test it on the worst phone in the staff room
Your teachers will not be using a MacBook. They will be using a mid-range Android phone with a cracked screen, 3GB of RAM, and a data plan they are personally paying for. If the system takes eleven seconds to load a class list on that phone, teachers will stop entering scores until the day before results are due — and then the whole term collapses into one panicked evening of data entry.
Practical tests to run before you buy:
- Load the score-entry screen on a 3G connection and time it.
- Enter twenty scores in a row and see how many taps each one costs.
- Turn airplane mode on halfway through and see whether the entered data survives.
That last one matters more than any feature. Systems that lose half-entered work destroy staff trust permanently, and trust does not come back.
3. Insist on result computation you can audit
Result computation is where school software most often quietly goes wrong. Weighted CA, exam percentages, subject positions, class positions, grade boundaries, promotion rules — each school has its own arithmetic, and many of those rules are unwritten, living only in the head of one experienced teacher.
Before committing, take three real result sheets from last term and ask the vendor to reproduce them exactly. Not approximately. Exactly, down to the position tie-breaks. If they cannot, either the system is too rigid or your rules were never documented — and both are problems worth discovering before you migrate.
4. Decide who owns the data
This is the question schools ask last and regret most. Get clear answers in writing:
- Can you export every student record, score, and payment in a standard format, at any time, without asking permission?
- If you stop paying, how long do you retain access?
- Where is the data stored, and who at the vendor can read it?
A school holds sensitive records on minors. Treat data portability as a hard requirement, not a nice-to-have. A system you can leave is a system you can safely commit to.
5. Count the training cost honestly
The licence fee is rarely the real cost. The real cost is the term you spend getting forty staff to change how they work. Budget for it deliberately:
- One in-person session per staff category (teachers, bursary, admin) rather than one big general session.
- A single named internal champion who is paid or recognised for the extra load.
- A written one-page cheat sheet per role, printed, laminated, and pinned in the staff room.
Schools that skip this step do not save money. They just pay the cost later in wrong results and parent complaints.
6. Roll out one module at a time
The temptation is to switch everything at resumption. Resist it. A safer sequence:
- Term one: student records and attendance only. Low risk, builds familiarity.
- Term two: add scores and result computation, run in parallel with the old method for one term.
- Term three: add fees and parent communication.
Running in parallel for one term feels like duplicated effort because it is. It is also the cheapest insurance you will ever buy against a botched results day.
7. Ask what happens when it breaks
Because it will, and usually at 9pm the night before results are published. Find out:
- What is the actual response time, and is it a person or a ticket queue?
- Is support available in the hours your staff work, including Saturdays during exams?
- Who fixes a data error — you, or them?
A vendor who answers these plainly is worth more than one with twice the features.
A note on our own system
We build EduOS Control against exactly this checklist, because it came out of watching the failures. It is not the right fit for every school, and we will tell you when it is not — a school with fewer than a hundred pupils and one attentive administrator is often better served by a well-structured spreadsheet and a clear filing habit.
The point is the checklist, not the product. Take it to whichever vendor you are considering. The good ones will welcome the questions.
If you want a second opinion on a system you are already evaluating, book a consultation and bring the demo login — we will run the tests above with you.