Designing parent notifications that do not get muted

Muting is the failure mode

The worst outcome for a school transport app is not that it fails to send a notification. It is that it sent so many unimportant ones that the parent disabled notifications three weeks ago, and now the important one does not arrive either.

This is worth stating plainly because notification volume is usually treated as a product decision and it is actually a safety decision.

What a parent genuinely needs

Reduced to essentials, a parent needs to know four things:

1. My child boarded. Confirmation, once, at the moment it happens.
2. The vehicle is approaching my stop. With enough lead time to walk there.
3. My child got off. Confirmation, once.
4. Something has gone wrong. Delay beyond a threshold that matters, route change, or an incident.

That is four notifications on a normal day, two of them in the morning and two in the afternoon. Anything beyond that has to justify itself against the risk of the parent muting the channel.

What gets sent that should not

• Trip started / trip ended. The parent does not care that the vehicle left the depot. They care when it reaches them.
• Every geofence crossing. A route with eighteen stops does not need eighteen notifications sent to every family.
• Speed violations. These matter enormously to the school and the contractor. Sending them to parents produces anxiety and phone calls without producing any action a parent can take.
• Sub-threshold delays. A bus two minutes behind schedule is not late. Sending that trains the parent to ignore delay notices, which means the genuinely late one gets ignored too.
• Marketing and announcements. Not in the same channel as safety alerts. Ever. This is the single fastest way to get a safety channel muted.

Let the parent set the lead time

Proximity alerts are the notification parents value most, and the correct lead time varies by household. A parent whose stop is thirty seconds from their front door wants two minutes' warning. A parent walking a five-year-old four hundred metres wants eight.

Give them the choice per stop. A parent who has configured their own alert has an investment in it working, and they are considerably less likely to mute a channel they tuned themselves.

Confirm, do not predict

There is a meaningful difference between "your child's bus has arrived at your stop" and "your child boarded at 07:14".

The first is inferred from vehicle position. It is often right and occasionally wrong, and every time it is wrong the parent trusts it slightly less.

The second is generated by the credential read. It is a statement about what happened. Parents calibrate on this quickly — messages derived from a tap event get believed, and messages derived from a position estimate get treated as a guess.

Prefer confirmations. Where a prediction is genuinely useful, such as proximity, label it as an estimate rather than dressing it up as a fact.

Separate the channels by severity

Three tiers, delivered differently:

• Routine confirmations (boarded, alighted) — in-app notification, standard priority. Quiet, informational, no sound at night.
• Actionable notices (approaching, significant delay, route change) — push notification with sound, because the parent needs to do something.
• Incidents (SOS, missed boarding, emergency) — push with high priority, plus SMS as a fallback, because push delivery is not guaranteed and this is the message that must arrive.

Most platforms send everything through one channel at one priority. That is what forces parents to choose between all of it and none of it.

The test to apply

Before adding a notification, ask: what will the parent do differently when they receive this?

If the answer is "nothing", it belongs in the app's activity log, not in a push notification. The log is where a parent looks when they want detail. The notification is for when the system needs their attention.