Hiring
How a school fills a post end to end — write the vacancy, publish it to your own careers page, take applications from people with no account, interview and score them, make an offer they answer from home, and turn the acceptance into an employee with a role, a contract and a timetable.
A stranger on Monday, a colleague with a class on Friday
Recruitment is the one school process that starts with someone the school has no record of, and ends with that person holding keys to it. Most systems handle only the second half: you hire somebody in a spreadsheet, then type them into the platform. EaseAcademia carries the whole line — the vacancy, the school’s own careers page, the applications, the scorecards, the offer letter and the reply — and the moment an offer is accepted, one action turns a candidate into an employee with a staff number, a contract, a role and the modules that role grants. Nothing about that person is re-typed, and nothing exists before the school says so: an applicant is not on your payroll, in your directory, or on your bill.
On this page
Write the job, not just the advert
A vacancy is more than a description. It carries the headcount it is allowed to fill, the department the hire will belong to, the closing date, the stages applicants will move through, and — the part most schools do on paper — the questions candidates are actually asked. Setting those once is what lets everything downstream be a decision rather than a data-entry job.
Every post the school is recruiting for
The recruitment board lists each vacancy with its department, its headcount, its status and how many applications it has drawn. Drafts sit beside published roles, so a post can be written in September and opened in November without anyone seeing it in between.
Compose the vacancy
The composer is where the post is actually defined: title and department, how many people it may hire, a rich description and requirements, the tags candidates filter on, a closing date, and the application form the role will use. Publishing is a separate, explicit action — writing a vacancy never puts it on the internet by accident.
Ask what you actually screen on
Application forms are reusable and versioned. Every form starts from the same base — name, email, phone, CV, cover letter — and the school adds the questions it genuinely sorts candidates by: subject specialism and TRCN number for a teaching post, references and availability for a support role.
Ready to run your school on this?
Every screen in “Write the job, not just the advert” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.
Applied for from outside, with no account
Every school on EaseAcademia has a careers page at its own short link, wearing its own branding and carrying no platform attribution. A candidate finds it from a job board, a WhatsApp forward or the school’s website, reads the post and applies — with nothing to install, no account to create, and no password to remember for a school they may never work at.
The school’s own careers page
Every published vacancy, on one page at the school’s short link. Each card carries the role, the department, the summary and the date it opened — enough for a candidate to decide whether to read further, and nothing that leaks the school’s internal pipeline.
The post, in full
The role in the school’s own words — the description and requirements as HR wrote them, the department, and the closing date. This page is what the school is actually judged on by the people it is trying to attract, so it is the school’s text, not a template.
Apply, in one form
The application form is the one the vacancy named — the base fields every candidate gives, plus this school’s own questions. The CV uploads straight from a phone, required fields are enforced before the form will submit, and the answers arrive attached to the application rather than in an inbox.
See this on your own school’s data.
Every screen in “Applied for from outside, with no account” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.
Sort a stack of strangers
Applications arrive into one pipeline per vacancy. The board is the shape of the school’s own process — the default stages, or the ones this post defined — and moving a candidate is a drag, an audited event and a filter, all at once. Nobody keeps a parallel spreadsheet, because the spreadsheet is what the board replaced.
The whole post on one board
Every applicant for the role, in the stage they have reached — applied, screening, interview, offer, accepted. Dragging a card moves the candidate and records who moved them; dragging a column reorders the school’s process for this post.
The same people, as a list
The board is the right shape for moving candidates and the wrong one for comparing them. The list view carries the same applications as rows — stage, score, current role, when they applied — so a panel can sort by score and work down it.
One candidate, whole
The application in full: who they are, what they answered, the CV they uploaded, every stage they have passed through and who moved them, the interviews held and how they were scored, and the private notes the panel keeps. This is the record a hiring decision is defensible from.
Set this up for your team.
Every screen in “Sort a stack of strangers” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.
Interview, score, and put it in writing
The two decisions that actually cost a school something are taken in dialogs over the application, so the record stays in front of whoever is taking them. An interview is scheduled with a panel and comes back with a scorecard; an offer is composed with terms and an email, and leaves as a link the candidate can answer.
Schedule the interview and score it
An interview carries a time, a place or a meeting link, and the panel who will sit on it. Afterwards it carries the scorecard — criteria, scores and notes — and an outcome. Both halves live on the application, so a score is never a memory of a conversation.
Compose the offer
The offer composer is three steps: the terms, the email that carries them, and a review before anything is sent. The email is pre-written from the school’s own name, the candidate’s name and the role, with the decision link dropped in — so the common case is read-and-send rather than write-from-blank.
Ready to run your school on this?
Every screen in “Interview, score, and put it in writing” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.
The reply, from a kitchen table
An offer is only real when the other person can answer it. The link in the email opens a page carrying the school’s branding, the role, the terms and two buttons. The token in that link is the credential — there is no sign-in, because the school is asking a question of someone who does not work there yet.
Accept or decline
The offer page shows the school, the role and the terms as they were sent, and asks for a decision. Accepting or declining is confirmed rather than one-click, records the moment it happened, and is the event the school’s side is waiting on — nobody has to ring to find out.
See this on your own school’s data.
Every screen in “The reply, from a kitchen table” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.
One action, and they exist
Accepted is not employed — deliberately, and for the same reason an accepted applicant is not yet a student. Creating an employee adds a person to the school’s directory and to what the school pays for, so it is a human decision taken on its own screen, with everything the platform already knows about them carried across.
Turn the acceptance into an employee
The hire dialog opens prefilled from the application — name, email, phone — and asks only for what a candidate could not have told you: their department, their job title, their start date and their employment terms. One submit mints a staff number and a directory record.
On the register, with everyone else
The new employee appears in People Operations beside every other member of staff, with their department, their status and — the column that matters on day one — whether they can actually sign in yet. Being on the register and being able to open the app are two different things.
The paperwork, attached to the person
Contracts and compliance documents live on the employee rather than in a folder — with expiry dates the platform watches. A teaching qualification that lapses in March is a thing the school is told about in February.
Set this up for your team.
Every screen in “One action, and they exist” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.
Decide what they can open
A staff record is an identity, not a permission. What a new colleague can actually see is decided in two more places — the role they are granted, and the classes or subjects they are given — and both are base platform, so this half of hiring works whether or not the school ever bought the HR module.
Grant the role
Roles are assembled from granular, per-module permissions and granted to a person — permanently, or for a fixed window that expires on its own. The modules a role grants are exactly the sections that will appear in that employee’s sidebar, which is why this screen decides more about their first day than any other.
Give them something to teach
A subject-teacher role opens the teaching workspace; it does not say which subjects. That is decided from the subject catalogue, where each subject carries the teachers who teach it and the lead teacher who owns it — so a new physics teacher is assigned from the subject’s side, in front of the whole curriculum.
Ready to run your school on this?
Every screen in “Decide what they can open” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.
What it all looks like from their side
Every decision the last seven phases recorded shows up in one place: the sidebar of the person they were about. A new employee signs in to a workspace already carrying their timetable, their classes, their own employment record and the self-service every member of staff gets — assembled from their role, not configured for them by hand.
Their first sign-in
The staff home is the day ahead — the lessons on it, what is waiting, and the notices they have been sent. It is assembled entirely from the role granted two phases ago; nobody built this page for this person.
Their own employment record
The contract, the department, the start date and the documents the school holds — readable by the person they are about, without asking HR for a copy. It is the same record the HR office worked with in phase six, seen from the other end.
The class that was waiting for them
The teaching workspace opens on the subject they were assigned, carrying its classes, its roster, its gradebook and its attendance. The hire is finished at the point this screen has something in it — and it does, because of a decision recorded on a subject page, not because anyone set this workspace up.
See this on your own school’s data.
Every screen in “What it all looks like from their side” 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.