Notification channels — reality & cost
When an officer scans a learner’s badge at the gate, MySentinel records the check in / check out immediately and then notifies that learner’s verified guardians. The record at the school is the source of truth; the notification is a best-effort courtesy on top of it. That distinction matters commercially, and the product never blurs it: the officer’s screen says “Recorded at the school. Guardians are notified on their verified contacts.” — it never claims a guardian read the message.
This document is the un-spun version of what reaches a parent today, what is still being provisioned, and what each channel costs you inside the ~R10/learner/month price.
The fallback ladder: push → email → WhatsApp → SMS
Each guardian’s message walks an ordered ladder, highest-trust-and-lowest-cost first:
| Rung | Channel | What it is |
|---|---|---|
| 1 | App push (web push) | Free, instant, lands on a guardian’s installed phone app |
| 2 | One branded per-school HTML layout, your colours + logo | |
| 3 | The channel SA parents actually use — but provider-gated (see below) | |
| 4 | SMS | Last resort: short, paid-per-message, always-delivers |
How the ladder behaves depends on the message type, and this is a deliberate, per-school policy — not an accident:
- Routine check in / check out uses the school’s chosen mode. The owner default is broadcast (reach every resolved channel the guardian has enabled); a school can switch to priority, the classic fallback ladder that stops at the first confirmed send. Either way the per-guardian channel toggles and quiet-hours still narrow it.
- Emergency, safety mode, and late-pickup always broadcast to every eligible channel and bypass the per-child routine preferences — a safety message is not something a parent can accidentally mute. (The one exception, by design: a guardian who explicitly turns SMS off keeps it off even in an emergency, because SMS spends real money on their behalf.)
Guardians control their own mix from the tokenised parent portal — channel preferences and quiet hours, no login required.
Channel honesty: the app never shows a fake “sent”
This is the part a buyer’s technical advisor will probe, so here is exactly how it works in the code today.
Every attempt is recorded with a truthful status — there is no path that writes “sent” for a message that was not actually handed to a provider:
| Status | Meaning |
|---|---|
| sent / duplicate | The provider accepted it (duplicate = idempotent re-send of the same message) |
| skipped | We deliberately did not send on this channel (e.g. WhatsApp template not approved) — recorded, not hidden |
| retryable_failure | Transient provider problem; the queue will retry |
| permanent_failure | Will not succeed; surfaced for admin action, never silently dropped |
A guardian is only counted as “notified” when at least one channel genuinely confirmed. If nothing confirmed, the system reports delivered: false rather than inflating a success number. The deliveries dashboard uses “Deliveries” vocabulary, not “messages read”, and in the admin and operator UI every channel wears a Preview or Live badge so nobody mistakes a not-yet-connected channel for a working one.
Privacy is built into the same plumbing: delivery logs store a hashed recipient address, never a parent’s raw phone or email. (The live walkthrough confirmed this — a check-in fanned out through notification-service and the email log fired with a hashed recipient.)
Per-channel status — what actually delivers today
App push (web push) — verified arriving on a real device (UAT)
The web-push implementation is real (VAPID + aes128gcm, no Firebase, proven against the RFC-8291 test vector in code) and was confirmed arriving on a real device on UAT (2026-06-27) with VAPID secrets provisioned. Web push is Chrome/Android-friendly; iOS requires the parent to “Install MySentinel” (add to home screen) first. Any new environment still re-provisions its own VAPID secrets + a device re-check before you promise delivery there. Status: live and verified on device (UAT); each new environment re-provisions VAPID, which is an activation step, not new development.
Email — live with a verified domain
Email is the dependable backbone today: one shared branded layout (email-render) used by every service, themed to each school. It is live once the sending domain is verified (SPF/DKIM/DMARC). Locally it runs in stub mode ([email-stub] logs); on a connected environment it sends for real. Status: live; this is the channel a cold demo can always truly deliver.
WhatsApp — live delivery tested on UAT, activates per school once connected
Live WhatsApp delivery was tested and confirmed on UAT (2026-06-27). For a given school it switches on once two things are true: a configured provider, and Meta-approved message templates for the (school, template, language) combination. Until a school has both, the message is demoted to email — recorded as a truthful skipped WhatsApp attempt, never a failed-retry-loop and never a fake send. Where a school brings its own Meta credentials, those are used directly. Status: proven to deliver (UAT); activates per school once the provider + approved templates are connected.
SMS — live delivery tested on UAT, activates per school once connected
SMS is the always-arrives fallback, rendered as a tight ≤160-character GSM-7 body in en/af/zu. Live SMS delivery was tested and confirmed on UAT (2026-06-27); it is operator-provisioned per school. Because every SMS costs real money, it sits last on the ladder and carries a smart guard: in broadcast mode the SMS rung is suppressed once a higher tier already confirmed for that guardian and event — you are never double-charged when the family was already reached on push, WhatsApp or email — unless SMS is the only channel left. Status: proven to deliver (UAT); activates per school once the provider is connected.
What it costs — BYO vs pass-through inside ~R10/learner
Pricing is ~R10 per learner per month (negotiable), billed manually, out-of-app — there is no in-app billing engine. The platform fee covers the software, app push, and branded email. The two paid channels carry their own per-message provider cost, and you choose how that is handled:
| Channel | Per-message cost | How it’s handled |
|---|---|---|
| App push | None (no provider fee) | Included in the platform fee |
| Effectively included | Sends on a verified domain | |
| Meta conversation fee | BYO your own Meta credentials (you pay Meta directly) or marked-up pass-through, metered per confirmed delivery | |
| SMS | Per-segment carrier fee | BYO provider or marked-up pass-through, metered per confirmed delivery |
Only genuinely confirmed WhatsApp/SMS deliveries on a pass-through (platform-metered) arrangement are metered for billing — BYO and failed sends are never metered. Admins see channel-usage metering in Settings, and the operator console exposes per-school delivery success and provider readiness for reconciliation.
The honest bottom line
- Proven to deliver (verified on UAT, 2026-06-27): app push arriving on a real device, branded email (on a verified domain), and live WhatsApp + SMS. All four were confirmed delivering on UAT.
- Activates per school: WhatsApp (Meta templates + provider) and SMS (provider) deliver, but each school connects its own provider before they switch on — until then they honestly demote to email, a real demoting code path, never fake capability.
- No overclaiming by design: the app never paints a fake “sent”, every channel is badged Preview vs Live, recipient addresses are hashed, and unconfirmed sends are reported as not-delivered.
- Production is currently a hollow shell (no secrets, usage-blocked) — channel activation and any live demo happen on UAT, never prod.
The selling point is precisely this restraint: across many campuses, a system that refuses to over-promise parents is the one that keeps the school’s trust.