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 and everything the school says (announcements and in-app messaging, free and unlimited), included with every subscription.

Get started Talk to usFrom ₦10.00 per student/day · deducted daily from your prepaid credit

What this module bills

Active students₦10.00 per student/day · billed daily
Staff accounts₦15.00 per staff/day · billed daily
Object storage₦10.00 per GB/month · first 5 free each month
Document renders₦0.05 per render · first 500 free each month
Emails sent₦2.00 per email · first 500 free each month
SMS segments₦10.00 per SMS segment · pay-as-you-go

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.

Your mark, not ours

Branding is included, not an upsell. The sidebar shows your logo and school name, your palette applies across every portal by default, your careers site is served your colours, and there is no “Powered by” line on your public pages.

Every message on the record

Announcements, direct messages and in-app notifications are part of the base, free and unlimited — not a messaging add-on. A notice is aimed at an audience the platform can resolve (a grade, a class, a group, a role), a direct message is a thread between real school accounts, and both are auditable from a per-channel delivery log.

Every flow, every role

How Base Platform actually works

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

On this page

School office
Subject teachers
Form teachers
Every other employee
Students
Parents & guardians

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.

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.

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.

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.

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.

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 — and the three pages beside it are about the same subject record at a different grain, which is why they are route tabs rather than four sub-modules in the sidebar.

Subjects with a code, a title and the department they belong to.

Whether a subject is compulsory is decided PER YEAR GROUP, not once on the subject: the same subject is core in JSS 2 and optional in SSS 1, and a single flag could only ever be wrong for one of them.

Elective groups on their own tab — the “pick two of these four” rules a year group puts on the optional half of its curriculum.

Selection windows on another: the period families actually choose in, opened and closed by the school.

And the selections themselves on a fourth — what each pupil ended up offering, with the school's approval queue over the submissions, because a submission is not a selection until somebody signs it off.

Teachers are assigned to a subject from the subject's own page, as well as from the teacher's — the roster reads the same either way round.

Rooms are configured alongside, for timetabling and for the class arms that sit in them.

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 — with guardians and their links on their own sheet beside it.

A pupil created here immediately has a student portal, a library membership, a clinic record and a billing identity — with no second registration anywhere.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Own the screen before the login

The sign-in page is the surface a school has least control over in most systems, and the one its people see most often. Here it is yours: your photographs beside the form, your mark and name above it.

Up to six images, in an order you set, crossfading beside the sign-in form.

An optional title and description over each — a new science block, a prize day, a founding date.

Pick the whole set at once, write the copy against the pictures in front of you, and publish the lot in one save.

A browser that has signed in to your school remembers it, so returning members meet your brand rather than ours — including after they sign out.

Motion respects the visitor’s reduced-motion setting; the copy and dots are keyboard reachable.

Keep more than one look

Themes holds up to three presets. Colours split into the two groups schools actually reason about: brand colours, which come from a style guide, and interface colours, which most schools never touch.

Add, rename and remove presets, and mark one active for the school.

Every change previews live across the dashboard around you — the real thing, not a swatch.

A contrast panel names any text/background pair below the WCAG AA ratio of 4.5:1.

Make it look like your school

Schools spend years building a name, a crest and a set of colours, and most school software hands their families a portal that belongs to a software company. One Settings page replaces all of that with yours — and it is base, not an upsell.

Up to three saved theme presets. One is active for the school; members can pick any of the others from their own theme menu, or opt out to plain light and dark.

Every change previews live across the dashboard around you — you are looking at the real thing, not a swatch.

One school logo used by the sidebar mark, sign-in screens, ID cards, document headers and your public pages, with an optional override per preset.

“Extract colours from logo” reads the dominant colours out of your crest and proposes a primary, secondary and accent with contrast-safe text, instead of you hunting hex codes in an old style guide.

A WCAG AA guardrail measures every text-on-background pair as you edit and names the exact pair that falls below 4.5:1.

A status section that states, item by item, what your brand has actually replaced of ours — and what is not included, so nobody expects a custom domain.

Start at the communication hub

Communication is part of the base now, and it splits into two jobs that should not be confused: getting a message out, and governing how messaging works. The hub holds both.

Delivery surfaces — messages for direct threads, announcements for broadcasts.

Operations surfaces — the notification log, the moderation queue, and policy settings.

Each tile is access-controlled: a member of staff sees only the surfaces their role grants, so the hub is different for the bursar and the head.

Work the announcement outbox

Every notice the school has written lives here — published, scheduled and draft together — so the state of school-wide communication is one list rather than a memory.

Filter by status, channel, priority and audience scope to find what went where.

Drafts sit beside sent notices, so a half-written notice is never lost in someone’s email.

A scheduled notice shows its send time and has not gone anywhere yet — it is a queued job, not a reminder to a person.

Open any notice for its delivery status: who it reached on in-app, email and SMS, and the provider error on anyone it did not.

Retry a failed send for one recipient or for every failure at once — a wrong phone number is fixed and re-sent without re-notifying the other 800 parents.

Read receipts alongside delivery, so "never arrived" and "never opened" stay two different problems.

Duplicate a past notice to reuse it — the same end-of-term reminder does not get retyped each term.

Compose to an audience the platform can resolve

The recipients are chosen as school concepts — not a mailing list somebody keeps up to date by hand — and the platform expands them at send time from the live roll.

Audience scopes: the whole school, all staff, all students, all parents — or a specific set of grades, classes, named student groups or access profiles.

Channels per notice — in-app, email and SMS — chosen for that message rather than fixed for the school.

Priority (low, normal, high) carries through to how the notice is presented in every recipient portal.

Publish now, or set a send time and let the scheduler dispatch it; an expiry date retires the notice without anyone remembering to.

Save as a draft and come back — the form keeps an offline draft, so a lost connection does not lose the wording.

Hold the school’s own conversations

The same messaging workspace every portal uses, seen from the office: threads with guardians, teachers and students, each attached to the school rather than to whoever happens to be handling it.

Start a thread with any parent, teacher or student the school’s policy permits.

Attachments, replies to a specific message, and forwarding into other threads.

Close a conversation when a matter is settled — it stays readable, but nobody can add to it.

Flag a message for review from inside the thread, which puts it in the moderation queue.

Unread counts and live updates, so a thread that needs an answer is visible without opening it.

Review what has been escalated

Open messaging between adults and children is only defensible if someone is watching. Anyone in a thread can escalate a message, and it arrives here with the reported content attached.

Every flag with its reason, who raised it, and the message itself — not just a pointer to a conversation.

Filter by status and by the role of the reporter, so a pattern involving one group is visible.

Resolve or dismiss with the outcome recorded against the flag.

Administrators are notified in-app the moment a flag is raised, so review is not dependent on someone checking the queue.

Set the rules everyone operates under

A grid of who may open a conversation with whom, and a second for who may close one. Each cell is one relationship, so the school can allow a subject teacher to write to the pupils they teach without also opening a line to those pupils’ parents.

One switch per relationship, not per role — "subject teachers" is three separate decisions: pupils, those pupils’ parents, and the office.

A dash marks a relationship that does not exist at all. Parents and pupils never write to each other, so there is nothing there to switch on.

Closing works the same way: a form teacher can be allowed to end a thread with a parent without being able to end one with the office.

Changes take effect immediately across every portal — a group the school has closed simply is not offered in the "new conversation" picker.

The default is deliberately not everything-on. Non-teaching staff can reach the office, because it is their only audience; almost everything else starts closed.

Ready to run your school on this?

Every screen in “School office” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.

Get started Book a demo

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.

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.

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.

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.

See this on your own school’s data.

Every screen in “Subject teachers” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.

Get started Book a demo

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.

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.

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.

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.

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.

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.

Set this up for your team.

Every screen in “Form teachers” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.

Get started Book a demo

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.

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.

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.

The same workspace, in the school’s colours

Staff get no branding screen and nothing to configure. What they get is that the workspace they were already using stops looking like a vendor product.

The sidebar header carries the school logo and name, with the school switcher on the chevron beside it.

Any of the school’s saved presets can be selected per person; the school’s active preset is the default.

A plain light/dark choice remains available as an accessibility opt-out.

Read what the school sent them

A member of staff sees the notices aimed at them — staff-wide, their role, their classes — in their own portal, with the urgent ones marked.

Filter by channel and priority to find a specific notice.

Read state is tracked, which is what feeds the read receipts the office sees.

An unread count in the navigation, so a rota change is not missed.

Hold their own threads

The same messaging workspace, scoped to this employee: their conversations with the office and with the guardians of the children they teach, on the school’s record.

Threads with guardians and administrators, with attachments and replies.

Whether a teacher can open a thread — and with whom — is the school’s policy setting, not a per-teacher choice.

Anything inappropriate can be escalated to the school from inside the thread.

A teacher’s personal number never enters the conversation, which is the point.

Ready to run your school on this?

Every screen in “Every other employee” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.

Get started Book a demo

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.

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.

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.

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.

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.

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.

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.

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.

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.

Their school, not a product

An ordinary student screen — here a timetable — themed the moment the school activates a preset. No per-student setting, no first-run prompt. Students are the largest audience for a school’s brand and the least likely to configure anything, so it reaches them by default.

The school’s active preset applies on first load, so pupils see the school they belong to.

A pupil who finds a palette hard to read can switch to another preset or to plain light/dark.

The school’s notices, in writing

Announcements aimed at students land in their own portal, newest first, with priority marked. An exam timetable notice is now something a student can re-read at home.

Search and filter across everything they have been sent.

Priority is visible, so an urgent notice does not look like a club reminder.

Notices aimed at the whole school arrive here too — students are not a separate mailing list.

Ask a teacher, on the record

Students get their own messaging workspace, limited to the teachers the school’s policy allows them to reach. Every exchange is held by the school and can be escalated.

Threads with subject and form teachers, with attachments for work-related questions.

Whether a student may start a thread at all is the school’s setting — off, and they can only reply to threads a teacher opens.

The school can see and moderate these conversations, which is what makes them safe to allow.

See this on your own school’s data.

Every screen in “Students” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.

Get started Book a demo

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.

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.

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.

See published results

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

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.

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.

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.

A school-branded parent portal

Parents form an impression of a school from its digital surfaces long before they sign in to one. They see the school’s colours and mark rather than ours — on a child’s results here, and on the public pages that lead to the portal.

The parent portal wears the school’s active preset by default.

The public careers site is served the school’s palette and logo, and carries no platform attribution.

School notices where the rest of the record is

A guardian reads the same notice they were emailed or texted, kept beside their ward’s results, attendance and invoices rather than lost in a personal inbox.

Everything the school has sent them, searchable and filterable by priority.

Notices aimed at parents and at the whole school both arrive here.

Read state feeds the office’s receipts, so the school knows the message landed.

A direct line the school can see

Threads with the form teacher and with the office, held on school accounts. The school sets whether guardians may open a conversation, and every message can be escalated by either side.

Conversations are attached to the ward, so context travels with the thread.

Attachments — a receipt, a medical note — without resorting to a personal phone.

The guardian can flag a message for the school’s attention, exactly as staff can.

When a matter is settled the school can close the thread; it stays readable to both sides.

Set this up for your team.

Every screen in “Parents & guardians” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.

Get started Book a demo

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 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.
Every module’s notifications leave through the base
Announcements target classes, grades and roles that already exist, and reach guardians through the links held here. The dispatch pipeline, templates and delivery log are shared platform machinery: a fee reminder, a clinic visit notice, a hostel leave-pass approval and a results release are all requests in the same queue, which is why one place shows a school everything it has sent.
Access control treats branding as its own job
Branding has its own permission namespace and a Brand Manager role, so the person who owns the school's look does not need broad settings access — and a settings administrator does not silently inherit the brand.
The careers site wears your brandrequires Human Resource Management
Where recruitment is in use, the public job board is one of the branded surfaces — often the first page a candidate ever sees of the school, and served your palette and logo rather than ours.
Document templates share the brand kit
Generated documents draw on the same logo and brand assets through the document-template engine, so a report card and a sign-in screen agree on what the school looks like.

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, and a good deal more than that. Twenty-nine spreadsheet imports now cover the school itself (departments, year groups, rooms, subjects, class arms, terms, the calendar and the timetable), the people in it (staff, pupils, guardians), and the modules a school has bought — fee categories, store categories and products, inventory suppliers, items and assets, library titles, copies and acquisitions, behaviour categories and rewards, leave types and policies, hostels, rooms and bed spaces, subject selections and alumni outcomes. Every one runs through the same upload, dry run and apply: refusals land on the rows that caused them in an editable grid, so a bad row is corrected rather than the whole file rejected.

In what order do the imports have to be loaded?+

In the order the school is built, and the sheets say so: no sheet ever creates the thing another sheet references. Class arms name a year group that has to exist; a timetable names a subject, a room and a class; a store product names its category; a library acquisition names a title. Load the catalogues first, then the people, then what the people do.

Is messaging included, or is Communications still an add-on?+

Included. Communication & Messaging was a paid module until August 2026; announcements, meetings and internal in-app messaging now ship with every active subscription and are free and unlimited — there is no per-message charge for in-app threads. Only the delivery channels that cost real money are metered: transactional email (the first 500 each month are free) and SMS (billed per segment), because every send costs the platform a provider fee.

Can we stop parents from messaging teachers directly?+

Yes. The communication settings screen turns initiation on or off per role — parents, form teachers, subject teachers, students and administrators — so a school can allow parent-to-form-teacher threads while keeping subject teachers out of the loop, or route everything through the office.

Do parents and teachers need each other’s phone numbers?+

No, and that is much of the point. Conversations run between school accounts inside the portal, so a teacher never gives out a personal number and the school retains a complete record of what was said.

Is branding really included, or is it an add-on?+

Included. Theme presets, the school logo and tagline, the brand kit and the white-label public pages are all part of the base fee. Branding & Customization was a paid module until August 2026; it is now a page in Settings that every school has.

How many themes can we keep, and do we need brand colours to hand?+

Up to three saved presets, one of them active for the school. You do not need hex codes: upload your logo and the brand kit reads its dominant colours, proposing a primary, secondary and accent plus contrast-safe text, which you can then adjust.

Can a member of staff or a pupil turn the school theme off?+

Yes. Choosing plain light or dark in the theme menu opts that person out — an accessibility escape hatch that does not affect anyone else.

Can we serve the portal from our own domain?+

Not today. A custom domain needs DNS and certificate infrastructure and is treated as a separate premium tier. Branding covers the colours, the mark and the public pages, and the Settings page says plainly what it does not cover rather than implying otherwise.

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 started View products & pricing