Choosing a School ERP: A Buyer's Guide for Indian Schools

Most school ERP evaluations are run on a feature list, and feature lists do not distinguish between products — every vendor ticks every box. What distinguishes them is whether the system survives contact with your fee structure and your academic calendar.

Decide what you are actually buying first

Schools describe the need as "an ERP" when the real problem is usually one of three things:

• Fee collection and arrears. Money is leaking or the picture is unclear. Highest-value, clearest payback.
• Parent communication. Office phones are constantly busy with routine queries.
• Academic administration. Marks, report cards, board formats.

Buy a system that can do all three eventually, but name which one you are solving this year. A project without that focus tries to launch everything simultaneously, which is the most reliable way to fail.

The test that separates real products from demos

Take your actual fee structure — with every exception — to the demo, and ask the vendor to configure it in front of you. Include:

• Different heads per class, with the boundaries where they change
• Staff-ward and sibling concessions, percentage and flat
• Transport by distance slab or route, and what happens mid-year when a family moves
• Optional heads applying to some students only
• Late fees with a grace period, and the principal's waiver
• RTE or scholarship students billed differently

A vendor who can build this live has implemented for schools like yours. One who says "that can be customised" is telling you it will be a development request after you have paid.

This single exercise is worth more than the rest of the evaluation combined, because the fee structure is where implementations overrun.

The questions most evaluations skip

Feature comparisons are largely a waste of time, because every vendor has the modules. Where products genuinely differ is underneath — the server the data sits on, whether a backup actually reaches you, and what happens when the connection drops. Almost nobody asks about these, and they are the things that decide whether a school loses work or loses records.

"Automatic" is the word that matters in a backup

Every vendor says they back up. The question that separates them is whether a copy arrives with you, without anyone doing anything.

A backup the vendor holds and would restore on request is not protection against the scenario it is meant for — a dispute, an unresponsive vendor, a vendor who has gone quiet. In that situation a backup requiring their cooperation is worth nothing.

So ask it precisely:

• Does a copy reach the school automatically, or only when requested?
• Where does it arrive — our email, our storage, or a portal on your system?
• How often, and can we set the frequency ourselves?
• How many days are kept?

Our own system schedules this: a school sets hourly or daily, whichever suits, and the backup goes out on its own. A school taking fees all day is not in the same position as a small pre-primary, and neither should be stuck with whatever interval a vendor decided. Daily is the sensible floor for any school collecting fees — a day's receipts is a day of counter work nobody wants to reconstruct.

Retention is worth understanding as two separate things, because they answer different risks:

• On our server we keep the last seven, with the oldest replaced automatically. That is operational — enough history to roll back a bad import or recover something deleted last Tuesday.
• In the school's own mailbox, every copy stays for as long as the school chooses to keep it. Nobody expires it but the school.

That second tier is the one that matters for the scenario at the start of this article. A vendor-side retention window, however generous, is still a window held by the vendor. A copy in the school's inbox from three years ago is the school's, regardless of what happens to the relationship.

What happens when the internet is bad

Connectivity is not uniform across India, and a cloud system that stops working when the line drops stops the fee counter with it. In several states this is not an edge case — it is a normal week.

Ask what continues to work offline, and what happens to the work done during an outage. The two answers that matter:

• Can staff keep issuing receipts and entering records while the connection is down?
• Does that work sync to the live server automatically once the connection returns, or does someone re-enter it?

Ours continues working offline and syncs with the live server when connectivity comes back. Work does not stop and nothing is re-typed. Not every system does this, and it is expensive to add later because it is an architectural decision rather than a setting.

The server your children's data sits on

Low-cost ERP is low-cost partly because of what it runs on. A school holds a great deal of personal information about minors — names, addresses, parent contact details, photographs, sometimes medical notes — and where that sits is a fair question to ask before price is discussed.

Ask where the servers are, who has access, and what the security arrangements are. A serious vendor will answer plainly. Vagueness here is itself informative.

Ours run on our own infrastructure rather than resold space, and we take a daily offline copy of them as well — a backup that is not reachable over the network at all. That last part is deliberate: an online backup shares the fate of whatever compromises the system it is attached to, which is the entire reason ransomware goes looking for backups first.

Boards: what is common, and what genuinely is not

Vendors talk about board support as though each board needs a different product. Most of it does not. Fee structure — heads, instalments, concessions, late fees, transport slabs — works the same way whether a school is with CBSE, UP, Maharashtra or Rajasthan. That is why one system can serve all of them, and why a vendor charging a premium for "board-specific" fee handling is charging for something that is not there.

What genuinely differs is the calendar, and it differs more than most people outside the sector realise:

This is not a display setting. The session start date determines when the academic year rolls over, when promotion and section reallocation run, when roll numbers regenerate, when the fee cycle begins, and which year arrears belong to. A system that assumes an April start will be wrong about all of it for a school in Maharashtra, and wrong by nearly half a year for one in Kashmir.

So the question to ask is not "do you support my board". It is "can the session start date be set per school, and does everything downstream follow it?" A vendor who has only ever implemented for one board may never have had to find out.

Report formats still need to be demonstrated

Fee handling being board-independent does not extend to reporting. Report card formats are prescriptive, they change, and they are where manual work accumulates.

Ask to see one generated, on screen, in your board's current format. The gap between "supported" and "produces the correct format without manual reformatting" is a term's worth of work every term — and it is a gap that does not show up in a feature list.

What to ask about the parent app

• Does it work on low-end Android phones and poor connections? Your parent base is not uniform.
• Is it available in the languages your parents actually use?
• Can a parent with two children in the school see both without logging out?
• Can fees be paid in the app, and where does that money settle?
• What does a parent see if they have not paid — and is that appropriate for your school?

That last question is worth thinking about. Some schools want arrears visible; others consider it inappropriate for a child to see. It should be configurable.

Sequence the rollout

A sequence that works, with roughly a term between steps:

1. Fees. Alone, through one full collection cycle, until it is boring.
2. Parent communication. Now that parents have a reason to have the app.
3. Attendance. Once the process and exception handling are agreed.
4. Examinations and report cards. Timed to start with a term, never mid-term.
5. Everything else — transport, library, payroll, inventory.

Compressing this is the single most common cause of failure. Schools that succeed almost always went slower than they planned to.

Questions about the vendor, not the product

1. How many schools of our size and board do you support? Can we speak to two?
2. Who does the data migration, and what does clean data look like to you?
3. What time does your support line open? Schools run from 7am; most software companies answer from 10, which covers none of the morning fee counter.
4. What is your support response time during fee collection week?
5. What happens at academic year rollover — do you assist the first time?
6. If we are in a payment dispute with you, what happens to our access?
7. How do we get a routine copy of our own data, without asking you for it?

The third matters more than it looks. Support quality during the two weeks of a collection cycle is the difference between a system staff trust and one they work around.

The last two matter more than anything else on the list. A school's records — admissions, fees, student history, personal details of children — are held on a platform the school does not control. If losing access is possible, everything else is secondary. Ask for the answers in writing, and treat a vendor who will not commit as having answered.

Commercial points worth pinning down

• Pricing basis — per student, per module, flat — and what happens as enrolment grows
• Whether implementation and migration are included or separate
• What training is included, and whether refresher training after staff turnover costs extra
• Annual maintenance, and what it covers
• Whether configuration changes — a new fee head, a changed concession — are chargeable

Fee structures change every year. A vendor charging for each change converts a fixed cost into a recurring one.

About the author. Kislay Chandan has worked with schools since 2014. Rather than gathering requirements from the outside, he worked inside a school to see what actually goes wrong day to day, and built what he found into the software. He still works with Shemrock Glitters in Patna — most changes to the product start with something that came up there.