The envisioning session at Lodgewise, a residential property-management agency, produced two AI pilots and a short list of ideas deliberately sent the other way. Top of that “not an AI problem” list was the one a director was most excited about: predict which tenancies will fall into arrears. The room tested it against the gate from when not to use an LLM and the answer was uncomfortable but clear. This wasn’t a language problem, it wasn’t even a machine-learning problem yet, and the version that delivered almost all the value was a rule the team could have written years ago.
This is that rule, built in full, because “use a rule instead” is only honest advice if someone shows you the rule is enough.
What the model would have cost
The pitch was a model that scored each tenancy on its risk of falling behind. Strip away the appeal and look at what it actually needed. Arrears is a structured-data question, days since last payment, amount outstanding, history, not a question about messy human text, so a language model is the wrong family entirely. A classical model trained on tabular features could in principle learn it, but it would need a labelled history, a training pipeline, an eval set, monitoring for drift, and an explanation for why it flagged a particular tenant, and a tenant who’s flagged for “risk” wants a better answer than “the model said so.”
Against all that sits the actual signal the agency cares about: a tenant is behind when their paid-up date is in the past. That isn’t a prediction; it’s a fact in the ledger. The fact captures the overwhelming majority of the value, costs almost nothing, and explains itself.
The rule
Arrears is a query. The ledger knows what’s owed and what’s been paid; the rule is the difference, in days and in dollars, bucketed into a few tiers that mean different things:
SELECT
t.tenancy_id,
t.property,
t.rent_amount,
t.rent_frequency,
t.paid_up_to,
CURRENT_DATE - t.paid_up_to AS days_overdue,
t.rent_amount *
(CURRENT_DATE - t.paid_up_to) / 7.0 AS approx_owed,
CASE
WHEN CURRENT_DATE - t.paid_up_to <= 0 THEN 'current'
WHEN CURRENT_DATE - t.paid_up_to <= 3 THEN 'grace'
WHEN CURRENT_DATE - t.paid_up_to <= 14 THEN 'arrears'
ELSE 'serious'
END AS tier
FROM tenancies t
WHERE t.status = 'active'
AND CURRENT_DATE - t.paid_up_to > 0
ORDER BY days_overdue DESC;
The thresholds (a three-day grace period, two weeks before it’s serious) come straight from the agency’s own policy and the relevant tenancy rules, not from a training run. When the policy changes, you change four numbers and you can explain the change to anyone. There’s nothing to retrain and nothing to drift.
Acting on it
A rule that nobody sees is as useless as a model nobody trusts. Run the query on a schedule, and turn each tier into an action the team already understands:
ACTIONS = {
"grace": None, # watch only, no contact yet
"arrears": "send_reminder", # automated, friendly
"serious": "raise_property_manager_task",
}
def run_daily(rows):
for r in rows:
action = ACTIONS.get(r["tier"])
if action == "send_reminder":
queue_reminder(r["tenancy_id"], r["approx_owed"])
elif action == "raise_property_manager_task":
raise_task(r["tenancy_id"],
f"{r['days_overdue']} days overdue, "
f"~${r['approx_owed']:.0f}. Policy: personal contact.")
A daily scheduled job, a friendly reminder at the arrears tier, a real task for a human at serious. The grace tier does nothing on purpose; chasing someone who’s two days late and always pays burns goodwill for no gain. The whole thing is a query, a cron schedule, and a switch statement, and the agency went from “arrears is visible three weeks deep” to “arrears is visible the morning it starts.”
Why the boring version wins
Set the rule beside the model that was proposed and the rule wins on nearly every axis that matters to a property manager:
- It’s explainable. “You’re eleven days overdue” is a complete, defensible reason. A model’s risk score is not, and the conversation it forces with a tenant is worse.
- It’s instant and free. No training, no inference cost, no GPU, no provider. A query.
- It’s auditable. Anyone can read the SQL and the thresholds and see exactly why a tenancy was flagged.
- It can’t drift. There’s no learned behaviour to decay, no eval set to maintain, no guardrail to test. The rule does in a year exactly what it does today.
- It’s correct, not approximately correct. The whole apparatus a model needs to keep its accuracy honest, the loops in keeping an AI pilot honest, simply doesn’t apply, because there’s no probabilistic output to monitor.
That last point is the real saving. The cost of an AI feature isn’t the build; it’s the standing obligation to watch it forever. A rule has no such obligation.
When a model would actually earn its place
Honesty cuts both ways: there’s a real question a model could answer that the rule can’t, which is who is about to fall behind for the first time, before they miss a payment. That’s a genuine prediction, and if the agency ever has the data and the appetite, it’s a classical model on tabular features (payment regularity, lead time, seasonality), not a language model. It would be a real project with a real monitoring burden, justified only if the early warning saved more than the upkeep cost. Framing that as a bet worth measuring is its own exercise: impact mapping an ML bet.
The point of the envisioning gate was never “don’t use AI.” It was “use it where it earns its place, and build the cheaper, more reliable thing everywhere else.” Arrears was everywhere else, and the agency got an early-warning system in an afternoon that will outlast every model in the building.