Designing Behavioural Reminder Automation for School Payments
Designing Behavioural Reminder Automation for School Payments
Designing Behavioural Reminder Automation for School Payments
How we reduced manual follow-ups and improved on-time fee payments through structured lifecycle automation.
Scope:
Scope:
Product Feature
Product Feature
/
For:
For:
Zenda
Zenda
/
Duration:
Duration:
2 months
2 months
Year
Year
2025
2025

/ TL;DR
/ TL;DR
If you’re short on time
If you’re short on time
This project is part of Zenda’s broader Revenue Automation System, designed to help schools manage invoicing, payment communication, and collections at scale.
It builds on the invoicing workflow explored in the previous case study:
→ Designing a Trust-First Invoicing System at Scale
This project is part of Zenda’s broader Revenue Automation System, designed to help schools manage invoicing, payment communication, and collections at scale.
It builds on the invoicing workflow explored in the previous case study:
→ Designing a Trust-First Invoicing System at Scale
Schools were spending significant operational time manually reminding parents to pay invoices. The process was repetitive, inconsistent, and heavily dependent on admins tracking payment statuses themselves.
Schools were spending significant operational time manually reminding parents to pay invoices. The process was repetitive, inconsistent, and heavily dependent on admins tracking payment statuses themselves.
I designed a behavioural reminder automation system that combined lifecycle messaging, escalation logic, and controlled flexibility—helping schools improve payment consistency while reducing operational dependency on manual follow-ups.
I designed a behavioural reminder automation system that combined lifecycle messaging, escalation logic, and controlled flexibility—helping schools improve payment consistency while reducing operational dependency on manual follow-ups.
/ Context
/ Context
When reminders become operational overhead
When reminders become operational overhead
Manual follow-ups don’t scale - At Zenda, invoicing was only one part of the fee collection process. The bigger challenge started after invoices were generated.
Manual follow-ups don’t scale - At Zenda, invoicing was only one part of the fee collection process. The bigger challenge started after invoices were generated.
School admins still had to:
Monitor unpaid invoices
Manually send reminders
Follow up across different communication channels
Escalate overdue payments
Handle frustrated parent conversations
School admins still had to:
Monitor unpaid invoices
Manually send reminders
Follow up across different communication channels
Escalate overdue payments
Handle frustrated parent conversations
For smaller schools, this was manageable. For larger institutions handling thousands of students, it quickly became operationally exhausting.
For smaller schools, this was manageable. For larger institutions handling thousands of students, it quickly became operationally exhausting.
The issue wasn’t a lack of communication—it was the lack of a reliable system around it.
The issue wasn’t a lack of communication—it was the lack of a reliable system around it.
/ The Problem
/ The Problem
The issue wasn’t awareness — it was postponement
The issue wasn’t awareness — it was postponement
Most parents already knew the due date. But, one of the most important behavioural insights we observed was surprisingly simple: Parents usually weren’t unaware of payments—they postponed them.
Most parents already knew the due date. But, one of the most important behavioural insights we observed was surprisingly simple: Parents usually weren’t unaware of payments—they postponed them.
A common pattern looked like this:
A parent sees a tuition invoice two months early
Mentally notes that there’s still time
Prioritises other immediate expenses
Assumes they’ll “handle it later”
Suddenly receives an urgent reminder just before the deadline
A common pattern looked like this:
A parent sees a tuition invoice two months early
Mentally notes that there’s still time
Prioritises other immediate expenses
Assumes they’ll “handle it later”
Suddenly receives an urgent reminder just before the deadline
That final reminder often created unnecessary stress:
Rushed payments
Support calls
Frustration toward schools
Last-minute operational pressure
That final reminder often created unnecessary stress:
Rushed payments
Support calls
Frustration toward schools
Last-minute operational pressure
The problem wasn’t communication volume. It was communication timing and progression.
The problem wasn’t communication volume. It was communication timing and progression.
We realised reminders needed to behave less like alerts and more like a structured payment lifecycle.
We realised reminders needed to behave less like alerts and more like a structured payment lifecycle.
/ Key Constraints
/ Key Constraints
Why Automation Was Hard
Why Automation Was Hard
Reminder systems become messy faster than expected.
At first glance, reminder automation sounds simple: “Just schedule notifications.”
Reminder systems become messy faster than expected.
At first glance, reminder automation sounds simple: “Just schedule notifications.”
In reality, the system had to account for:
reminder fatigue from excessive communication
different parent behaviours across schools
overlapping schedules and duplicate reminders
varying escalation timelines
multiple communication channels
payment sensitivity and emotional tone
operational oversight and accountability
In reality, the system had to account for:
reminder fatigue from excessive communication
different parent behaviours across schools
overlapping schedules and duplicate reminders
varying escalation timelines
multiple communication channels
payment sensitivity and emotional tone
operational oversight and accountability
A reminder sent too early could be ignored. A reminder sent too late could create panic. Too many reminders could reduce trust entirely.
Schools also wanted flexibility—but unrestricted flexibility would eventually create chaos.
A reminder sent too early could be ignored. A reminder sent too late could create panic. Too many reminders could reduce trust entirely.
Schools also wanted flexibility—but unrestricted flexibility would eventually create chaos.
The challenge was designing automation that still felt controlled, understandable, and human.
The challenge was designing automation that still felt controlled, understandable, and human.
/ Goals
/ Goals
The System We Designed
The System We Designed
Instead of designing standalone reminders, we designed a system around Reminder Groups.
Instead of designing standalone reminders, we designed a system around Reminder Groups.
Admins could:
Create reminder groups for batches or individual students
Define timelines relative to invoice due dates
Choose communication channels (WhatsApp, Email, SMS, InMail)
Configure recurring or custom reminder schedules
Select and edit templates
Track delivery, activity, and reminder status
Admins could:
Create reminder groups for batches or individual students
Define timelines relative to invoice due dates
Choose communication channels (WhatsApp, Email, SMS, InMail)
Configure recurring or custom reminder schedules
Select and edit templates
Track delivery, activity, and reminder status
Step 1 — Create reminder group
Step 1 — Create reminder group
Admins defined:
Group title name
Invoice type
Reminder schedule
Recurring or custom timelines
Admins defined:
Group title name
Invoice type
Reminder schedule
Recurring or custom timelines




Step 2 — Add students
Step 2 — Add students
Students could be filtered and grouped based on:
Class
Unpaid fee items
Payment status
Batch/group criteria
Students could be filtered and grouped based on:
Class
Unpaid fee items
Payment status
Batch/group criteria


Step 3 — Configure lifecycle communication
Step 3 — Configure lifecycle communication
Admins selected:
Templates
Dates
Channels
Escalation stages
Admins selected:
Templates
Dates
Channels
Escalation stages
The system then automated the reminder lifecycle while keeping admins in control.
The system then automated the reminder lifecycle while keeping admins in control.



/ Design Implementation
/ Design Implementation
Controlled Flexibility
Controlled Flexibility
Enough customization to adapt. Enough structure to stay reliable.
Enough customization to adapt. Enough structure to stay reliable.
Schools needed flexibility, but unrestricted automation would quickly become difficult to manage.
So we intentionally designed boundaries into the system.
Schools needed flexibility, but unrestricted automation would quickly become difficult to manage.
So we intentionally designed boundaries into the system.
What admins could do:
Edit templates before sending
Customise reminder dates
Select channels
Pause or modify reminder groups
Remove students from groups
What admins could do:
Edit templates before sending
Customise reminder dates
Select channels
Pause or modify reminder groups
Remove students from groups
What we intentionally restricted:
Unlimited reminder logic
Uncontrolled automation branches
Infinite template variations
AI-generated reminders
Fully autonomous communication without oversight
What we intentionally restricted:
Unlimited reminder logic
Uncontrolled automation branches
Infinite template variations
AI-generated reminders
Fully autonomous communication without oversight
For example: If a user modified one occurrence inside a recurring schedule, the system automatically converted it into a Custom Schedule instead of pretending it was still recurring.
This prevented invisible logic conflicts and kept automation understandable.
For example: If a user modified one occurrence inside a recurring schedule, the system automatically converted it into a Custom Schedule instead of pretending it was still recurring.
This prevented invisible logic conflicts and kept automation understandable.


/ Design Implementation
/ Design Implementation
Designing Behavioural Escalation
Designing Behavioural Escalation
Not every reminder should sound the same. One of the most important design decisions was structuring reminders as a behavioural progression rather than a static notification sequence.
Not every reminder should sound the same. One of the most important design decisions was structuring reminders as a behavioural progression rather than a static notification sequence.
The lifecycle evolved gradually:
1. Early Notification
A calm informational reminder sent soon after invoice generation.
2. Upcoming Reminder
A softer nudge shared weeks before the due date.
3. Urgent Reminder
A more direct reminder as deadlines approached.
4. Due Date Notification
Final payment reminder on the exact due date.
5. Post-Due Notification
Sent only if payment remained incomplete.
6. Warning / Suspension Communication
Used for prolonged non-payment scenarios.
This progression mattered because communication tone directly affected user behaviour.
The lifecycle evolved gradually:
1. Early Notification
A calm informational reminder sent soon after invoice generation.
2. Upcoming Reminder
A softer nudge shared weeks before the due date.
3. Urgent Reminder
A more direct reminder as deadlines approached.
4. Due Date Notification
Final payment reminder on the exact due date.
5. Post-Due Notification
Sent only if payment remained incomplete.
6. Warning / Suspension Communication
Used for prolonged non-payment scenarios.
This progression mattered because communication tone directly affected user behaviour.
For example:
WhatsApp reminders performed significantly better than email for many middle-aged parents
Early reminders reduced confrontation later
Aggressive reminders too early created unnecessary friction
Repeated identical messages caused users to mentally ignore notifications entirely
For example:
WhatsApp reminders performed significantly better than email for many middle-aged parents
Early reminders reduced confrontation later
Aggressive reminders too early created unnecessary friction
Repeated identical messages caused users to mentally ignore notifications entirely
The system wasn’t just scheduling reminders—it was pacing financial communication responsibly.
The system wasn’t just scheduling reminders—it was pacing financial communication responsibly.


/ Design Implementation
/ Design Implementation
Visibility & Operational Trust
Visibility & Operational Trust
Automation still needed accountability. One important principle guided the system:
“Automation should reduce operational effort—not remove visibility.”
Automation still needed accountability. One important principle guided the system:
“Automation should reduce operational effort—not remove visibility.”
The challenge was enabling this without compromising clarity or control.
The challenge was enabling this without compromising clarity or control.
Admins could always:
View reminder histories
Track delivery status
Monitor activity timelines
Pause/Edit/Delete reminder groups
Identify failed communication attempts
Admins could always:
View reminder histories
Track delivery status
Monitor activity timelines
Pause/Edit/Delete reminder groups
Identify failed communication attempts
If messages failed:
Admins could manually sync and resend communication
Delivery failures remained visible
Payment links expired predictably after invoice deadlines
If messages failed:
Admins could manually sync and resend communication
Delivery failures remained visible
Payment links expired predictably after invoice deadlines
This visibility layer was critical because schools needed confidence that communication had actually happened.
This visibility layer was critical because schools needed confidence that communication had actually happened.




/ Design Implementation - Design Decisions
/ Design Implementation - Design Decisions
Key Design Decisions
Key Design Decisions
The most important decisions were behavioural and operational:
The most important decisions were behavioural and operational:
Structured escalation instead of static reminders
Structured escalation instead of static reminders
Reminder timing and tone evolved intentionally across the payment lifecycle.
Reminder timing and tone evolved intentionally across the payment lifecycle.
Controlled customization
Controlled customization
Schools could adapt communication without compromising system consistency.
Schools could adapt communication without compromising system consistency.
Multi-channel flexibility with operational visibility
Multi-channel flexibility with operational visibility
Communication stayed centralised while preserving traceability.
Communication stayed centralised while preserving traceability.
Human oversight over full automation
Human oversight over full automation
Admins remained accountable instead of blindly trusting automation.
Admins remained accountable instead of blindly trusting automation.
Making automation understandable
Making automation understandable
Complex scheduling logic was simplified into manageable flows and timelines.
Complex scheduling logic was simplified into manageable flows and timelines.
/ Outcomes & Impacts
/ Outcomes & Impacts
The system reduced both operational load
and payment friction.
The system reduced both operational load
and payment friction.
After launch:
Manual reminder workflows reduced significantly
Support tickets related to payment follow-ups dropped
Schools reported earlier fee payments
Dependency on ops teams reduced
Reminder communication became more consistent and traceable
After launch:
Manual reminder workflows reduced significantly
Support tickets related to payment follow-ups dropped
Schools reported earlier fee payments
Dependency on ops teams reduced
Reminder communication became more consistent and traceable
More importantly, schools trusted the system enough to rely on it daily.
More importantly, schools trusted the system enough to rely on it daily.
/ What I Learned
/ What I Learned
My Key Takeaways
My Key Takeaways
Behavioural systems require restraint:
Automation without visibility creates distrust
Reminder timing matters as much as reminder frequency
Good lifecycle design reduces operational dependency quietly
Communication design directly influences user behaviour
Behavioural systems require restraint:
Automation without visibility creates distrust
Reminder timing matters as much as reminder frequency
Good lifecycle design reduces operational dependency quietly
Communication design directly influences user behaviour
Why this matters
Why this matters
This project reinforced my belief that the best automation systems don’t try to replace human decision-making—they reduce friction around it.
This project reinforced my belief that the best automation systems don’t try to replace human decision-making—they reduce friction around it.
Madan Murali
I’m always open to conversations, whether it’s about design challenges, collaborations, or just sharing ideas.
See my journey on paper
My Resume →