Reminders go stale fast

Every month, a few tenants are overdue on rent or utilities. Someone has to check each balance, write each message and send it.

That part's easy. The hard part is keeping the reminders accurate.

A morning report says a tenant owes ₮200,000. By the afternoon they've paid. If the morning's reminder still goes out, it's wrong.

A wrong message costs more than a late one

A stale reminder is worse than no reminder:

  • The tenant who paid gets chased anyway, and their trust drops.
  • I spend the afternoon apologising and rechecking records.
  • A timed-out send gets retried, and one reminder arrives twice.
  • A building announcement goes to the wrong group, or exposes someone's balance or who reported a problem.

None of this is hard to prevent. It just takes the same checks every time, and people skip checks when they're busy.

Check the record, then send

I already have Mongolian rental templates and sending tools. The agent reuses them. It doesn't need new ones.

  1. Refresh the records. The agent pulls current bookkeeping data before every batch. Rent and utilities stay separate, so each message says exactly what's due.
  2. Drop what's no longer needed. If a matched payment has arrived, that reminder goes.
  3. Prepare the drafts. Each one shows the verified contact, the actual message with its period and balance, and the record behind it.
  4. I review recipients and wording. If a balance changes during my review, the draft changes too.
  5. Record each result. The agent logs the result for every recipient, not just the batch. If a request times out, the result is unknown until the agent checks the message history.

Announcements are a separate task. The agent needs a clear scope: one tenant, one floor or the whole building. Asking it to contact one person never turns into a message to everyone.

The record decides whether there's a message to send.

Batch results per recipient: three delivered, one timed out and marked unknown until the message history is checked, and one dropped because the tenant paid.
Every recipient gets a result. A timeout stays unknown until the history is checked.

A short list, and my call on what's next

What I get back is three lines:

  • Sent: delivered, with evidence from the channel.
  • Needs attention: failed, unknown or contact unverified.
  • No reminder needed: paid since the last report.

That's enough to know what happened. Chasing anyone further is still my decision.

This workflow is built around my existing rental tools. The examples are fictional, and the app's live sending connections still need validation.