How to Choose a School Management System in Nepal

Search for the best school management system in Nepal and you will get a page of vendors, each of whom has decided the answer is themselves. That is not a scandal, it is just how the category markets itself. But it leaves the person actually doing the choosing, usually a principal or an administrator with a term to run, with no way to tell the products apart except by counting features in a brochure.

Feature counts are the least useful thing to compare. Every serious product in this market has students, staff, fees, attendance, exams and notices. The differences that decide whether your institution is still using the system in three years are almost never on the feature list at all. This guide is the checklist we would use, written so it works whoever you end up buying from, including if that is not us.

What a school management system actually is

A school management system is one place that holds the records an institution runs on, students and their guardians, staff, classes, attendance, fees, exams and results, so that those records stay consistent with one another instead of living separately in an admission register, a fee book, three spreadsheets and one person's memory. Some vendors call it school management software, some call it a school ERP. The words differ; the job does not.

That definition is worth holding on to, because it is also the test. If a product would leave your institution with two places where the same fact is written down, it is not doing the job, however long its feature list is.

Why the best is the wrong question

There is no best school management system in Nepal in the way there is a tallest mountain. A 200-student primary school in a hill district and a 3,000-student campus in Kathmandu with a +2 wing are not choosing between the same things, and a product that suits one will feel wrong to the other. What does generalise is the set of questions that expose whether a product will survive contact with a real institution. There are about nine of them.

1. Can your existing records actually get in?

This is where rollouts die, and it is almost never discussed in a demo, because a demo runs on clean sample data. Your data is not clean. Two students share a name, one guardian has three children spread across three classes, half the dates are in Bikram Sambat and half in AD, and someone typed a phone number into the address column in 2079.

So ask to see an import of your own file, not theirs. Specifically: does it check the file and show you the problems before anything is written, or does it write first and leave you to find the mess afterwards? Can you fix the flagged rows and re-run it? If the import goes wrong, can it be reversed? And who does the work, you or them? An answer of "send us the file and we will handle it" is not necessarily bad, but it tells you that you will be asking them again every time.

2. Can your records get back out?

Ask this in the sales conversation, when the answer costs them nothing. If you decided to leave in two years, what exactly could you take with you, in what format, and how long would it take? A vendor who has thought about this will tell you plainly. A vendor who has not will tell you that you would never want to leave.

This matters more than it sounds, because it is the one thing you cannot fix later. Every other bad decision on this list can be worked around by a determined administrator. Data you cannot export is a decision you only get to make once.

3. Where are the permissions actually enforced?

Nearly every product in this market has roles: admin, teacher, accountant, parent. The question is not whether the roles exist but where they are checked. If the software only hides things in the interface, then the record is still reachable by anyone who knows the address of the page, and "the teacher cannot see fee balances" is a statement about a menu, not about your data.

You do not need to be technical to test this. Ask them to log in as a teacher during the demo and then open a page that teacher should not have, by pasting its link. Watch what happens. A refusal is the correct answer. A page that loads, even a broken one, tells you the permission was decoration.

Ask two more while you are there. Does a teacher see every student in the institution, or only the students in the classes they actually take? And when a staff member leaves and their password is changed, does that end the sessions they already have open?

4. Are Bikram Sambat dates native, or bolted on?

Any product can show a BS date on a receipt. The test is whether the system can think in BS. Can you filter attendance for a BS month and get the right days? Does a report generated for Shrawan cover Shrawan, or cover a stretch of July and August that mostly overlaps it? Does a student's date of birth survive being entered in BS, stored, and printed back out?

A converter widget bolted to the front of a system that only really understands the Gregorian calendar will get you through a demo and then quietly disagree with your office at the end of every month.

5. Does it work on the connection you actually have?

Do the demo on your own internet, on the day and at the hour your office is busiest, and if you have a branch outside the valley, do it from there too. Better still, open it on the phone of a parent you know, not on the laptop the salesperson brought. Heavy dashboards look impressive in an office with fibre and become unusable on a slow mobile connection, and by then it is your staff who stop using the system, not the vendor's.

6. Who can see a result before you publish it?

Marks entry is a feature everyone has. Publication control is the part that matters and the part that is frequently missing. While a subject teacher is entering marks, and while the class teacher is still checking them, can a parent open the app and see a half-entered result? If the answer is anything other than a clear no, you have just discovered how your institution will find out, which is from a parent's phone call.

The same question applies to anything else a family sees: fee ledgers, attendance, remarks. There should be a moment you choose, and nothing should be visible before it.

7. What happens at reporting season?

A school management system earns most of its value on the days you have to report. If the data is already structured the way the return expects, reporting is a lookup. If it is not, reporting is a reconstruction, and you do it every year forever.

So ask what the system holds for each student beyond a name and a class, and compare that against what you are actually asked for. Be specific: ask them to show you the screen where those fields are filled in, not the brochure line that says the system is compliant.

8. What does it cost in year two?

Year one is the marketed number. Year two is the real one. Get all of it in writing before you sign, and get it as figures rather than as reassurance.

• Is the price per student, per module, per campus, or flat, and what happens when your student count grows by a hundred?
• Is there a one-off setup or data-migration fee, and is training included or billed separately?
• Which modules are inside the price and which are add-ons, particularly SMS, which is a per-message cost somebody has to bear.
• What does support cost after the first year, and what response time are you actually promised?
• What happens to the price at renewal, and is there anything in writing that limits the increase?

Treat a promise of free forever with the same care as an unusually low quote. The cost has not vanished, it has moved: into advertising, into your data being awkward to get back, or into support that stops replying once you are settled in.

9. Who answers when something breaks in exam week?

Ask for the name of the person who answers, the channel they answer on, and the hours. Ask what happened the last time they had an outage and how their customers found out. Then ask for two institutions of roughly your size and shape, and call them without the vendor on the line. Ask those institutions one question: what do you still do outside the system, and why? The answer to that is the most honest product review you will get.

What to ignore in a demo

A few things that impress in the room and predict nothing.

• The module count. Twenty-six modules where four are finished is worse than eight that work.
• Charts on the dashboard. Nobody runs an institution off a pie chart, and they are among the cheapest things in the product to build.
• Client logos, unless you can call one of them.
• An AI feature you cannot see running on your own data during the demo.
• Anything demonstrated only on sample data. Ask for it again with a class of your own students in it.

Where NepEdu sits, honestly

We built NepEdu around the first three questions on that list, because they are the ones we watched institutions get hurt by. Imports are staged: your file is validated and every problem shown back to you before a single record is written, you fix the flagged rows in a grid, and an import that goes wrong can be reverted. Permissions are checked on the server on every request, so a teacher sees the students in the classes they take and nothing else. Bikram Sambat is native throughout, and results stay invisible to families until you publish them.

Two things we do not do, which you should hear from us rather than discover in month three. There is no payment gateway: fees are recorded as payments your office verifies, not collected through eSewa, Khalti or Fonepay inside the app. And there is no biometric or RFID device integration: attendance is taken in the app, on a phone or a computer, not read off a scanner at the gate. If either of those is the reason you are buying software this year, ask us before you spend time on a demo and we will tell you straight.

Everything else on this page is a question we are happy to be asked, and we would rather you asked it of every vendor on your list, ours included. An institution that chose carefully and picked somebody else is a better outcome for Nepali education than one that chose us on a brochure.