Start with the record, not the feature list
Almost every school management system sold in Nepal lists the same modules: admissions, attendance, fees, examinations, library, transport. Comparing those lists tells you very little, because the lists are nearly identical. What differs is whether those modules read from one student record or from separate tables that have to be reconciled.
The test is simple. Ask a vendor to show you a single student, mid-year, who has changed section, has a partial fee waiver, missed a week of classes, and sat a re-examination. Systems built around one record show that in a single view. Systems that stitched modules together show you four screens and an explanation.
Check the grading scheme before anything else
This is where most implementations in Nepal run into trouble. Report cards must match the grading scheme your board actually uses, including the way grade points, theory and practical splits, and pass criteria are calculated. A system that cannot reproduce your existing report card exactly will create term-end work that never goes away.
Bring a real, completed report card from last term to the demo and ask the vendor to reproduce it. If that cannot be shown in the demo, treat it as unresolved rather than as a configuration detail to settle later.
Decide what parents and students should see
Parent access is the feature schools most often buy and least often plan. Deciding this early changes which system fits: some publish everything by default, others let you control visibility per field, per class or per term.
Work out in advance whether parents should see attendance daily or weekly, whether marks appear before the school has verified them, and whether fee dues are visible to the student as well as the guardian.
What actually drives the cost
Licence price is rarely the largest number in a school software project. The costs that surprise buyers are data migration, configuration of your grading and fee structures, training during a live term, and the internal time spent running old and new processes in parallel.
- Data migration — how many years of student, fee and result history move across, and in what condition
- Configuration — grading schemes, fee heads, waivers, class structures and shifts
- Training — how many staff, in which term, and who trains new joiners afterwards
- Parallel running — the weeks where your team maintains both the old and the new system
- Ongoing support — response times during admissions and examinations, when it matters most
Ask about the term-end, not the demo
Software looks similar in a demo and behaves very differently in the last week of a term. Ask each vendor what happens when results are due, fees are being collected and admissions are open simultaneously — and specifically, how quickly someone responds and whether that person is in Nepal.
Local implementation support is not a soft consideration in this category. A school cannot postpone a results deadline while waiting on a support queue in another timezone.
A short vendor checklist
Take these to every demo and score them the same way. Vendors that fit an operation answer these concretely; vendors that do not will redirect to the feature list.
- Show one student, mid-year, with a section change, a fee waiver, absences and a re-examination
- Reproduce our current report card from our own grading scheme
- Show exactly what a parent sees, on a phone
- Explain how many years of history migrate, and what is lost
- Tell us who answers on the day results are due, and where they are based
- Show the audit trail for a changed mark and a reversed fee entry
