31 October 2026
School pickup authorisation that holds up at the gate

Every school day ends with the same question, asked quickly and under pressure: is this person allowed to take this child? School pickup authorisation is the written answer to that question. In most schools I have seen in Belize, the answer lives in a teacher's memory, a note pinned near the office, or a message buried in a WhatsApp group from February. That works until the day it does not.
I build and run Scholar, a school management system (software that holds student records, attendance, grades and the day-to-day administration of a school) that is live with a Belizean school. One of the smaller features in it is the authorised pickup list. It is small in code and large in consequence, so it is worth describing properly.
Why a WhatsApp group is not a pickup record
A group chat is a conversation, not a record. It has no structure, so you cannot search it reliably. It has no permissions, so anyone in the group sees everything. It has no history you can trust, because messages get deleted and phones get replaced.
More to the point, the person standing at the gate at 2:45 on a Thursday is often not the person who read the message. It might be a substitute teacher who started on Monday. It might be the security guard. Neither of them knows the family, and neither of them should be expected to.
When there is no record, the decision falls on whoever is nearest. That is unfair to the staff member and unsafe for the child.
What does a pickup authorisation record actually contain?
In Scholar, each student has a list of people authorised to collect them. For each person on that list, the school holds:
- The person's full name.
- Their relationship to the child, for example mother, grandmother, aunt, neighbour, driver.
- A phone number, so the office can call before handing a child over if something looks unusual.
- An optional photo, which is the single most useful field when the staff member on duty has never met the family.
That is the whole shape of it. It is not complicated data. What makes it useful is that it is in one place, attached to the student, visible to the right people, and kept current.
Who can see it and who can change it
Parents can view their child's list through their own login. If something needs to change, they request the change rather than editing it directly. A member of staff reviews and applies it.
That sounds like friction, and it is, deliberately. A pickup list is a safeguarding record, which means the school needs to know that a change was reviewed by a person with authority, not typed in by whoever had the password.
Every change is written to an audit log, a record of who changed what and when. If a question is ever asked about who added a name and on what date, the answer is in the system rather than in somebody's recollection.
How do staff check school pickup authorisation at dismissal?
On a phone. That is the only practical answer, because dismissal happens at the gate and not at a desk.
A staff member on duty opens the student record on their phone and sees the authorised list, including the photos. It takes a few seconds. If the person at the gate is not on the list, there is no argument to have, because the answer is not a personal judgement. It is what the record says, and the next step is to call the parent.
This is where a written record does its quiet work. It moves the decision away from a young teacher who does not want to cause offence and onto a policy the school has already agreed. You can read more about how the rest of the system fits together on the Scholar page.
What happens when custody arrangements change?
This is the case that matters most, and it is the one informal systems handle worst.
Family arrangements change. Separations happen, court orders are issued, a grandparent takes over the school run, a relationship ends badly. The school is often told once, verbally, by one parent, at a busy moment.
With a written record, the removal of a name is an event with a date and a staff member attached to it. The school can show what it was told, when, and what it did about it. That protects the family, because the instruction was actually carried out, and it protects the school, because there is evidence that it was.
I am not a lawyer and Scholar is not legal advice. But I have built enough administrative systems to know that the difference between a defensible decision and a difficult conversation is usually just a timestamped record.
Checklist: informal arrangements against a written record
Use this to work out where your school currently sits.
| Question | Notes and memory | Written record in a system | | --- | --- | --- | | Can a substitute teacher check the list? | No, they have to ask someone | Yes, on their phone | | Is there a photo of the authorised adult? | Rarely | Optional, per person | | Can a parent see what the school holds? | Only by asking | Yes, through their login | | Do you know when a name was removed? | No | Yes, with the staff member who did it | | Does it survive a phone being lost? | No | Yes, it is on the server | | Can two staff see the same version? | Not reliably | Yes |
If most of your answers are in the left column, you do not necessarily need a full school management system tomorrow. But you do need to decide, as a school, who is allowed to collect each child, and write it down somewhere every member of staff can reach.
What does it take to set this up?
The feature itself is modest. The work is in the data entry and in agreeing the policy.
A school with a few hundred students will spend most of a week collecting authorised names from parents, usually through a form at the start of term, and then keying them in or importing them. Photos trickle in over a longer period, and that is fine, because a list without photos is still far better than no list.
The policy conversation is shorter but more important. Who may approve a change? What does a staff member do when the person at the gate is not on the list? What happens for a one-off collection by someone unlisted? Scholar can record the decisions, but the school has to make them.
Scholar is multi-tenant, meaning one system serves several schools with each one seeing only its own data, and it runs on Linux servers I operate myself. Work is delivered with source code, documentation and in-app help, and the school keeps ownership of its data.
Where to start
- Write down your current rule for releasing a child, in one or two sentences, as it actually works today rather than as you would like it to work.
- Ask three members of staff who are not class teachers how they would check whether an adult is authorised. Their answers will tell you how exposed you are.
- Draft a short parent form: authorised names, relationships, phone numbers, and consent to hold a photo.
- Decide who in the office is allowed to approve changes to the list, and who reviews the log.
- Only then decide whether you need software, and if so, whether it should be part of a wider school system or a standalone list.
If you want to talk through how this would work at your school, you are welcome to get in touch.