← All articles

Choosing the Best School Management System in Kenya: A Buyer's Guide

A vendor sits across your desk with a laptop and a confident smile. The demo is smooth: colourful dashboards, a parent app, a slide that promises to transform your school. Forty minutes later you are nodding, and the only number you remember is the monthly price. This is how most Kenyan schools choose a management system, and it is why so many of them are unhappy a year later.

The problem is rarely that the software was bad. It is that the demo answered the vendor's questions, not yours. A school management system is not a gadget you buy once. It is the place your learners' records, your fee ledger, your assessment history and your parent relationships will live for years. Choosing one is closer to hiring a bursar than to buying a printer, and it deserves the same scrutiny.

This guide gives you a framework to evaluate any vendor rather than simply be sold to. Seven questions separate a system that will serve your school from one that will trap it. Ask them in every demo, and insist on specific answers rather than reassuring adjectives. Where the guide notes how Opero answers, treat that as one worked example of what a good answer sounds like, not as the only acceptable option.

First, be clear about what you are actually buying

Before the criteria, a reframe. You are not buying features. You are buying a multi-year relationship with a company that will hold your school's most sensitive information and touch your daily operations. Features can be added later; a broken relationship, a vendor who goes quiet, or data you cannot get back are far harder to fix.

So evaluate two things at once. There is the product: can it do the work? And there is the arrangement: what does this look like over three years, and what happens if you decide to leave? A dazzling product on a bad arrangement is a slow trap. The seven criteria below cover both, and they are written so you can score any vendor on the same scale.

The right question is never "what can this system do in a demo?" It is "what will this system, and this company, be like to live with in year three?"

1. Does it work with M-Pesa, and does it reconcile by itself?

In Kenya, fees move on M-Pesa. So the first practical test is whether the system connects to your Paybill and posts each payment against the right learner automatically, or whether someone still keys them in by hand from an SMS.

Ask to see it happen. When a parent pays, does the payment land against that child's fee account on its own, through a Paybill or STK Push flow, with an instant receipt? Or does "M-Pesa integration" really mean a staff member copying figures into a spreadsheet at the end of the day? That difference is the first two weeks of every term.

Automatic reconciliation is the capability that pays for the whole system, in saved staff hours and in fewer children sent home over fees their families already cleared. If a vendor cannot demonstrate a live payment matching itself to a learner, treat the integration claim as unproven until they show you. For the detail of how this should work, see our guide to automating fee collection with M-Pesa.

2. Was it built for CBC, or bolted onto it?

The Competency Based Curriculum changed what schools must record, not only what they teach. A report card built for the old mean-score world cannot honestly carry competency levels by strand and sub-strand, formative evidence kept separate from summative results, and a learner portfolio that follows the child from grade to grade.

Ask the vendor to produce a CBC report card from the system, using your own grade levels. Look for performance recorded against expected outcomes, such as Exceeding, Meeting, Approaching and Below, per strand, rather than a single percentage dressed up in new language. Ask how a subject teacher enters assessments, and whether that teacher sees only their subject or the whole class.

Systems designed for 8-4-4 and retro-fitted for CBC tend to fail at the worst moment: when the sub-county or KNEC asks for data the structure was never built to give. If the CBC support looks like a bolt-on, assume it is one, and ask to see the awkward cases rather than the tidy demo record.

3. Who owns the data: the school or the vendor?

This is the criterion schools skip, and the one that hurts most later. Under Kenya's Data Protection Act, 2019, your school is the data controller for its learners' personal data. The software vendor is, at most, a data processor acting on your instructions. That is a legal position with duties attached, not a marketing line.

So ask three blunt questions. Can we export everything, on demand, in a usable format, without raising a support ticket and waiting? Is our data isolated from other schools' data, enforced at the database level and not just hidden by the screen you are shown? And what happens to our records if we stop paying or decide to move on?

If the honest answer to "can we get all our data back" is "contact support", the real answer is no, and you should keep looking. A school should be able to walk away with its complete records intact. We wrote a whole piece on why this matters and what the law expects: who owns your school's data.

If leaving a vendor means abandoning your own children's records, you did not buy software. You rented your history, and the vendor kept the key.

4. Does it still work when the internet does not?

Kenyan connectivity is real but uneven. Power dips, a router fails, or the fibre is cut on the road outside, and for a few hours the office is offline. The question that matters is what your school can still do inside that window.

Ask the vendor plainly: what happens when the internet drops during a busy morning? Can the bursar still issue a receipt, can a teacher still record marks, and does the system hold what was entered and sync it once the connection returns? A platform that becomes a blank screen the moment the line drops will fail you on exactly the days you are busiest.

You do not need a system that runs forever offline. You need one that degrades gracefully instead of stopping dead, and that never loses what your staff typed while the connection was down. Ask for a specific description of that behaviour, not a promise that outages "rarely" happen.

5. Is support local, and can you reach a human?

When something breaks in the first week of term, you do not want a ticket portal in a distant time zone. You want someone who understands a Kenyan school calendar, speaks to your context, and answers the phone.

Ask who supports the system, where they are based, and how you reach them: phone, WhatsApp, email, and during what hours. Ask what a realistic response time looks like during the term-opening rush, not on a quiet afternoon. Ask whether onboarding and training are included, or billed separately once you have already committed.

Good support is not a soft factor to weigh lightly. It is the difference between a bad morning and a lost week. Treat it as heavily as any feature on the slide, because you will need it most on the days when the pressure is highest and there is no time to wait.

6. How does migration off spreadsheets actually work?

Every school already runs on a system, even if that system is a stack of spreadsheets, an exercise book and a filing cabinet. Getting from there to a new platform is where many rollouts stall, so make migration a formal part of the evaluation rather than an afterthought discovered in week one.

Ask exactly how your existing data comes across. Who does the work, you or the vendor? What format do they need your current records in? Are outstanding fee balances brought over at a clean term boundary, and can you run the new system alongside the old one for a fortnight before you trust it fully? A vendor who has migrated Kenyan schools before will have a clear, calm answer. A vendor who waves the question away is quietly telling you the first month will be chaos.

The safest migrations are boring: import once at a term boundary, verify the balances against your own figures, run in parallel briefly, then retire the spreadsheet. If the proposed plan is anything other than boring, ask why, and do not accept a switch that happens overnight with no fallback.

7. What is the total cost, including training and year two?

The monthly price on the slide is rarely the real cost. Add setup and data migration, training for staff, any per-parent or per-message charges, hardware you may need to buy, and the price in the second year once the introductory rate ends.

Ask for the total cost of the first year in writing, then the expected cost of the second. Ask what is included and what is billed on top: training sessions, extra modules, support tiers, SMS bundles. A fair vendor will give you a straight number. A vendor who is vague about year two is often hoping you will feel too committed to switch by the time it arrives.

Cheap software that eats staff time is expensive. Slightly pricier software that reconciles fees by itself and saves a fortnight each term can be the cheaper choice once you count the hours. Judge cost against the work removed, not against the sticker price on its own.

Total cost is not the monthly price. It is setup, training, per-message fees, year two, and the staff hours the system saves or wastes. Add all five before you compare vendors.

How Opero answers these questions

We built Opero as a school operating system for Kenya, so these are the questions we designed around rather than the ones we hope you forget. Fees connect to M-Pesa through a payment prompt the parent approves on their phone, and each prompted payment posts to the right learner by itself; payments sent straight to the Paybill are still recorded by the bursar, and we say so up front. Assessment is modelled the way CBC is actually shaped, with competency levels held by strand. The arrangement is deliberate: Opero runs the system, and the school controls its own data, isolated per school, backed up nightly with a restore tested every week, and exportable on demand. Support is local and reachable, and migration is a planned import at a term boundary rather than a leap of faith.

We are not the only system that could answer these criteria well, and a good head teacher should make every vendor earn the sale. But the point of the framework holds no matter who you choose: the individual modules matter less than whether the whole thing joins up and stays yours. That is the argument behind treating a school as one backbone from admissions to alumni instead of a drawer full of disconnected tools.

Key takeaways

  • You are buying a multi-year relationship, not a demo. Judge the arrangement as hard as the product.
  • Insist on live proof of M-Pesa reconciliation, not a claim on a slide.
  • Make sure CBC assessment is native, not bolted onto an old mean-score report card.
  • Confirm the school owns and can export its data, isolated from other schools.
  • Test what happens when the internet drops, and check that support is local and reachable.
  • Get the total first-year and second-year cost in writing, including training and messaging fees.

Frequently asked questions

What is the best school management system in Kenya? There is no single best system for every school. The best one is the system that answers the seven questions above for your context. A large boarding school and a small junior school have different needs, so use the framework to score each vendor honestly and weight the criteria that matter most to you.

How long does it take to move from spreadsheets to a new system? For most schools the core import happens at a term boundary and takes days, not months, when the vendor helps. The safest approach is to import once, verify balances against your own records, run the new system alongside the old one for about two weeks, then retire the spreadsheet.

Does a school management system work without reliable internet? It should degrade gracefully. Ask specifically whether staff can still issue receipts and record marks during an outage, and whether the system saves that work and syncs it when the connection returns. Do not accept a system that becomes a blank screen the moment the line drops.

Who owns the data in a school management system? Under the Data Protection Act, 2019, the school is the data controller and the vendor is a processor. In practice that means you should be able to export all your records on demand and take them with you if you leave. If you cannot, the arrangement is wrong regardless of how good the features look.

See the framework answered on your own school

The fastest way to test any system, including ours, is to bring your real questions to a live walkthrough and watch the vendor answer them with your school's own shape on the screen.

Book a demo and put the seven questions to us directly. If we cannot answer them well, you will walk away with a sharper checklist for every other vendor you meet.


Opero is a school operating system built for Kenya. Start with the whole backbone, from admissions to alumni, or book a walkthrough.

Choosing the Best School Management System in Kenya: A Buyer's Guide | Opero