Parent communication
Schools can't reach parents reliably.
SchoolVoice
An AZCY platform.
School management software with one promise at its core: when you send a message to parents, you know it arrived.
A school sends the same message four different ways and still can't say which parents received it. SchoolVoice was built to close that gap.
The shape of it
What moves, and what happens to it.
School records
Pick who the message is for — a class, an arm, or a group you define. You choose people the way a school thinks, not by building a list of phone numbers.
Send and confirm
Your message goes out by SMS, email, and voice call. The system then checks, parent by parent, whether each one actually arrived.
The parent
The message arrives on the channel that works for that household. You see who received it, parent by parent — not a total you have to take on trust.
Capabilities
The parts that carry the argument.
Communication Control Panel
Pick your audience — a class, an arm, a custom group — choose how to send, and watch each parent's delivery confirm on screen.
Delivery and read receipts
For every parent, on every channel. 'Did they get it?' has a real answer, not an average.
Voice for the households SMS misses
A recorded or computer-voiced call, in the household's language, for parents a text message won't reach.
Per-channel cost visibility
A voice call costs more than a text. You see the cost before you send, not in an invoice at month end.
One record behind everything
Attendance, results, and fees all sit on the same student record your messages use. Update a phone number once and it is current everywhere.
How it fits
Into what you already run.
Nothing here replaces a system that works. These are the questions that decide whether a platform can be deployed at all, so they are answered before the specification.
Integrations
- SMS gateways, per-country, with per-route failover
- SMTP or transactional email providers
- Voice/telephony providers for call delivery
- Payment providers for fee collection
- CSV import for existing student records
Deployment
- Managed cloud, multi-tenant
- Single-tenant for groups running multiple schools
- In-country data residency where required
Security and custody
- Role-based access control, per school
- Contact details are visible only to roles that need them
- Full audit trail on every send: who sent what, to whom, when
- Parent data is never used to train anything
Specification
Design facts and stated targets. Nothing we have not measured.
Technical specification
Channels
- Delivery channels
- SMS · Email · Voice
- Receipt model
- Per-recipient, per-channel
- Gateway model
- Multi-provider, per-route failover
- Send model
- Immediate · Scheduled
Data
- Audience selection
- Class · Arm · Custom segment
- Import
- CSV · API
- Export
- CSV · PDF report cards
- Record of truth
- One student record, shared
Deployment
- Model
- Multi-tenant · Single-tenant
- Residency
- In-country available
- Access
- Web · Parent mobile
- Authentication
- Role-based, per school
The hard problem
A delivery receipt is not proof that a parent was reached.
In plain terms: the hard part is not sending a message — it is proving, honestly, that a parent received it. The naive version of this system sends a message to a gateway, gets a 200 back, and marks it delivered. That number is meaningless. The gateway has accepted the message; it has not delivered it. The real receipt arrives later, asynchronously, on a callback — sometimes seconds later, sometimes hours, sometimes never, and sometimes twice for the same message.
So the engineering problem is reconciliation, not sending. Every message carries an identity that survives the round trip through a third party we do not control. When a receipt comes back, it has to find the parent it belongs to, even though the gateway's idea of a recipient is a phone number and a school's idea of a recipient is a person who may have three numbers and two children in the school. Receipts arrive out of order and are not guaranteed to be unique, so the reconciliation has to be idempotent — the same receipt landing twice must not produce two outcomes.
Then there is the harder half: a message that is never receipted. Silence from a gateway is ambiguous — it can mean delivered-but-unreported, or dropped. A system that shows silence as success is lying to a school, and a system that shows it as failure will have the school resending everything. We model it as a third state and surface it as one, because the honest answer to 'did the parent get it' is sometimes 'we don't know', and a head teacher can act on that. They cannot act on a false green tick.
The channel design follows from the same reality. SMS is the cheapest and the least certain. Voice costs more and reaches households where text does not — which in practice means the parents a school most often fails to reach are the ones a text-only system silently drops. Putting per-channel cost in front of the person choosing, at the moment they choose, is what makes that a decision rather than an accident.
The practices behind it
Where it runs
Questions
The ones we actually get asked.
Can we keep our existing student records?
Yes. Records import from a spreadsheet or straight from your current system. We run the import against a copy first, so you can see exactly what will land before anything changes.
What happens when a parent has no phone?
The message goes to whichever contact does exist, and the record shows plainly that the main contact can't be reached. The system never quietly drops a family — an unreachable parent is something you need to know, not a row to hide.
Do we have to use every module?
No. Most schools start with messaging and student records, then add fees, results, and the parent portal as they go. Everything shares one student record, so adding a module later never means re-entering anything.
Where does our data live?
In a managed cloud service by default, and it can be kept in-country where that's required. School groups that need a fully separate system of their own can have one.
Can it send in a language other than English?
Yes, for text and for voice calls. This matters most for voice, which is usually what reaches the households a text-only system misses.
We build systems like this for other organizations.
SchoolVoice exists because we met the same operational failure enough times to engineer it properly. Yours is probably a different failure. That is the conversation we want, and you will have it with an engineer.