School Management System in Kenya: 14 Buying Requirements

A school management system should reduce repeated work without turning every school process into a rigid screen. It must fit admissions, learner records, attendance, fees, academic reporting, communication, approvals and management decisions while protecting information about learners, parents, guardians and staff.

The safest buying process begins with the school's actual journeys and responsibilities, not a long feature list. These fourteen requirements help a Kenyan school compare products, commission custom software or replace spreadsheets with a phased system.

Keep the system's role clear

The Ministry of Education describes NEMIS as the national platform for school and learner information used for sector planning and administration. A school's own management system should support its internal operations and required reporting without pretending to replace government platforms. Define which records originate locally, which must be submitted elsewhere and who verifies each transfer.

14 requirements to test before you buy

1. Admissions from enquiry to enrolment

Map application, document collection, assessment, offer, acceptance, class placement and learner-number creation. The system should show missing requirements, prevent duplicate learners and preserve the decision trail.

2. One dependable learner record

Define identity fields, guardian relationships, contacts, medical or support notes where legitimately required, enrolment history and exit status. Avoid copying the same learner into separate spreadsheets for every department.

3. Attendance that fits the timetable

Decide whether attendance is daily, lesson-based, boarding-based or event-based. Include late arrivals, authorized absence, corrections, approval, trend reporting and parent communication without exposing one learner's information to another family.

4. Academic structure and reporting

Model years, terms, classes, learning areas, assessments, grading rules, remarks, moderation and report approval. Version rules rather than silently rewriting historical reports when a scale changes.

5. Fees, billing and receipts

Define fee structures, instalments, scholarships, discounts, penalties, opening balances, payments, reversals, refunds and statements. Separate payment evidence from approval, reconcile mobile-money and bank transactions and retain immutable ledger history.

6. Parent and guardian access

A parent portal should show only the learners and information linked to that verified account. Decide which reports, balances, notices, consents and documents are visible, downloadable or acknowledged. Provide a safe recovery process when phone numbers or guardianship details change.

7. Staff roles and approvals

Teachers, finance staff, administrators, school leaders, nurses, librarians and ICT teams do not need the same access. Use role-based permissions, MFA for staff, recent reauthentication for sensitive changes and an audit trail for exports, corrections and account administration.

8. Communication with consent and delivery evidence

Design notices, fee reminders, emergency alerts and newsletters as distinct message types. Record the intended audience, channel, delivery status and opt-out rules. Avoid putting private learner information in broad mailing lists or insecure group messages.

9. Government reporting boundaries

Document every required return or data exchange, the responsible officer, validation steps and submission evidence. Do not promise automatic integration until the receiving platform, authorization process and supported interface are verified.

10. Privacy throughout the learner lifecycle

Learner and guardian data can remain sensitive long after a school term ends. Kenya's Data Protection Act makes lawful purpose, minimisation, security, access, retention and deletion central design questions. Define which records must be retained, for how long, by whom and how disposal is proven.

11. Security, backup and recovery

Require encrypted connections, protected secrets, secure uploads, session controls, vulnerability management, bounded logs, off-site backups and a witnessed restore. Include procedures for a lost device, compromised account, staff departure, accidental deletion and service outage.

12. Reporting that supports decisions

Reports should answer operational questions: enrolment, attendance, balances, collections, class progress, exceptions and pending approvals. Agree on definitions before building dashboards so two departments do not produce different totals for the same question.

13. Migration and data quality

Inventory spreadsheets, paper files and previous systems before promising a migration date. Define duplicates, missing identifiers, invalid contacts, historic balances, attachments and acceptance checks. Preserve the source and a reconciliation report until the school signs off.

14. Rollout, training and support ownership

Introduce complete workflows in phases, train each role against real tasks and keep a clear support route. The contract should state hosting, backups, updates, response times, data export, account ownership, documentation, handover and what happens if the supplier relationship ends.

Questions that reveal whether a demonstration is real

• Can a teacher correct attendance without deleting the original entry?
• Can finance trace one payment from receipt to learner account and bank reconciliation?
• Can a guardian with two learners use one verified account without seeing another family's data?
• Can the school revoke every session when a staff account is compromised?
• Can reports reproduce last term's figures after rules change?
• Can the supplier restore the system into a clean environment from an off-site backup?
• Can the school export its records in a usable format without supplier intervention?

Frequently asked questions