Get started
All modules & pricing
Base platformStaff portalStudent portalParent portal

Base Platform

The school record every other module is built on — pupils, staff, classes, subjects, terms, attendance, results and access control — plus the staff, student and parent portals, included with every subscription.

Get startedTalk to us₦9,900.00/mo

What this module is

Most school software is sold as a stack of features and delivered as a stack of silos. The register does not know the timetable, the timetable does not know the gradebook, the gradebook does not know which child moved class in January, and none of them know the parent. The result is a school that re-types the same eight hundred names into four systems every September, and a head teacher who cannot answer "how is this child doing" without opening three of them.

The Base Platform is the answer to that, and it is not an add-on: it ships with every active subscription and cannot be switched off. It holds the school itself — sessions and terms, stages, grades and class arms, the subject catalogue, the rooms — and the people in it: every pupil with their guardians, every employee with their department and role. On top of that record sit the things a school does daily: attendance, assessments and the gradebook, broadsheets and psychomotor reports, result approval and publication, promotion at the end of the session, behaviour and discipline, notifications, the request queue that carries approvals, the reporting suite, and an audit trail that records who did what.

It also includes the three portals, which are not modules and never will be. Every employee gets a staff workspace the day they are created. Every pupil gets a student portal. Every guardian linked to a pupil gets a parent portal. Add-ons like Library, Health Clinic or School Fees surface inside those same portals when a school buys them — but the portals themselves, and everything above, are the base.

What follows walks the whole core, role by role: the school office that sets it up and runs it, the two teaching workspaces a role grants, the self-service every employee has, and the student and parent portals on the other side of the record.

What you get

One record, entered once

A pupil exists once. The library, the clinic, the bursary, the register and the parent portal all read the same row — so admissions, transfers and leavers propagate instead of being re-keyed per system.

The school year is a real object

Sessions carry terms, one of which is current. Every mark, register, invoice and report is stamped with the term it belongs to, which is what makes "last term" a query rather than an archive folder.

Structure that matches your school

Stages, grades and class arms are configured, not assumed — a junior and senior secondary school looks different from a through-school, and both are describable without a workaround.

Access control you compose yourself

Roles are built from the platform's own action catalogue rather than chosen from three tiers. A bursar sees finance, a librarian sees the desk, a form teacher sees their class — and you decide where those lines fall.

Marks that become results without re-typing

Assessments feed the gradebook, the gradebook feeds the broadsheet, the broadsheet is submitted for approval, and approval publishes to pupils and parents. One chain, no spreadsheet in the middle.

Attendance that means something

Registration and per-lesson attendance both exist, both feed the pupil record, and both feed the at-risk calculation — so a child present at 8am and missing from period four is visible as exactly that.

Three portals, included

Staff, student and parent portals ship with the subscription. They are integral constituents of the platform, not seats or upgrades, and their availability does not depend on which add-ons you buy.

Reporting over the whole school

Enrolment, attendance, academics, behaviour, health, finance, HR, operations and communication each get a section of one reporting suite, drawn from the live record rather than an export.

An audit trail that records refusals too

Consequential actions are logged with the actor, the resource and the outcome — including attempts that were denied, which is the half most systems throw away and every inspection asks for.

Every flow, every role

How Base Platform actually works

Everything below is the real application, running live on this page with sample school data — not screenshots. Each screen is the same one your team would use.

On this page

School office

The school office is where the record is created and governed. These sixteen screens are the base platform in the order a school meets it: describe the institution, describe its year and its shape, put the people in, decide who may see what — then run the year, and answer for it afterwards.

1

Start on the school's own dashboard

The landing page is assembled from the modules the school actually runs, so it grows as the subscription does. On the base package alone it already carries enrolment, attendance, academic standing and risk.

A per-portal card set — the school office, a teacher, a pupil and a guardian each land on a different arrangement of the same underlying record.
Live figures rather than a report you schedule: today's attendance, current enrolment, outstanding approvals.
The card set is drawn from the modules the school runs — the demo school below has every add-on enabled, so it shows the fullest version of the page.
Every card is a link into the screen behind it, which is how most days in the office actually start.
2

Describe the school itself

Before anything else exists there is the institution: its name, its contact details, the currency it bills in, and the locale its dates and money render in. This screen is also where a new school learns what it still has to do.

School identity — name, short code, addresses and contact points — used across every document the platform produces.
Currency and locale set once, so money is formatted consistently from invoices to reports to the parent portal.
A setup-progress indicator that names the remaining steps, so onboarding is a checklist rather than a guess.
Document templates and operating hours live alongside, for the artefacts and schedules the rest of the platform reads.
3

Define the session and its terms

The academic year is the spine of everything else. Marks, registers, invoices, promotions and reports are all stamped with the term they belong to, and this is where that calendar is declared.

Sessions with a start and end date, one of them marked current.
Terms within a session, each with its own dates, ordinal position and short form.
Term status — active or archived — so a closed term stops accepting new marks without being deleted.
The sidebar period picker reads from here, which is how every screen in the platform knows which term you are looking at.
4

Set out the shape of the school

Stages, grades and class arms are configured rather than assumed. A school running a junior and senior secondary section describes exactly that; a through-school describes something else. Nothing downstream has to be told twice.

Academic stages selected per school — Early Years, Primary, Junior Secondary, Senior Secondary — which narrows every stage filter in the platform to the ones you actually run.
Grades within each stage, in order, with the number of class arms each carries.
Class arms with a code, a room, a capacity and a form teacher.
A pupil belongs to a class, a class belongs to a grade, a grade belongs to a stage — the chain the timetable, the gradebook, billing and reporting all walk.
5

Build the subject catalogue

Subjects are defined once and referenced everywhere: on the timetable, in the gradebook, on the broadsheet, on the report card and in a teacher's assignment. Adding one here makes it available to all of them.

Subjects with a code, a title and the department they belong to.
Compulsory versus elective, so a class's expected subject list is derivable rather than manually maintained.
Assignment of subjects to grades, which is what determines whose gradebook a subject appears in.
Rooms are configured alongside, for timetabling and for the class arms that sit in them.
6

Put the pupils on the record

This is the roll — and it is the only roll. Every add-on module, every portal and every report reads pupils from here, which is the single biggest reason a school stops maintaining four lists.

Pupil records with admission number, class, grade, stage and status.
Admission, transfer between classes, withdrawal and alumni status as first-class states rather than a spreadsheet colour.
Per-pupil detail — timeline, documents, ID card — reachable from the row.
Bulk import for a school arriving with an existing roll, so onboarding is not a typing exercise.
A pupil created here immediately has a student portal, a library membership, a clinic record and a billing identity — with no second registration anywhere.
7

Link guardians to their children

A parent portal is not an account someone signs up for — it is the consequence of a guardian being linked to a pupil. This screen is where that relationship is made, and it is what makes fee notices, results and announcements reach a family.

Guardian records with contact details and relationship to each ward.
One guardian linked to several children, and one child to several guardians — including the case where they are at different addresses.
The link is what grants the parent portal, scoped to exactly the wards on it and nothing else.
Guardian contact details are what fee reminders, result notifications and school announcements are dispatched to.
8

Create the employees

Every member of staff is a record here first. Creating one is what brings their staff portal into existence — before any role is granted, before any module is bought.

Staff records with employee number, job title, department, contract type and employment status.
Status covering active, on leave and exited, so cover and access follow the actual state of employment.
An onboarding state per employee — invited, in progress, completed — for the gap between hiring and starting.
Form-teacher designation, which is what connects an employee to the class whose broadsheet they own.
9

Group them into departments

Departments are the organisational structure the rest of the platform reports, approves and covers by. Teaching, finance, operations, student support — whatever the school actually uses.

Departments with the staff assigned to each.
Used by reporting to break staff figures down, and by approvals to route to the right desk.
The grouping HR add-ons build on when a school buys them — but the structure itself is base.
10

Decide who can see what

Access control is composed, not chosen. Roles are built from the platform's own action catalogue, so the line between what a bursar and a form teacher can reach is a decision the school makes rather than a tier it pays for.

Roles assembled from individual actions, grouped by the namespace they belong to — students, academics, finance, library, and so on.
A plain-language summary of what a role grants, so the person approving it does not need to read action codes.
Role assignment to individual employees, with more than one role per person where the job needs it.
The same role that grants a module's workspace is what puts that module in the employee's sidebar — access and navigation are one decision, not two.
Every grant and revocation lands in the audit trail.
11

Watch attendance across the school

Registers are taken by teachers; this is where the office sees the consequence. Today's position, the pupils drifting below threshold, and the definition of "below threshold" itself.

Today's marks across every class, as they come in.
Pupils below the school's attendance threshold, surfaced as a worked list rather than a figure to go looking for.
Configurable thresholds, so "at risk" means what this school means by it.
Per-pupil attendance history reachable from any row.
12

See which children need attention

Risk monitoring is the base platform doing something with the data it holds rather than only storing it: attendance, academic standing and behaviour combined into one score per pupil, so support goes where it is needed instead of where it is noticed.

A risk level per pupil — high, medium, low — computed from attendance, academics and behaviour rather than assigned by hand.
The component scores shown beside the overall one, so the reason for a flag is visible.
School-wide counts at the top, which is the number a governing body asks for.
Thresholds configurable per school, because the same attendance rate means different things in different settings.
13

Approve and publish results

This is the gate between a teacher's marks and what a family sees. Results arrive per class from form teachers, are checked here, and are published in one action — which is the moment they appear in the student and parent portals.

Submission state per class, so an incomplete term is visible before publication rather than after a complaint.
Review of the submitted broadsheet and psychomotor reports before anything is released.
Publication as a deliberate act, with the school deciding when families see marks.
Published results flow to the pupil's portal, the guardian's portal and the pupil's permanent record at once.
14

Promote at the end of the session

End of year is the one process every school does the same way and every school does by hand. Here it is candidates per class, measured against rules the school wrote, decided in a batch.

Promotion rules defined per school — the thresholds that separate promoted, repeated and referred.
Candidates listed per class with the evidence the rule is being applied to.
Batch decisions with per-pupil overrides, because a rule is a starting point rather than a verdict.
A recorded promotion history per pupil, visible to them and their guardian in their own portals.
15

Work the approvals queue

A school runs on small approvals — a record change, a result submission, a document request. The platform routes them into one queue with an owner and a state, rather than into somebody's inbox.

Requests from across the platform in one list, with the module and the requester on each row.
A status trail through pending, approved and rejected, with the approver recorded.
Sent and received views, so a member of staff can see their own outstanding requests as well as the ones waiting on them.
Every decision lands in the audit trail with its reason.
16

Report on the whole school

Every module carries its own Reports & Analytics page, and the Reports module gathers them into one view. Students & Attendance is shown here. Each card is a metric owned by the module whose data it describes, so a school sees exactly the cards its permissions and subscription allow — nothing is duplicated, and nothing is hidden in the nav while staying reachable underneath.

Pupil attendance for the period: marks taken, present, late, absent and excused, with the resulting rate against a target.
Every card carries its own period selector. Set the page period to move them together, or change one card to pin it while the rest follow.
Compare any figure against the previous period or the same window last year, with the direction coloured by whether a rise is good news — a climb in overdue fees is not the same kind of news as a climb in collections.
Lateness broken down by day of the week — the breakdown that turns "we have a lateness problem" into "we have a Monday problem".
Drag and resize the cards; the arrangement is remembered per person, per page, at every screen size.
Trends across the term rather than a single snapshot, drawn from the live record rather than an export.
17

Answer for what happened

The audit trail records consequential actions with the actor, the resource, the action and the outcome — and it records refusals as well as successes, which is the half that matters when someone asks whether a control actually held.

Who did it, to what, when — with the actor's display name and roles frozen as they were at the time, so a later role change does not rewrite history.
Allow, deny and error as distinct outcomes, with the deny reason recorded on refused attempts.
Filters by action, resource type, outcome and date range, with reads hideable so write activity can be read on its own.
A correlation id per event, so a single user action spanning several records can be reconstructed end to end.
Tamper-evidence via a monotonic sequence and a hash of the previous row.
CSV export for the periods an inspection or a board asks about.

Subject teachers

A subject teacher is a member of staff whose role adds a teaching workspace. Nothing here is bought separately — assessments, the gradebook, assignments and per-lesson attendance are all base. What the role decides is which classes and subjects appear.

1

Keep the marks

The gradebook is where continuous assessment actually lives. Marks are entered against the assessment scheme the school configured, and the weighting is applied for you rather than re-derived in a spreadsheet each term.

Assessments per subject and class, each with its own weight in the term total.
Marks entered per pupil, with the running total updating as the term proceeds.
The grading scale the school defined applied automatically to produce a letter or band.
These marks are the source the broadsheet reads — a form teacher never re-types them.
2

Set and mark work

Assignments are created here and appear immediately in the pupils' portal. Submissions come back into a marking queue, and the mark posts to the gradebook rather than being copied into it.

Assignments with a brief, a due date and the class they are set for.
Submission counts and states per assignment, so chasing is a list rather than a memory exercise.
A marking view per submission, with feedback that reaches the pupil in their own portal.
Marks flow into the gradebook, which is what keeps the two consistent.
3

Take attendance per lesson

Registration attendance answers whether a pupil came to school. Subject attendance answers whether they came to your lesson — a distinction most systems collapse and most schools care about.

A register per class and subject, marked in bulk with per-pupil exceptions.
Present, late, absent and excused as distinct states rather than a tick or a blank.
Marks feed the same pupil attendance record the office monitors, so per-lesson absence shows up in the school-wide picture.
Prior marks visible beside the register, so a pattern is apparent while the class is in front of you.

Form teachers

A form teacher owns a class rather than a subject. Their workspace is the other teaching half of the base platform: the daily register, the whole-class picture across every subject, the conduct report, and the submission that sends both to the office.

1

See the class as a whole

The form teacher's landing screen is the class in one view — attendance, academic standing and the pupils who need attention — rather than a subject at a time.

Each form class with its roll, today's attendance split and a performance index.
Risk alerts per class, so the pupils to follow up are named rather than inferred.
The strongest and the most-pressured class called out where a teacher holds several.
2

Take the morning register

Registration attendance for the form class, marked in a few clicks. The panel beside it carries the term's pattern and the pupils the data says to watch.

Mark the whole class present and correct the exceptions, which is how a register is actually taken.
Present, late, absent and excused, with the previous mark shown per pupil.
The term's attendance split and a seven-day trend beside the register.
Risk alerts naming pupils by the pattern that triggered them — attendance below threshold, consecutive lates.
3

Build the broadsheet without building it

Every subject's marks for the whole class on one sheet, with averages and positions computed. This is the document form teachers traditionally assemble by hand each term; here it is a view over marks that already exist.

All subjects for the class in one grid, drawn from each subject teacher's gradebook.
Per-pupil totals, averages and class position computed rather than entered.
Missing marks visible as gaps, so an incomplete term is obvious before submission.
Comments per pupil where the school's report format calls for them.
4

Record conduct and skills

The affective and psychomotor half of a report card — punctuality, neatness, participation, handwriting — recorded against the school's own template rather than a fixed list.

Templates configured per school, so the traits assessed are the ones on your report card.
Ratings per pupil per trait, entered for the whole class in one pass.
Submitted for approval alongside the academic broadsheet rather than separately.
5

Submit the term to the office

One action sends the broadsheet and the psychomotor reports to the school office for approval, with the class's completeness visible before it goes.

Completion state per pupil and per subject, so nothing is submitted half-finished by accident.
A single submission covering both the academic and the behavioural half of the report.
Status visible after submission — pending, approved, returned — so a teacher is not left wondering.
Approval at the office is what publishes results to pupils and families.

Every other employee

The staff portal is not a module and is not a seat. Every employee gets it the day their record is created — before any role is granted and regardless of which add-ons the school has bought. What a role adds is extra sections; what it can never do is take this away.

1

A workspace for every employee

A bursar, a caretaker, a lab technician and a head of year sign in to the same self-service workspace. It is the platform's answer to the assumption that only teachers need an account.

Their own day, their notices and their own records in one place.
Present for every employee whatever their role — the sections a role grants appear alongside it, never instead of it.
Where an add-on is enabled and the employee's role grants it, that module's workspace joins this sidebar rather than becoming a separate login.
2

The school calendar, as it applies to them

Terms, school events and — for teaching staff — the periods they are timetabled for, in one calendar rather than one per source.

Session and term boundaries from the academic year the office configured.
School-wide events visible to every employee.
Timetabled periods for staff whose role includes teaching.

Students

The student portal ships with the subscription. Everything in this chapter is base platform — a pupil needs no module bought on their behalf to see their timetable, their work, their marks or their attendance.

1

Their own starting page

A pupil lands on today rather than on a menu: the lessons ahead, what is due, and anything the school needs them to see.

Today's timetable and what is next.
Assignments approaching their due date.
Notices addressed to them or their class.
2

Know where to be

The full weekly timetable as the school configured it — the same source the teacher's timetable is drawn from, so the two cannot disagree.

3

See the subjects they take

The subjects on their record, with the teacher for each — derived from the class they are in and the school's subject catalogue rather than entered per pupil.

4

Do the work

Assignments set by their teachers, with due dates, submission state and — once marked — the feedback that came back.

Set work with the brief and the deadline.
Submission from the portal, so the queue on the teacher's side fills as pupils finish.
Marks and written feedback returned to the pupil rather than read out in class.
5

Get the resources

Notes, revision packs and resources their teachers published, organised by subject and week, with progress tracked per item.

Materials grouped by subject and by the week they belong to.
Multiple resource types per item — files and links.
Per-pupil progress, so a teacher can see what has actually been opened.
6

See their marks when the school publishes them

Results appear in the pupil's portal at the moment the office publishes them — not before, and not as a photocopy weeks later.

7

See their own attendance

Their register history, so a pupil can see the pattern the school is seeing rather than hearing about it in a meeting.

8

Follow their own progression

The classes they have moved through and the decision behind each move — their record of progress through the school, held by the school.

Parents & guardians

A guardian gets a portal because they are linked to a pupil, not because a module was bought. This chapter is the point of the whole record: everything the school knows about a child, gathered per child, for the person who asks about them most.

1

Sign in to their children, not to a system

A guardian lands on a summary of every ward before clicking anything — which is the difference between a parent portal people use and one they are chased to log into.

Every ward on one page, with the state of each.
Scoped strictly to the children linked to this guardian and nothing else in the school.
One account covering children in different classes and different year groups.
2

One page per child

The ward page pulls every module together for one pupil — attendance, results, fees, clinic, library, discipline — so a parent has one destination per child rather than one per module.

Attendance and academic standing beside each other, because a parent reads them together.
Sections for add-on modules appear when the school has them and stay absent when it does not.
Read-only throughout: a guardian sees their own child's standing, never anyone else's.
3

See published results

Results reach the family at the moment the school publishes them, in the same form the school approved.

4

See attendance as it happens

A ward's register history and this week's totals, so an absence is a conversation on the day rather than a surprise at the end of term.

5

Follow what has been happening

An ordered feed of what the school recorded about their child recently — marks published, a register mark, a notice, a receipt.

6

See the end-of-session decision

The promotion decision with the evidence behind it, visible to the family at the same time as the school office rather than by letter weeks later.

How it connects to the rest of the platform

  • Every add-on is built on this record

    Library borrowers, clinic patients, hostel residents, store customers and fee payers are all the same pupils and staff held here. That is why enabling a module takes minutes rather than a migration: there is no membership list to import and no roster to keep in step.

  • The three portals are not modules

    Staff, student and parent portals ship with every active subscription and cannot be purchased, disabled or gated. An add-on adds sections inside them; it never determines whether a pupil or a guardian has a portal at all.

  • Billing bills the people on this recordrequires School Fees & Finance

    Fee categories apply to grades defined here, invoices are raised against pupils held here, and reminders are dispatched to the guardians linked here. The finance ledger reports alongside attendance and academics in the same reporting suite.

  • HR extends the staff record rather than replacing itrequires Human Resource Management

    Leave, performance, training and disciplinary all attach to the employee and department records the base platform already holds — the same row the staff portal and the role grant read from.

  • Messaging addresses the platform's own audiencesrequires Communication & Messaging

    Announcements target classes, grades and roles that already exist, and reach guardians through the links held here. Basic notifications are base; campaigns and moderated messaging are the add-on.

  • Branding re-skins these portalsrequires Branding & Customization

    The staff, student and parent portals every school gets are what the Branding module puts the school's own colours and mark on — the module changes their appearance, not their availability.

Common questions

Is the base platform an extra cost on top of the modules?+

It is the other way round. The base platform is what the subscription's base fee buys, and it is included with every active subscription. Add-on modules are priced on top of it. There is no configuration in which a school has modules but not the core.

Do we pay per portal, or per parent and student account?+

No. The staff, student and parent portals are integral constituents of the platform, not seats. Every employee, every pupil and every linked guardian gets their portal as a consequence of being on the record.

Can we turn parts of the core off?+

The core cannot be disabled, but what any individual can reach is entirely yours to decide. Roles are composed from the platform's action catalogue, so a school that does not want, say, behaviour points visible to teachers simply does not grant those actions.

What happens to a pupil's record when they leave?+

They move to a withdrawn or alumni status rather than being deleted. Their results, attendance history, promotion record and any outstanding balances stay attached and attributable, which is what makes a transcript or a reference possible years later.

Can our class structure be described accurately, or do we have to fit a template?+

Stages, grades and class arms are configured per school. You select the stages you actually run, define the grades inside them, and create as many class arms per grade as you have — each with its own room, capacity and form teacher.

Does attendance distinguish between missing school and missing a lesson?+

Yes. Registration attendance is taken by the form teacher and per-lesson attendance by the subject teacher. Both feed the same pupil record and the same at-risk calculation, so a pupil who registers and then misses period four is visible as exactly that.

How do marks become a report card?+

Subject teachers enter marks in the gradebook against the school's assessment scheme. The broadsheet is a view over those marks for the whole class, and the form teacher adds the psychomotor report. Both are submitted together, the office approves, and approval publishes to the pupil and their guardians. Nothing is re-typed at any point in that chain.

Is the audit trail a real audit trail?+

It records the actor, resource, action and outcome of consequential events, including denied attempts with the reason for the refusal. Rows carry a correlation id, a monotonic sequence number and a hash of the previous row for tamper-evidence, and the log can be filtered and exported as CSV.

Can we import our existing pupil and staff data?+

Yes — pupil records support bulk import, so a school arriving with an existing roll does not type it in. Guardians and their links come in with them.

Run your whole school on one connected platform

Start with the base package, switch on the modules you need, and give every parent, student and staff member a single place to log in.

Get startedView products & pricing