Cutting school admin without adding another system nobody logs into

Every school already has more systems than staff can keep up with. The one the authority requires. A learning platform. Google or Microsoft. A payments provider. A messaging tool. A shared drive with four folders called Admin.

So the first rule for any new software in a school: it has to remove a place, not add one. If a new tool does not kill a spreadsheet, a paper form or a group chat, do not buy it, however good the demonstration is.

Find out where the hours actually go

Two weeks, one sheet in the office, four columns:

• Answering a question the school has already sent out
• Chasing a form, a payment or a permission slip
• Typing in something that was already typed in somewhere else
• Building a report or a list by hand

A tick and a rough number of minutes each time. Ask teaching staff separately, because their admin is a different problem -- registers, reports, trip forms, parents evening bookings -- and it happens in the evening where nobody sees it.

At the end you will have an ordered list. Build against that list, not against a brochure.

The four that usually pay back

Roughly in the order they tend to come out on top of the tally in a school office.

Admissions that follow the applicant

Enquiry, visit, application, offer, acceptance, enrolment, all on one board, with automatic follow-ups so nobody sits unanswered for a fortnight, and every family visible at a glance.

This is normally first for three reasons. It is the process where people fall through the gaps, those people are your intake, and admissions usually sits outside the system your authority mandates, so it can be built without touching anything regulated. This is standard custom software work rather than anything exotic.

Attendance taken in the room

Registers on a phone or tablet, submitted in seconds, with absence messages going to parents the same morning instead of surfacing a week later.

One test decides whether this works: how long it takes a teacher to submit a register with everyone present. If that is more than a few seconds, staff will go back to paper and you will have paid for a system that generates more work than it saves.

A parent portal that answers the question

Timetables, attendance, reports, fees, term dates, permission slips, messages. Most calls to a school office are about something the school has already communicated; a portal gives it a permanent address.

One warning, because this is where portals fail. A portal only reduces calls if parents can get into it without a password reset. Every login barrier costs you a portion of your parents permanently. Use a link sent to their phone or email rather than another password to forget, keep it working properly on a phone, and accept that some parents will always ring. The target is fewer calls, not none.

Fees and reminders

Invoices raised, payment plans tracked, reminders sent automatically before anyone has to make the awkward call.

The detail that matters more than the software: reminders must stop the instant a payment lands. Chasing a parent who paid on Friday costs more goodwill than the reminders saved.

Do not commission all four at once. Do the one at the top of your tally, get it genuinely used for a term, then take the next.

Working with the system you are required to use

Where an authority mandates a student information system, build alongside it and connect to it. Replacing it is usually not your decision and rarely your problem.

Decide, field by field, which system is the master. Normally the mandated one holds the pupil record and everything else reads from it. Run the connection one way first, into a copy, and compare before anything writes back. That discipline is the whole of a good integration and skipping it is how two systems end up quietly disagreeing about a child's address.

Children in your data, in plain language

This section is not legal advice, and the rules differ by country. But these are the questions a school should be able to answer about any system it uses, and any supplier who is vague about them is telling you something.

Collect less. Every field you ask for is a field you must keep accurate, protect, and eventually delete. The cheapest privacy measure available is not collecting the information in the first place. Challenge every field on the form.

Decide who can see what, and enforce it in the software. A class teacher does not need the fee record. The finance office does not need pastoral notes. Roles that are enforced by the system rather than by a convention people are trusted to follow.

Log who looked. For sensitive records, keep an access log showing who opened what and when. This is what turns a written policy into something you can actually check when a question arises.

Know where it is stored. Which country the data sits in, and which companies process it along the way. Get the answer in writing before you sign, not after.

Delete on a schedule. How long do you keep an unsuccessful applicant's file? An ex-pupil's records? Photographs? Decide the periods, write them down, and make the software do the deleting. Manual deletion never happens, because it is nobody's job on any given Tuesday.

Record consent per child and per purpose, and make it easy to withdraw. If a system cannot record that one child must not appear in photographs and then actually stop that happening, it is not fit for a school.

Be careful with AI specifically. Do not paste pupil information into a general chatbot. Where AI is used, it should be on business terms that keep your data out of model training, with the same access rules as every other part of the system. Nothing about a specific child should go to a parent without a member of staff having read it. And nothing to do with safeguarding should be automated at all -- that is a human process with a human record, and software's only job there is to be secure and to stay out of the way.

What we would tell you not to build

Not a replacement for the mandated system. Large, slow, risky, and usually solving a problem you are not allowed to solve.

Not an app, unless you need notifications. A mobile app is worth it when you need to reach parents with something that cannot wait for an email and when people will open it regularly. If it just repeats the portal, you have created a second place for information to go out of date.

Not anything for a process you change every September. Wait until it has settled for a year.

Not automated decisions about children. Attendance flags that prompt a human to look are fine. Anything that decides is not.

The measure of a good year is that the number of places information lives went down. If a project ends with staff logging into one more thing and nothing switched off, it failed, whatever else it did well.