What to ask before you buy school software

Feature lists are nearly useless

Every vendor's list says students, fees, attendance, exams, transport, library. The list tells you almost nothing, because it does not say how well any of it works or whether the parts connect.

A better question than "do you have transport?" is "if a student changes their bus stop mid-term, what happens to their fee?" One question about a workflow you actually run reveals more than an hour of slides.

• Ask them to perform your workflows in the demo, not their script
• Bring a real awkward case — a mid-term joiner with a sibling concession and a bus stop
• Ask what the system does not do; a vendor with no answer is not being straight

Who owns the data, and can you leave

Your student records, fee history and academic results are the school's asset. Get it in writing that they remain yours, and establish before signing how you would get them out.

Ask specifically: can we export at any time, in what format, and what happens to our data if we stop paying? A vendor who is vague here is describing a lock-in you will discover in three years.

• Ownership of school data stated in the contract
• Export available at any time during the subscription
• A defined window after termination to retrieve data
• A stated deletion timeline, including backups

Test security claims

"Bank-grade security", "ISO certified" and "100% secure" appear constantly in this market and mean nothing without evidence. If a vendor claims a certification, ask for the certificate and its scope.

More useful than any badge: ask concretely how one school's data is kept from another's, where documents are stored, whether uploaded files are reachable without logging in, and what happens if a laptop with an open session is stolen.

• Ask for evidence of any certification claimed
• Ask how tenant separation actually works
• Ask whether uploaded documents are reachable by URL without authentication
• Ask what is logged, and who can see student records

Implementation is where projects fail

Software rarely fails because a feature was missing. It fails because it was never configured properly, existing data was never migrated, and staff were left to work it out.

Find out who does the setup, whether your existing student data will be imported or retyped, how staff will be trained, and what support looks like in week six rather than week one.

• Who configures the academic structure and fee terms — you or them?
• Is existing student data imported, or entered by hand?
• What training is included, and for how many staff?
• What is the support channel and expected response time?

Understand the whole cost

The subscription is rarely the full figure. Implementation, data migration, customisation and messaging are usually separate, and messaging in particular is usage-based and easy to underestimate.

Ask for a written breakdown covering the first year and the renewal, and ask what happens to pricing at renewal. "Unlimited messaging" deserves particular scrutiny — the underlying platform charges per conversation, so someone is absorbing that cost or the claim is not what it sounds like.

Questions worth asking every vendor

A short list that tends to separate vendors quickly.

• What does your system not do?
• Who owns our data, and how do we export it?
• Which sub-processors receive our data, and where is it hosted?
• What exactly happens when a student changes transport stop mid-term?
• Who configures the system, and is our existing data imported?
• What is the full first-year cost, and what changes at renewal?
• Can we speak to a school currently using it?