Perspectives
A payment reminder is not a threat
The reply matters more than the reminder.
By Ehsan Gazar, 6 October 2026
Somebody on your team spends Monday morning sending the same message to two hundred people. "Your payment is overdue."
By Tuesday the replies are in, and they are the real work. "I paid on Friday." "Can I pay half now?" "This is not my number."
Most automation stops at the first message. It sends the reminder and leaves the replies to pile up in an inbox nobody owns.
That is backwards. The reminder is the easy part. Everything that matters happens after it.
Sending, within limits you set
A reminder sent at eleven at night is a complaint waiting to happen. So is the same reminder sent three times.
A campaign in Vatan takes a list, a channel and a message. Each person's row fills in their name and amount. Then the sends go out inside a window you choose, in the list's own time zone, at a rate you set and under a daily cap.
The channel is a public bot on WhatsApp or Telegram, or a text through your own SMS provider. The message is produced by a workflow, so it can be checked and changed before anybody receives it.
The collections template ends every reminder with the same line: reply STOP to stop these messages.
A reminder that reads like a final demand gets ignored, or gets a furious reply. Neither leads to a payment.
The reminder's words are yours, written once for the campaign, with each person's details filled in. The agent's replies follow a persona you set for the whole workflow: who it is, how it speaks, and what it must never say.
So the tone is a decision your team makes once, in writing, and can change. It is not something the model improvises at eleven in the morning on a Tuesday.
STOP means stop
Opting out has to work every time, on every campaign, without anyone remembering to check.
When a reply is only a stop word, the sender goes on the workspace's suppression list. They get one fixed sentence confirming it, and nothing else. The agent never sees the message, so it cannot argue with it.
Every send in every campaign checks that list first. A person who said STOP in June is not messaged by a new campaign in September.
The list keeps a hash of the address and its last four characters, never the address itself. That is what lets it outlast the campaign lists, which are erased a set number of days after each campaign ends.
The reply is a conversation
When somebody answers a reminder, the same workflow takes the reply. A decisions model sorts it into one of a few paths you name.
"I will pay on the fifteenth" is a promise to pay. "I already paid" is a claim to check. "I cannot pay" or "that amount is wrong" needs a person. "Wrong number" needs an apology and a way out.
Each path ends differently. The wrong number is told how to stop and tagged as such. The customer who says they paid is asked for a receipt. Anyone who cannot pay, or disputes the amount, is handed to your team with the conversation attached.
Each conversation is tagged with its outcome. By the end of the week you can see how many promised, how many had paid, and how many needed a person.
A promise is checked before it counts
A promise to pay is the one reply that changes a record. It is also the one where an agent can be too agreeable.
So before the promise is written to your system, a second model checks it against a policy you write in plain words. For example: approve a promise with a date within two weeks, refuse one with no date, and send anything else to a person.
The check answers approve, refuse or needs a person, with its reason. Only an approved promise is recorded. Everything else goes to your team, who can agree a plan a model should not.
The write itself is kept and retried if your system does not answer, so a promise is never lost because a server was restarting.
A reminder is personal information. So is the reply.
Where the conversation goes beyond the reminder itself, into a balance or a payment plan, the agent can ask for a one-time code first. It is texted to the number on the account, and the conversation waits until it is typed back.
This is slower by one message. It is also the difference between telling the account holder their balance and telling whoever picked up their phone.
Rehearsed before anybody is messaged
None of this should meet a real customer untested.
A test run walks the workflow as drawn, with every step that would send or write replaced by a fake reply. The decisions, the policy check and the wording all run for real. Nothing reaches a phone or your system.
You can try "I will pay next month" and watch the second check send it to a person, before a single reminder has gone out.
Collections done carefully is mostly about the reply, and about the reply that says stop.