Every school-software brochure lists the same modules: attendance, exams, fees, portals. Committees that compare brochures end up choosing on price and regret it by the second term — because the differences that decide whether staff adopt the system or route around it are never on the brochure. After enough evaluation seasons on both sides of the table, these are the questions we believe committees should put to every vendor, including us.
Ask about the data model before the features
A feature is a screen; the data model is what the screen writes to. Ask one question: "If a teacher marks attendance, where does the parent SMS read from?" In a coherent platform there is one answer — the marked record. In assembled suites there are two databases and a sync job, and the day the sync hiccups, the SMS tells a parent their present child is absent. Every downstream promise — reports, analytics, portals — inherits its truthfulness from this answer.
- Can a student exist twice? (Re-admissions are where duplicate records breed.)
- When a session ends, is history preserved or archived away from the working system?
- Do marksheets compute from marks, or are totals typed into a layout?
- Is the academic structure (departments, classes, sections, subjects) shared by every module, or configured per module?
Governance is a feature — demand to see it
Institutions run on accountability, and software either supports it or dissolves it. Ask to see, on live screens: who may publish results and who may not; what a locked attendance day rejects; what the audit trail records when a mark changes. If the answer to "who changed this?" is a shrug, every future dispute lands on the principal’s desk with no evidence either way.
The cutover question decides the first year
Whatever you buy, your institution already has years of records. Vendors who say "just re-enter the current students" are quietly deleting your history. Ask precisely: what moves, how it is verified, and what proof you receive before the old system is switched off. A dry run with record counts compared against the source is a reasonable demand — accept nothing vaguer.
Score the parent experience like a parent
Parents will judge the institution by the portal more often than by the prospectus. Open it on a phone. Count the taps from "my child was absent — why?" to an answer. Check whether a fee receipt needs a phone call. The committee member with the least patience is your best evaluator here.
What to put in the RFP
- Per-institution data isolation, stated structurally (not "role-based access" alone).
- Audit trail coverage: publications, unlocks, record edits, sign-ins.
- Migration method with parity verification, in writing.
- Local time zone and currency handling for every operational record.
- A named support model — people, hours, escalation — not a ticket portal.
None of these questions requires technical staff to ask. They require only the willingness to look past the brochure — which is exactly what distinguishes the committees whose systems still serve them well ten years later.