Getting Your People In
The first fortnight: what happens between paying and having a working school, how a term’s worth of students and staff get onto the register without anyone re-typing them, and what a new teacher, pupil and parent each see the first time they open the link you sent.
The bit between “we’ve signed up” and “everyone’s using it”
Software is easy to buy and hard to start. The honest questions a school asks are: how long until it is usable, who types in eleven hundred children, and what happens when we send the invitations — because the last time we tried this, forty parents rang the office. This is the answer to all three, screen by screen. Nothing inside a school is built until the payment settles, and then it is built in front of you rather than in a support ticket. The register is filled from the spreadsheets the school already keeps, in a grid it can correct before anything is written. And every invitation lands on a page that has been designed for somebody who has never seen this system, does not have an account, and is holding a phone.
On this page
Nothing is built until the payment settles
A school record is written the moment the profile is finished, but nothing inside it exists yet — no grades, no classes, no schedule, no staff record for the owner. That is deliberate: a buyer who walks away at checkout leaves no half-built tenant behind. The build-out runs after the credit top-up settles, and the buyer watches it happen.
Choose what you are running, and see what it costs
The base platform is always included; add-on modules are switched on one by one. Enter the school’s expected size and the estimate is computed line by line from the same per-day rates the platform actually bills — not a quote, the real tariff.
Watch it being built
The payment redirect lands here, and this screen is the wait made visible: five ordered steps, each with its own status, streamed live as a background job works through them. It is the difference between “we are setting up your account” and knowing exactly what is happening.
A school that exists
The end of onboarding and the beginning of everything else. The owner is handed into a dashboard whose academic year, class structure and module set are already there — because a job built them two minutes ago, not because somebody configured them by hand.
Ready to run your school on this?
Every screen in “Nothing is built until the payment settles” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.
Eleven hundred children, not eleven hundred forms
Every school already has this data — in a spreadsheet, in the last system, in a book. The import is built around that fact. It does not ask for a perfectly formatted file; it asks where the rows are, and then puts them in a grid the school can fix before anything is written.
The register the whole platform reads
One roll of pupils, with admission number, class, status and whether they can sign in yet. There is no second list: the library, the clinic, the bursary and the parent portal all read this one, which is why getting it right once is the whole job.
Bring the spreadsheet you already have
The import asks a better first question than “upload a file”: where are your rows? Three answers, because there are three real situations — you have a file, you have the information but no file, or you started this yesterday and want to carry on.
See this on your own school’s data.
Every screen in “Eleven hundred children, not eleven hundred forms” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.
The same again, for the people who work there
Staff go in the same way, through the same flow. That is worth saying plainly: the import is one mechanism with eight sheets behind it — students, staff, subjects, grades, class arms, rooms, the timetable — so a school learns it once and the sixth import is as fast as the second.
The staff directory
Every employee with their department, job title, status and portal access. Departments and the directory are base platform — a school that never buys the HR module still has all of this, because you cannot run a school without knowing who works there.
One import, eight sheets
The same chooser, the same grid, the same checks — pointed at the staff sheet. Everything a school learned importing pupils applies here unchanged, which is the point of building it once.
Set this up for your team.
Every screen in “The same again, for the people who work there” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.
Who each child belongs to
A pupil record is not a family. The link between a guardian and their wards is what makes an invoice reach somebody, a consent request find the right household, and one parent with three children at the school sign in once instead of three times.
The guardian directory
Guardians as records in their own right, with the pupils each is linked to. The figures above the table are the ones the office actually needs in week one: how many guardians there are, how many hold a portal account, and how many are still unreachable.
Ready to run your school on this?
Every screen in “Who each child belongs to” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.
The invitation, from the other side
Everything so far has been the office’s view. The next three phases are the only screens in the whole product that a person meets before they have an account — and the only ones where the school has no chance to explain anything first. Each is reached by a link in an email, and the token in that link is the entire credential.
A new employee finishes their own record
The school entered a name, an email and a job title. The employee fills in the rest — the phone number, the address, the next of kin, the qualifications and the documents — because they are the ones who know it, and because a record they completed themselves is one they will keep up to date.
See this on your own school’s data.
Every screen in “The invitation, from the other side” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.
A child’s first sign-in
Students are the hardest people to onboard and the ones most systems handle worst — they often have no email address of their own, and the credential the school issues is guessable by anyone in their class. Both facts are designed around rather than ignored.
The pupil sets their own password
A student signs in with the registration number the school issued, and the password they are given is their date of birth — which every classmate knows. So the first sign-in does one thing and refuses to do anything else until it is done: replace it.
Set this up for your team.
Every screen in “A child’s first sign-in” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.
The link that already knows their children
The last invitation, and the one that decides whether a school’s parent portal is used or ignored. It has to work first time, on a phone, for somebody who has never heard of this system and is not going to ring the office to ask what their username is.
One link, and their children are on it
The page names the guardian and lists the wards they are linked to — which is both the reassurance that the link is genuinely theirs and the explanation of why they were written to at all. Loading the page is itself the email confirmation: the token could only have come from the address the school sent it to.
Ready to run your school on this?
Every screen in “The link that already knows their children” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.
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.