Questions to ask
any vendor

This is the question that decides whether you can ever leave. A school that cannot export its own student records, marks and fee history is not a customer — it is a hostage.

A straight answer naming the formats you get out (not "we will help you if you leave"), whether you can run an export yourself without asking, and whether it includes historical data or only the current year.

Student data is children’s data. Where it sits determines which law protects it and how fast the software feels from your staff room.

A named region, not "the cloud". Plus whether data is encrypted at rest and who on the vendor’s side can read it.

This is where most demos quietly fail. A teacher halfway through marking a register in a corridor with no signal either keeps their work or loses it, and losing it means the register was never taken.

Specificity. "It works offline" is not an answer — ask exactly which actions survive a dead connection, and what happens to the rest.

A parent who cannot read the fee reminder will not pay it, and will ring the office instead. Language support is a collections and workload question, not a nicety.

A list of languages, and crucially which surfaces are translated. Many systems translate the parent app and leave every staff screen in English.

Per-module pricing looks cheap in year one and becomes a negotiation every time you want a feature. Per-student pricing penalises you for growing. Ask what year two costs.

The shape of the price in writing, what triggers an increase, and whether modules are gated behind a higher tier once you depend on them.

Whatever fraction of your parents will not install an app is the fraction that will not receive anything you send through it.

A path that works without an install for parents who will never complete one, and an app for those who want it.

Fee collection is the one module the management will judge on day one. "We have a fees module" and "parents can pay from their phone and it reconciles" are very different products.

The named payment gateway, who holds the money and for how long, what the per-transaction cost is, and whether reconciliation is automatic or a monthly spreadsheet exercise.

If the UDISE+ return is still assembled by hand from the software’s reports, the software has not removed the work — it has moved it.

The specific returns and certificates it generates, and whether they come from live records or from a form someone retypes.

Your accountant already has a system and will not move to a school ERP. If fee collections do not reach it cleanly, someone keys them in twice.

Honesty about whether it integrates or replaces. A school ERP that claims to be your ledger usually is not.

This is the question to ask any vendor advertising AI. A language model asked to produce a score will produce a confident one, and it may be wrong in a document a parent keeps.

A clear separation: arithmetic by code, wording by the model. If the vendor cannot tell you which part of the pipeline produced a number, treat the number as unverified.

Fee arrears are the most sensitive thing in the building. In a school where families are related and children share classes, a leak is a dispute between families, not an IT ticket.

A role model the vendor can describe without hedging, and a demo logged in as a teacher rather than as an administrator. Ask to see it, do not ask whether it exists.

The single most common reason a school ERP fails is that nobody ever finished loading the data. Find out whose job that is before you sign, not after.

A named timeline, who performs the migration, what format your existing records need to be in, and what staff training is included.