Most software treats a payment reminder as a growth surface: send more, send sooner, optimise the open rate. Rent arrears are not that. In Kenya the sequence of demands a landlord makes is potentially evidence, and the question the software has to answer is not "did this convert?" but "if this ends up in front of a tribunal in eight months, does the record hold up?"
That reframes almost every design decision.
The sequence is deliberate and slow
Three steps, with a grace period before any of them:
- A grace period in which nothing at all is sent. Rent arrives late for ordinary reasons and the first week of arrears is not evidence of anything.
- A reminder. Short, neutral, no legal language, no fee.
- A formal notice. Names the amount, the period, and the consequence.
- A final notice. A legal instrument, and it reads like one.
Nothing is sent inside the grace window at all. A tenant five days late has usually not defaulted; they have been paid late themselves, or the landlord's paybill was down, or they are travelling. Automating a demand into that window damages a relationship to recover money that was arriving anyway.
The gaps widen as the sequence proceeds, because each step has to be defensible as a distinct escalation rather than the same message sent three times. A tribunal reading four demands inside nine days sees harassment. Reading a reminder, then a formal notice a fortnight later, then a final notice a fortnight after that, it sees a process. The intervals are configurable per organisation; the widening is not.
Register changes with each step, and so does language
Step one is a nudge. Step three is a legal instrument and reads like one. Four things have to be in it and nothing else belongs: who is being addressed and for which unit, exactly how long the rent has been outstanding and how much is owed, what happens next and by when, and the statute the remedy rests on. In Kenya that last one is the Distress for Rent Act. No apology, no negotiation, no marketing footer.
It names the statute, states the outstanding amount, states the period, and gives a specific deadline. That is not a stylistic choice; a demand that cannot be tied to a legal basis and a number is a demand that does not do much work later.
Every step exists in English and Swahili. This is not a localisation nicety. A notice a tenant can demonstrate they did not understand is a weaker notice, and a notice that opens "kodi yako imechelewa" is the sentence a great many Kenyan tenants will actually read.
Escalate the tenant, not the invoice
A tenant three months behind has three overdue invoices. Escalating per invoice sends three separate demands on three different schedules, which reads as chaos and is trivially attacked as such.
So the queue groups by tenant, sums the outstanding across their unpaid invoices, and takes the age of the oldest to decide the step. One tenant, one position in the sequence, one total. The demand a tenant receives corresponds to the situation they are actually in.
The log is the product
Sending is the easy half. What makes the sequence usable eight months later is that the record cannot have been quietly improved in the meantime.
The notifications table is append-only at the database layer, which forces a specific discipline: escalation metadata is attached at insert time, not updated onto the row afterwards.
Append-only is enforced at the database layer rather than by convention, which forces the discipline upward: everything you will later want to know about a message, including which escalation step it belonged to and which language it went out in, has to be attached at the moment it is written. There is no second pass in which the record gets tidied up, because there is no update.
That constraint is doing real work. If steps could be edited after the fact, the log would be a record of the current story rather than of what happened, and its evidentiary value would be close to zero.
Note also that arrears messages claim no exemption. They are subject to the same frequency caps, quiet hours and opt-out rules as everything else. A tenant who has opted out of marketing has not opted out of a legal notice, but they have opted out of being messaged at 21:30, and the sequence respects that. It is both the lawful position and the one that survives scrutiny.
Exporting it in a form somebody else can read
The log exports as CSV over a date window, sorted oldest-first so it reads chronologically, with proper RFC 4180 escaping so a message body containing a comma does not silently corrupt the file. The columns are the ones that actually get asked about in a hearing: when it was created, when it was sent, whether and when it failed, who it was addressed to, which step of the sequence it was, which language it went out in, the exact text, and any error the provider returned.
The sent timestamp, the failure timestamp and the provider error are all present. A landlord asserting they sent three notices needs to be able to show the third one actually left, and if it did not, that is better discovered while preparing than while being cross-examined. An export that only contains successes is an export that hides the one fact most worth knowing.
The general principle
When software takes an action with legal weight, the record of the action matters as much as the action. That means append-only storage, metadata written at the moment of the event, delivery failures kept rather than hidden, and an export a person who has never seen your database can read. None of it improves collection rates this month. All of it decides whether the sequence is worth anything the one time it matters.