Evaluate a school ERP by the work it must survive, not by the number of menu items.

A useful ERP decision starts with real school workflows. Ask how admissions becomes a student record, how a fee receipt can be explained months later, how teacher access is restricted, how parents are linked, and what happens when a large import or internet connection goes wrong.

1. Start with a source-of-truth test

Ask the vendor to show one student moving through the system from enquiry to admission, Student Master, attendance, fees and results. The important question is whether those modules reuse one verified identity or create separate records that later need manual reconciliation. A connected system should make it clear which record is authoritative and which actions create history rather than silently replacing it.

Repeat the same test for a staff member and a parent. A teacher account should not automatically become a super-admin account, and a parent account should not expose unrelated children. If the vendor cannot explain identity and permission boundaries in a simple way, the school may spend more time fixing access problems than saving administrative effort.

2. Test permissions with real roles

Do not stop at a generic “Admin / User” demo. Create a realistic office user, class teacher, accountant and parent. Check whether the product can restrict module access and, where needed, class or division scope. Then verify what happens when a restricted user manually enters a private URL. Secure access must be enforced by the application, not merely hidden from the menu.

3. Inspect the fee workflow end to end

A fee module should explain how a due is created, how a payment is recorded, how discount or late fee authority works, and how duplicate receipt references are prevented. Ask to see an old receipt after a later correction. The school should be able to understand what changed and who performed the change without editing the database directly.

4. Treat import as a controlled migration, not a file upload

Schools usually begin with spreadsheets that contain local headers, abbreviations and inconsistent class names. A serious migration flow should preview incoming data before committing it, report missing required fields, identify duplicates and preserve a clear rollback or backup point. Flexible column mapping is useful only when it still leads into the same validation and transaction rules as the official template.

During evaluation, use a small synthetic workbook with deliberate problems: duplicate student identifiers, one blank class, a spelling variant in a division and one invalid date. The preview should show the issues before the production dataset is touched.

5. Verify parent access as a separate surface

Parent convenience is valuable only when identity linking is controlled. Ask how a parent email is verified, how children are linked, who can correct a wrong link, and whether a parent can ever reach staff-only operations. Parent Portal should show approved child information and parent services without inheriting ERP administration rights.

6. Ask what “offline” really means

Some products use “offline” to mean only that a page was cached. For schools with unreliable connectivity, ask whether supported work can actually read and write local data, how pending changes are queued, how reconnect is deduplicated, and what happens when the same record changes in cloud and local mode. Conflict handling should be explicit rather than silently selecting whichever copy was saved last.

7. Demand a backup and recovery demonstration

Backups should not be a marketing checkbox. Ask who can create them, what they contain, how restore is authorized, and whether a backup from one school can be restored into another school. A recovery workflow should protect authentication and tenant identity, validate the backup and provide a deliberate restore decision rather than a one-click destructive action.

8. Separate software readiness from third-party activation

Messaging, payment and identity providers often require separate accounts, credentials, approvals or templates. Ask the vendor to label integrations honestly: software-ready, configured, tested, or live. A product should not claim that a provider is active merely because an integration screen exists.

9. Evaluate the boring daily tasks

Spend more time on repetitive work than on dashboard animations. Mark attendance for a full class, search a student, find a previous receipt, correct a controlled field, generate a report, use the interface on a phone, and sign out. An ERP succeeds when staff can complete ordinary work consistently with fewer duplicate records and fewer unclear hand-offs.

10. Use a simple go/no-go scorecard