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:

  1. Structured escalation instead of static reminders

  1. 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.

  1. Controlled customization

  1. Controlled customization

Schools could adapt communication without compromising system consistency.

Schools could adapt communication without compromising system consistency.

  1. Multi-channel flexibility with operational visibility

  1. Multi-channel flexibility with operational visibility

Communication stayed centralised while preserving traceability.

Communication stayed centralised while preserving traceability.

  1. Human oversight over full automation

  1. Human oversight over full automation

Admins remained accountable instead of blindly trusting automation.

Admins remained accountable instead of blindly trusting automation.

  1. Making automation understandable

  1. 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 →