Choose school management software by testing your own daily workflows with sample records. Ask an administrator, a teacher, and an accounts colleague to complete the same tasks in each shortlisted system. Keep the evidence, unanswered questions, and written quotation together. A feature list alone does not show whether your staff can use the system reliably.

This guide provides a blank evaluation method for institutions in Bangladesh. iilmaa publishes it, and it is not an independent vendor ranking. The examples are fictional; they do not imply customer results or prices.

Start with the work your school must complete

Write down three tasks that currently cause delays or corrections. Useful examples include finding a guardian’s verified contact, checking who has not had attendance recorded, or matching a fee receipt to the correct student. Describe the expected result before the demonstration starts.

Give every vendor the same scenario and starting records. Do not compare a polished presentation from one supplier with hands-on testing of another. Decide who will operate the system, who will review the result and what evidence they should retain.

For a practical overview, review the school management workflows and student record features. Confirm which functions and limits apply to the package being demonstrated.

Use an evidence-based scorecard

The table below is intentionally blank. Use “passed”, “needs clarification” or “not demonstrated” rather than awarding numbers without a shared definition.

Workflow Expected result Evidence to keep Outcome
Admit a student One profile, correct class and verified guardian relationship Sample profile reference Fill after demo
Record attendance Correct date and roster; saved result survives a fresh view Register reference and review notes Fill after demo
Collect a partial fee Receipt and remaining balance agree Fictional invoice and receipt Fill after demo
Correct marks Authorized correction follows the institution’s grading rules Before/after example and approval record Fill after demo
Restrict staff access A teacher sees only the permitted scope Allowed and refused task results Fill after demo
Export records Required fields remain readable outside the product Sample file and field check Fill after demo

A demonstration can reveal a missing feature, a configuration requirement or a training need. Record which explanation applies. If the supplier cannot demonstrate an essential task, leave it unresolved rather than assuming it will work after purchase.

Ask a second staff member to retrieve the result

After one person saves a sample record, ask another authorized colleague to find it in a new view. This simple handoff checks whether the demonstration produced a persistent, usable record. An entry remaining on the original screen is weak evidence by itself.

Use fictional identities throughout. A supplier does not need real student records to explain its basic workflow. Keep sensitive examples inside the institution’s approved environment when later acceptance testing requires them.

Compare costs and implementation responsibilities

Request a written quotation using the same student count, branches and required modules for every supplier. Separate recurring subscription costs from setup, migration, training, messaging, payment-provider charges and additional support. Ask which assumptions could change the quotation.

Check the current iilmaa pricing information when assessing iilmaa. Provider approval, transaction charges and institution-specific setup need separate confirmation. Do not treat a displayed payment logo as proof that an account is ready to accept payments.

Agree who cleans existing records, maps fields, reviews imported samples and signs off the initial roster. Set acceptance conditions before discussing a launch date. A small trial should produce evidence for the school’s essential tasks; it should not become a promise that every institution can migrate in the same number of days.

Record exceptions before making a decision

Keep one shared list with the unresolved question, responsible person, evidence required and review date. Typical questions concern connectivity, correction permissions, export completeness and support availability. For connectivity, use the attendance instructions to prepare questions about the actual supported workflow, rather than assuming that every function works offline.

Before selecting a supplier, confirm:

  • Essential workflows have been demonstrated using the agreed scenarios.
  • Staff have retrieved and reviewed the saved results.
  • Costs, responsibilities and service limits are written down.
  • Data-export and service-exit questions have answers.
  • Unresolved issues have an explicit owner and next step.

Frequently asked questions

Does the supplier with the most features always win?

No. Prioritize the tasks your institution must complete correctly. A feature that your staff cannot use, or that is outside the quoted package, should not outweigh an essential workflow that has been demonstrated successfully.

Should we give a vendor real student data during the first demo?

Use fictional records for the initial evaluation. If a later migration test needs institutional data, agree access, permitted use and handling arrangements first. Share only the records necessary for that test.

Can this scorecard prove which software is best in Bangladesh?

It can help your institution document its own decision. It does not establish a universal market ranking or independent review. Different institutions have different requirements, operating constraints and budgets.

Bring your three most important workflows to an iilmaa demonstration, and use the same scorecard to check the evidence.