Evaluate school software by testing admission, attendance, fee collection and result preparation with fictional records. Ask a second authorized colleague to retrieve the saved result. Then compare implementation responsibilities, total costs, data export and support terms. A polished dashboard alone cannot establish whether the system fits your daily work.
iilmaa publishes this guide. It is a practical checklist, not an independent vendor ranking. The examples do not represent customer outcomes.
Name the problems before comparing features
Write down three recurring difficulties: repeated student entries, hard-to-find receipts or uncertainty about unfinished attendance, for example. Beside each problem, describe the result you need and who will verify it.
A school, madrasa and coaching center may need different workflows. Review the school requirements, madrasa workflows and coaching requirements to select what applies. You do not need to test every available module to make an initial shortlist.
Give every supplier the same scenario
Use the same fictional student, class and starting records in each demonstration. Compare hands-on work with hands-on work rather than comparing one supplier’s presentation with another supplier’s unfinished trial. Let your staff operate the system, and record where assistance is needed.
| Task | What to check | Evidence |
|---|---|---|
| Admission | One student identity, correct class and guardian relationship | Sample profile |
| Attendance | Correct date and roster; saved marks can be retrieved | Fresh register view |
| Partial fee | Receipt and remaining balance agree | Fictional invoice and receipt |
| Results | Marks, absence and grading rules are distinct | Reviewed result |
| Permissions | Unauthorized work is refused | Allowed and refused actions |
| Export | Required fields remain readable outside the system | Sample export |
Use “demonstrated”, “question open” or “not demonstrated” with an explanation. Numbers without shared definitions can make a comparison look more precise than its evidence supports.
Verify the saved record
After one colleague saves a result, ask another authorized colleague to retrieve it in a fresh view. Information remaining on the original screen does not establish that it has reached its intended destination. Prepare questions using the attendance guide and fee-payment instructions.
Confirm responsibilities and costs in writing
Use the same student count, branches and required modules in every quotation. Separate subscription or licence costs from setup, migration, training, messaging, payment-provider charges and additional assistance. When evaluating iilmaa, check the current pricing and limits; do not assume a particular trial or provider arrangement applies.
Agree who cleans existing records, checks imported samples and authorizes corrections. Use workflow-specific acceptance conditions rather than a promise that every institution can launch within the same number of days.
Before choosing, confirm that staff have completed essential tasks, retrieved saved records and understood connectivity limits. Keep unresolved questions with an owner and next step. Obtain answers about exports, service exit and support availability.
Frequently asked questions
Does the longest feature list identify the best supplier?
Prioritize essential tasks that staff can complete correctly. A feature outside the quoted package, or one that has not been demonstrated, should not outweigh an important verified workflow.
Must we provide real student data at the first demo?
Fictional data is sufficient for the initial evaluation. Agree access, permitted use and responsibilities before any later test that needs institutional records.
Is a demonstration enough to approve a complete rollout?
It can support a shortlist. A small pilot, checked records and written terms give the institution better evidence for its final decision.
Bring your three most important workflows to an iilmaa demonstration and assess them using this checklist.