School management software demos are organised around module count, because module count is easy to compare. Two years after go-live, most schools are using perhaps a third of what they bought, and struggling with two or three things that were never demonstrated at all.
Here is what schools actually use daily, what quietly goes unused, and the requirements that never make it into the tender and always make it into the change requests.
What gets used every single day
Attendance, if and only if it is fast
The most-used feature in any school system, and the one most often built badly. A teacher marking attendance for forty students has about ninety seconds of patience. If it takes six taps per student, the register comes back and the software has lost the argument.
What works: a single screen for the whole class, everybody present by default, mark the exceptions, submit. Absentee notification to parents in the same action. Anything slower gets bypassed, and once teachers bypass one module they treat the whole system as optional.
Fee collection and defaulter tracking
The module with the clearest financial return, and the one that most often fails on local reality. It has to handle: partial payments, sibling discounts, scholarship categories, arrears carried across terms, late fees with waiver authority, and multiple collection channels: bank challan, cash at counter, mobile wallet, online.
The defaulter list is the single most valuable report in the entire system. If generating it takes more than two clicks, the accounts office will keep its parallel spreadsheet, and once a parallel spreadsheet exists the software’s numbers are no longer trusted.
Parent communication
SMS and WhatsApp for absence, fee reminders, results and announcements. High usage, and the primary thing parents judge a school’s professionalism on.
The requirement schools consistently underestimate is segmentation: message one section, one class, one bus route, or all defaulters over 30 days. Systems that can only message “all parents” get used twice a term and then abandoned, because nobody wants to send eleven hundred people an irrelevant message.
Result and report card generation
Used intensely three or four times a year, and the module most likely to cause a crisis. Every board and every school has its own grading scheme, weightings, and report card layout, and the layout is treated as non-negotiable because parents compare it to last year’s.
The failure mode is a system that produces a technically correct report card in the wrong format, and the school printing eleven hundred of them by hand instead.
What gets bought and rarely used
- Learning management modules. Assignments, online submission, quizzes. Bought after 2020 by nearly everyone, used seriously by few outside schools that made it policy and trained for it. The software is rarely the reason it fails.
- Library management. Genuinely used in large schools with a full-time librarian. Elsewhere it is a barcode scanner that nobody plugged in.
- Analytics dashboards. Impressive in demos. Opened by the principal in month one and then not again, because the two numbers actually needed (attendance percentage and fee collection percentage) are available faster elsewhere.
- Biometric integration. Works well for staff. For students it is frequently abandoned over queue length at gate-in time. A throughput problem nobody modelled before buying the hardware.
- Inventory and asset modules. Set up during implementation, never updated after.
The requirements that never make the tender
1. Mid-year structural changes
A student changes section in October. A teacher goes on leave and another takes the class for six weeks. A new section opens in January because enrolment grew. Systems that model the school as fixed at the start of the year handle these as data corruption, and the office ends up making corrections in the database.
2. Siblings
One parent, three children, possibly across two campuses. One fee voucher or three? Sibling discount applied to which child? One login or three? This is trivially common in Pakistani schools and routinely missed in software designed elsewhere.
3. Multi-campus with shared identity
A student transfers from one branch to another and must keep their history. Branch principals see their own data, the director sees consolidated. Fee policy differs by campus but the report card must look the same. This is the requirement that most often forces a mid-project replan.
4. The academic year rollover
Promoting eleven hundred students to the next class, carrying arrears forward, archiving last year, retaining a few students, and handling leavers. This happens once a year, and if it is not automated it is the worst week of the office’s calendar. Ask to see it demonstrated.
5. Offline and low-connectivity behaviour
If connectivity in your area drops for an hour, does attendance stop? For schools outside major cities this is not a hypothetical, and a cloud system with no offline tolerance means the register comes back permanently.
6. Who can waive a fee
Someone will need to reduce or waive a fee for a genuine reason. Which roles may, up to what amount, with what record. Systems without a waiver workflow get worked around with cash adjustments, which is exactly the control problem the software was bought to fix.
How to evaluate a demo properly
- Ask them to mark attendance for a class of forty. Time it. Watch how many taps.
- Ask for the defaulter list, over 60 days, section by section. Count the clicks.
- Give them your actual report card and ask them to reproduce it. Not a similar one. Yours.
- Ask them to move a student between sections mid-term and then show that student’s attendance history.
- Ask them to run the year-end rollover. Most demos avoid this. That avoidance is your answer.
- Ask what happens to the data if you leave. Export format, and whether it includes historical records or only current-year.
Build or buy?
Buy, in most cases. School administration is a well-solved problem and an off-the-shelf system configured properly will serve a single-campus school better than a custom build.
Custom becomes the right answer when you run several campuses with genuinely different academic models, when you need deep integration with existing accounting or transport systems, or when you are a school group intending to license the system to others. The full decision framework is in our note on custom software versus off-the-shelf, and the same underestimation pattern shows up in healthcare. See the seven requirements clinics consistently underestimate.
Frequently asked questions
What features should a school management system have?
Fast attendance, fee collection with defaulter tracking, segmented parent communication, and result generation in your exact report card format. Those four carry almost all the daily value. Everything else is secondary until those work.
How much does school management software cost in Pakistan?
Cloud systems typically charge per student per month, which suits smaller schools. One-time licences and custom builds run from several hundred thousand rupees upward and make more sense for multi-campus groups. Implementation, data migration and training are separate from the licence in every case.
How long does implementation take?
Six to twelve weeks for a single campus, longer for multi-campus. Student and fee data migration is the largest variable: clean data shortens it dramatically, and most schools’ data is not clean.
What is the most common reason these projects fail?
Teachers abandoning attendance because it is slow, and the accounts office keeping a parallel spreadsheet because a report is hard to reach. Both are adoption failures, and both are visible in a demo if you time the tasks.
Ezitech builds and implements school, hospital and ERP management platforms for institutions across Pakistan and beyond. See our school management system or tell us how many campuses you run.