A principal in Lalitpur sat through five vendor demos in nine days. Each one opened the same way: a dashboard full of green checkmarks, a sales rep saying "we handle attendance, fees, exams, and communication - all in one platform," and a screen share that moved too fast to actually evaluate anything.
By the fifth demo, her notes looked identical to the first. Every vendor claimed the same six features. Every vendor said their support was "excellent." Every vendor had a client list that included a well-known school in Kathmandu. She had spent two weeks and had no real way to tell them apart.
This is not a failure of research. It's what happens when you evaluate software without a framework. Vendor demos are built to be persuasive, not comparable - and unless you walk in with your own checklist, you'll walk out with five polished pitches and no decision.
This guide is that framework: the specific questions to ask, the specific things to check, and the specific mistakes that cost Nepal schools months of rework after they picked wrong.
Why Do All School Software Demos Sound the Same?
Every vendor demo is built around the same goal: get to "yes" before you notice what's missing. That means leading with the features every product has - attendance, fees, exams, a parent app - and moving quickly past the parts where the product is weaker.
This isn't necessarily dishonest. It's just how sales demos work everywhere, not only in school software. A demo is a curated 45-minute tour, not an audit. The sales rep chooses what to show you, in what order, and for how long.
The result is that on paper, three or four vendors can look nearly identical. They'll all show you a clean attendance screen, a fee dashboard, and a mock report card. What they won't show you - unless you ask directly - is what happens when the internet drops mid-class, what your accountant's actual daily workflow looks like six weeks in, or what it costs to leave if the product doesn't work out.
A general framework for evaluating any SaaS vendor makes the same point: the demo tests relevance and polish, but trust and fit only show up when you ask pointed operational questions the vendor didn't plan to answer. For a school buying software that will hold years of student records, fee history, and exam data, that distinction matters more than almost any feature on the feature list.
This isn't a Nepal-specific problem, either. Capterra's 2024 Tech Trends Survey found that 60% of businesses regret at least one software purchase within 18 months of making it - and the leading cause wasn't a bad product. It was a rushed evaluation process, with a messy handoff between the sales team that sold the software and the implementation team that actually delivered it. A school has less room to absorb that mistake than most businesses do: a mid-year vendor switch during exam season is a far bigger disruption than swapping accounting software.
The questions you ask in the first meeting decide how much rework you do in month six.
A Tale of Two Schools: One Asked the Right Questions, One Didn't
Picture two mid-sized schools in the Kathmandu Valley, both around 450 students, both evaluating school management software within the same few months.
The first school ran a structured evaluation. Before any demo, the vice-principal wrote down twelve questions - the same ones for every vendor, covering the BS calendar, payment gateways, offline behavior, and what happened to their data if they ever switched systems again. She asked each vendor to answer live, on screen, not from a slide. Two of the four vendors couldn't demonstrate BS-calendar report cards without switching to a "beta" module. One admitted their offline mode was "in development." By the third demo, the shortlist was down to one vendor who could show, not just claim, every answer. Setup took three weeks. Six months later, the accountant was still using the system daily with no data loss and no unplanned costs.
The second school picked based on price and a confident sales pitch. The vendor promised BS-calendar support "in the next update" and Khalti integration "coming soon." Both took four months to arrive - well into the school's exam season, which meant report cards for the first term went out as PDFs typed manually anyway, the exact workaround the software was supposed to replace. When the school asked about exporting their own student and fee data mid-year to move to a different vendor, they learned the export tool only produced a format their own accountant couldn't open in Excel without help from the vendor's support team, which took nine days to respond.
Both schools bought "the same kind" of software. One spent three weeks getting the details right before signing. The other spent four months finding out what they hadn't asked.
Neither school in this example is a Gurukul customer - this is a composite of patterns we see repeatedly across Nepal school software evaluations, not a single institution. The pattern itself is the point: the cost of skipping the checklist rarely shows up in the first month. It shows up in the exam season after.
"We Do Everything" - What That Actually Means
Almost every school management vendor in Nepal will tell you their platform "does everything" - attendance, fees, exams, communication, HR, sometimes a school website. On the feature list, that's often technically true. What the feature list doesn't tell you is how deep each module goes, or which one the vendor actually built first and knows well.
This is a fair tradeoff, not a scam. Most software companies - in Nepal and everywhere else - build one or two modules deeply first, then add the rest to compete on a complete feature list. A vendor whose product started as an attendance app three years ago may still have a genuinely excellent attendance module and a fee module that was added in the last year to keep up with competitors. That's normal software company behavior. The problem is only that the feature list doesn't show you the difference.
The way around this isn't to distrust every vendor - it's to test the modules you'll use most, not just read the ones listed on the homepage. If fee collection is your biggest daily pain point, spend most of the demo there, not on the parts that are easy to make look impressive. Ask to see real screens, not marketing slides, for the specific workflow your staff will run every day.
This is also where comparison content helps, if you use it carefully. A page comparing Nepal's best school management software options for 2026 can narrow your shortlist before you spend time on demos - but treat it as a starting point for your own questions, not a replacement for them.
It's also worth checking what a product connects to, not only what it contains natively. A buyer's guide for classroom management software lists integration with the tools a school already uses - communication channels, existing content, assessment platforms - as a separate evaluation criterion from the core feature list. The same logic applies in Nepal: if your school already has an SMS gateway, an accounting workflow, or a website you're attached to, ask whether the new system plugs into that or forces you to replace it too.
Who Should Be in the Room During the Evaluation
The principal is rarely the person who will use the software daily, which means the principal alone is the wrong person to run the entire evaluation. A decision made in isolation, based only on how confident the sales rep sounded, tends to surface problems only after the contract is signed.
A workable evaluation team is small: the principal or vice-principal to own the decision, the accountant who will run fee collection daily, one senior teacher who represents the attendance and exam workflow, and - if the school has one - whoever currently maintains the Excel sheets and WhatsApp groups the software is meant to replace. That last person often asks the sharpest questions, because they know exactly where the current process breaks.
Each person in the room should walk away from the demo having tried the one workflow they'll personally own. If the accountant never touches the fee screen during the demo, you haven't actually evaluated the fee module - you've watched someone else use it.
The Buyer's Checklist: What to Actually Evaluate
This is the core of the framework. Before you sit through another demo, write these down - or print this table - and score every vendor against the same criteria. Don't let any vendor skip a row.
| # | Criterion | Why It Matters | Ask the Vendor | |---|-----------|-----------------|-----------------| | 1 | Bikram Sambat calendar support | Your academic year, attendance, and report cards all run on BS dates. AD-only software forces manual date conversion for every report. | "Show me a report card and an attendance report with BS dates live on screen - not a mockup." | | 2 | Local payment gateway integration | Parents pay through eSewa, Khalti, Fonepay, and cash. If the system only supports Stripe or manual reconciliation, your accountant does the matching by hand anyway. | "Walk me through what happens from the moment a parent pays via Khalti to the receipt appearing in our system." | | 3 | Offline or low-bandwidth behavior | Many schools outside Kathmandu deal with unreliable connectivity. A system that freezes or loses data during an outage is worse than paper. | "What exactly happens if the internet drops while a teacher is halfway through taking attendance?" | | 4 | Ease of use for non-technical staff | Your attendance teacher and accountant are not IT staff. If daily tasks take a training manual to complete, adoption fails quietly within weeks. | "Let my actual attendance teacher or accountant try this task live, with no help from your rep." | | 5 | Pricing model transparency | Per-student pricing scales predictably. Flat annual licenses plus "customization" or "setup" fees often balloon after signing. | "Give me the total cost for our exact student count, in writing, including every fee - not just the headline number." | | 6 | Data ownership and export rights | Your student records, fee history, and exam data are yours. If you can't export them in a usable format, you're locked in regardless of what the contract says. | "If we left in six months, what file format would we get our data back in, and how long would it take?" | | 7 | Support responsiveness and language | When a report card won't generate the night before distribution, you need an answer in hours, not a ticket number and a 3-day SLA. | "What's your actual average response time, and can support communicate in Nepali if my staff need that?" | | 8 | NEB grading alignment | Grade calculation, GPA, and report cards need to match NEB's official grading scale for SEE and +2 - not a generic percentage system that someone reformats by hand. | "Generate a sample report card using NEB's A+ to NG grading scale, live, for a student with mixed grades." | | 9 | Migration effort from your current system | Moving from Excel or paper isn't free. The real question is how much manual re-entry your staff will do versus what the vendor migrates for you. | "What specifically do you import for us, and what do we have to type in ourselves?" | | 10 | Security and role-based access | Fee data, exam marks, and student records need different access levels for a teacher versus an accountant versus a parent. One shared login is a liability. | "Show me what a teacher can see versus what an accountant can see versus what a parent sees, on three different logins." | | 11 | Contract length and exit terms | A one-year lock-in with no early-exit clause is a real risk if the product doesn't work out after two months of live use. | "If this doesn't work for us in the first three months, what does leaving cost us?" | | 12 | Integration with tools you already use | If your school already runs an SMS gateway, an accounting workflow, or a website, a system that can't connect to any of it means you maintain two sets of records instead of one. | "What does this connect to out of the box, and what would we have to give up if we switched to your platform?" |
Score each vendor from 0 to 3 on every row: 0 if they can't answer or demonstrate it, 1 if it exists but is clearly limited, 2 if it works well, 3 if it's a genuine strength. A vendor scoring consistent 2s and 3s across all twelve rows is in a completely different category from one that scored well on the first five and went vague on the rest.
Bring the same twelve questions to every demo, in the same order, and write the answers down in front of the vendor. This does two things: it keeps you from being swept along by whichever rep presents most confidently, and it signals to the vendor that you're running a real evaluation - which tends to produce more honest answers.
How to Actually Run the Evaluation Meeting
A good evaluation meeting isn't a passive demo you sit through. It's a working session where you control the agenda. A few adjustments make a real difference:
Bring your own data, not the vendor's sample data. Ask the vendor to enter one real fee structure or one real student record from your school live on screen. Sample data is always clean. Your data has the edge cases - siblings with different fee categories, a mid-year transfer, a student with an unusual attendance pattern - that reveal whether the software actually handles your reality.
Put your actual staff in the room, not just yourself. The principal isn't the one taking attendance every morning. If your attendance teacher or accountant can't operate the core workflow after watching it once, that's information the vendor's polished dashboard won't show you on its own.
Ask for a trial period with your real students, not a demo account. Any vendor confident in their product should be comfortable with a short pilot - a week or two with one class or one grade - before you commit the whole school. If a vendor resists this, that's worth noting on its own.
Compare total cost of ownership, not the sticker price. A detailed breakdown of what school management software actually costs in Nepal is worth reading before your first demo, so you know which line items to expect and which ones are padding.
Ask what happens during connectivity gaps before you sign, not after. This is where a lot of Nepal schools get burned, particularly outside the Kathmandu Valley. The difference between cloud and offline-capable school software isn't abstract - it decides whether a teacher can take attendance during a power cut or has to fall back to paper and re-enter it later.
What Migration Effort Actually Looks Like
Every vendor will tell you migration is easy. Ask them to define "easy" in hours, not adjectives.
The honest version usually looks like this: student names, grades, and sections import in a spreadsheet upload within a day. Historical fee ledgers - who paid what, when, and what's outstanding - take longer, because formats vary wildly between schools and almost never come out clean on the first try. Historical exam marks are usually not worth migrating at all; most schools start fresh from the next exam cycle instead of re-keying years of old marksheets.
If a vendor tells you migration will be instant and complete with zero manual work, that's the answer to write down and be skeptical of - not because they're lying, but because "instant and complete" almost never survives contact with a real school's messy, years-old spreadsheet. A more detailed breakdown of the process from a widely used SaaS evaluation checklist makes the same point for software buyers generally: ask what specifically the vendor migrates versus what your team re-enters, and get it in writing before you sign, not after.
The schools that switch with the least disruption pick one module - usually attendance or fees - go live on it for a few weeks, confirm it's solid, then add the next. The schools that struggle try to migrate everything on day one and end up running two systems in parallel out of fear, which defeats the purpose of switching at all.
Red Flags Worth Walking Away From
A few patterns are worth treating as disqualifying, not just noteworthy, during an evaluation:
- "That feature is coming next quarter." If a core feature you need - BS calendar, a specific payment gateway, NEB grading - isn't live today, don't buy on a promise. Roadmaps slip, and your exam season won't wait for an update.
- No answer on data export. If a vendor can't clearly explain how you'd get your own data out in a usable format, that's not a minor gap. It's the difference between choosing a vendor and being stuck with one.
- Pricing that requires a sales call to understand. Reasonable customization has reasonable pricing. If the only way to learn the real cost is a 45-minute call, budget for surprises later. Gurukul publishes module-based pricing for exactly this reason - a school should be able to work out its own cost before booking a call, not after.
- No willingness to run a small pilot. A vendor confident in their product will let you test it with one class before committing the whole school. Resistance to a pilot is usually resistance to scrutiny.
- No verifiable local track record. A number of school software vendors have sold into Nepal's market and quietly stopped supporting their product within a few years, leaving schools with data they couldn't move and no one to call. Ask how long the vendor has actively supported schools in Nepal specifically, not just how long the company has existed, and ask for a current customer you can actually call.
Bringing This Into Your Own Evaluation
You don't need to interview every vendor in Nepal to make a good decision. Three to four vendors, evaluated against the same twelve-row checklist, with real staff testing real workflows, is enough to see clear separation between products that only look similar on a feature list.
The framework matters more than any single vendor - including us. If you run this checklist against Gurukul, ask the same twelve questions you'd ask anyone else: BS calendar, live on screen. eSewa and Khalti reconciliation, walked through step by step. What happens during a connectivity gap. What your data export looks like if you ever leave. Those answers should hold up under the same scrutiny you'd apply to any vendor - and if they don't, that's useful information too.
Set a realistic timeline for the whole process, and hold yourself to it. Two to three weeks for demos and scoring, one week for reference checks and a short pilot, and a decision by week four is achievable for most schools - and it's fast enough that you won't be tempted to skip a row on the checklist just to move things along. Evaluations that drag on for months tend to end the same way the Lalitpur principal's did: five demos that all blur together, and a decision made on gut feeling anyway.
Buying school management software is not a decision you want to redo in eight months because nobody asked about BS dates or data export in the first meeting. Twenty minutes with this checklist, before your next demo, is cheaper than a school year spent working around software that almost fits.
Ready to run this checklist against a real product? Book a free demo of Gurukul and bring your twelve questions - we'll answer them on screen, not from a slide deck.
