Chasing fees without harassing families

Why reminder systems turn into complaints

Fee recovery is the one workflow where software talks directly to parents without a staff member in the loop, at scale, about money. The failure modes are therefore social rather than technical, and they are always the same four: a message to somebody who already paid, three messages in one afternoon from three different features, a message at 10:40 at night, and a message to a family the school never onboarded.

None of these are edge cases. Each one is what happens when a reminder engine trusts its own snapshot of who owes what.

Five rules that hold under load

1. Check payment at send time, on every path. Not when the campaign was built, not when the list was exported — at the moment the message goes out, on the manual button as well as the automated ladder. A reminder for a settled invoice is the one message you can never take back.
2. One pressure window per invoice, shared by every engine. A school may run a manual chase, a scheduled campaign, a pre-due nudge and an escalation ladder against the same invoice. If each keeps its own cooldown, the family experiences the sum. The window belongs to the invoice, not to the feature.
3. Send in daylight, and defer rather than drop. Automated messages about money should not arrive at 06:00 or 23:00. A send outside the window waits for the window; it does not vanish, and it does not go anyway.
4. Never start a ladder against imported history. The first thing a school does on new software is import last year's ledger. If that import can trigger outreach, the school's first act on the platform is to message every family about a balance it has not yet verified.
5. Escalate tone, not volume. Four messages in a week is harassment. A polite reminder, then a firmer one, then a call task for a human is escalation. The last rung of a good ladder is a person, not a louder message.

Count what happened, not what you attempted

Two numbers on a recovery dashboard are routinely wrong in the school's favour, and both are worth fixing before anyone reports them upward.

• Notices sent should count messages a provider actually accepted. A send that was skipped because the family opted out, or held because the school was in a quiet period, is not a notice sent — counting it makes an inactive campaign look busy.
• Amount recovered should be what was collected after the chase began, not the balance the invoice happened to carry. If a family owed ₹40,000, was enrolled in a ladder, and paid ₹12,000, the campaign recovered ₹12,000. Claiming ₹40,000 because the invoice later settled is how a school ends up believing an engine works better than it does.

The channel rules are not yours to bend

In India, a business-initiated WhatsApp message outside an open conversation window must use a template the platform has approved under its own business-messaging policy, and SMS runs under the TRAI DLT framework with registered sender IDs and content templates. Both rules belong to the channel and its regulator, not to us — confirm the current requirements with your messaging provider before you plan around them, because a system that lets you type free text into them will simply fail to deliver.

Practically, that means the school registers its own sender identity and templates, keeps consent and opt-outs honoured across every engine, and treats the provider's returned status as the truth about delivery rather than the fact that a button was pressed.

How this works in Vidyapeeth360

Every reminder path — the single row button, the drafted message, the bulk campaign and the automated ladder — runs through one function that re-checks the invoice's payment state before anything is dispatched. A settled invoice is never chased, and that guard is not something an engine can opt out of.

A shared per-invoice pressure window floors every automated engine, so the manual funnel, the escalation stage, the campaign and the pre-due nudge cannot stack on one family. Automated sends run inside a configured daytime window and defer outside it; a deliberate human action stays a human action. A workspace still in quiet mode — the default for a school that has not gone live — never starts a ladder at all, and imported invoices are excluded from recovery until the school says the ledger is real.

The escalation itself is staged: a propensity score orders who to work first, tone and channel escalate through the rungs, and the final rung is a call task for a person rather than another message. The ladder halts the moment the invoice is paid. Where an assistant is enabled it nudges the score from anonymised features and drafts a template with placeholders — the family's record is not sent to a model, and the message is rendered locally.

Reporting is deliberately unflattering: sends count only provider-accepted deliveries, each run records the per-channel outcome including skips, and the recovered figure is the amount actually collected after enrolment rather than the whole balance. That makes fee reminders, pending-fee tracking and the automated ladder reconcile with the ledger instead of with each other.

Escalation is automatic. Not harming a family who already paid is not optional — which is why it lives in the send path rather than in a policy document.