Skip to content
Concept · Tier 3Entry

Attendance and Parent Communication

A school marking attendance on paper registers that are filed and never analysed, and communicating with parents by phone calls from the office and notes sent home with children.

The problem

A child's fourth consecutive absence is noticed at the end of the month, if at all. Information the school already holds reaches parents only when a parent calls to ask for it.

In scope

  • Class and student lists
  • Daily and per-subject register
  • Absence reasons
  • Consecutive-absence alerting
  • Attendance summaries
  • Broadcast and targeted messaging
  • Delivery status
  • Message log

Out of scope

  • Fees
  • Results
  • Admissions
  • Timetable generation
  • Also out: a parent app. Parents will not install one, and the messaging channel they already use reaches them today.

What this would cover

Grouped by module — open the ones you want to read.

Class structure
  • Levels, streams, class lists, class teacher assignment per term
Register
  • Daily marking from a phone in under a minute, per-subject marking for senior classes where students move between teachers
Absence detail
  • Absent, late, excused, with a reason where one is given, distinguished because "absent" and "late" have different meanings to a parent
Alerting
  • Consecutive-absence threshold configurable by the school, notifying class teacher and office
Summaries
  • Per student across a term, per class for management, included automatically on any report card the school produces
Messaging
  • Broadcast to school, level, class or individual family; templated messages for common cases
Delivery tracking
  • Sent, delivered, failed, so a school knows whether a message about a fee or an absence actually landed
Message log
  • Every message held against the family record, so the office can see what a parent has already been told before calling them

Data model

  • Class → Enrolment → Student
  • Guardian → Family
  • AttendanceRecord
  • AbsenceAlert
  • Message → Recipient → DeliveryStatus
  • MessageTemplate

Invariants

  • A register for a past date can be amended, but the amendment records who changed it and when — back-dated attendance is the field most likely to be quietly edited.
  • Delivery status is stored per recipient, not per message.

Offline behavior

Required. Register marking queues locally and syncs, because teachers mark in classrooms with poor signal in short windows between lessons. A teacher must never be blocked from marking.

Hard trade-offs

The difficult decisions, stated plainly — not trimmed for length.

Messaging costs money per message, and schools routinely underestimate it.

A school of 400 students sending two messages a term to every family is not expensive; a school sending absence alerts daily during a flu week is. The system must show projected and actual messaging spend, and the school must decide its own alert thresholds with that cost visible. A vendor who does not raise this before go-live is setting up an argument in month two.

End state

What would be true about their day once this is running.

  • A register takes a minute and the data is usable.
  • A fourth consecutive absence reaches the office on the fourth day.
  • Parents receive what the school already knows without calling for it, and the office can see what was sent to whom.

This is a deliberate first step toward School Operations & Parent Portal Platform — its data model is designed as a genuine subset, so growing into it later doesn't mean starting over.

Let's map how your operation actually runs.

One session. We look at what's breaking, and what we'd build around it — whether or not you hire us afterward.

Start the operations review