Christchurch, NZ ·

← All work

McSTS

School bus software where changing a driver is one edit, not forty.

At Hail

mcsts.co.nz

Before: 40 student records for one route. 23 have been retyped with the new driver, two of those with typos, and 17 still show the old driver. "23 of 40 saved."After: one driver record saved. All 40 students follow it, except one marked with a cover driver. "1 save."
One route with 40 students. Drawn for this page, because the real system sits behind a login, and every name is made up. Drag across to compare.

When a driver changed routes, someone in the office opened every student on that route and retyped one name.

Mid Canterbury School Transport Service moves about 1,900 students a day across 36 school routes with 27 drivers, in rural Canterbury. It ran on a dated .NET application the office found very hard to use, and the client came back with a list of things they wanted to be able to do.

Driver changes were the worst of it. On a 40-student route, that was 40 saves and 40 chances for a typo. Records drifted out of date, and parents sometimes got emails naming a driver who no longer drove their child’s route.

So the driver stopped being something you type on a student.

I made each student take their driver from their route. One edit on the driver record, and every student on that route follows in seconds.

A map of the system on navy. Drivers cover routes and routes carry students, drawn in yellow. Students attend schools. A parent’s form writes new students. Email templates read the student’s route and its driver. Bus companies sits alongside.
The six kinds of record, and the links this page talks about. Drawn for this page in McSTS’s own colours and type.

Six kinds of record

Students, drivers, routes, schools, bus companies and email templates. Most of what the system does comes from the links between them. A School Years grouping runs across the students, so filtering and reporting stay consistent from one year to the next.

It runs on WordPress, but all the logic is in one plugin I wrote for this operator. WordPress only delivers the pages and handles sign-in.

A driver record is changed to cover Example Road and saved. The 39 students on the route change to the new driver in a wave, one student with a cover driver stays as it was, and the email a parent would get now names the new driver.
What one save does. Drawn for this page. The names, the phone numbers and the email wording are made up.

Where it doesn’t follow

Sick days happen. The office can put a cover driver on a single student, and that student keeps that driver when the route’s driver changes.

Emails that name the right person

The office writes each template with placeholders like {driver} and {driver_phone}. They’re filled when the email goes out, from the current driver on that student’s route. The office can change the wording itself, without a developer.

The office never opens WordPress.

Everything happens on pages in the same look as the public site: a list and a detail page for each kind of record, with search and filters for route, school, year, driver, status and approval. There’s no dashboard and there are no plugin menus.

Parents start the record

A parent fills in the Student Registration form, and the submission becomes a real student record, already on the chosen route and school, ready for the office to review and finish.

The first step of the public Student Details form, empty, with a drawn student record showing a route, a school, a driver and "Office to review".
The real public form, empty, and the record it starts. The record is drawn for this page, with made-up names.

Starting clean

One pass on deploy day brought every existing record into line, so nobody had to sweep through them by hand. The same tool stays in the system, and any administrator can run it if things ever drift.

Hours of admin a week became one edit on the driver record.

More work