Skip to main content
DoneThat

AI Adoption GuidePropertyOccupy

Tenant Churn Risk Predictor

ML infers churn risk from maintenance request frequency, payment behavior, and communication sentiment ahead of lease events, enabling proactive retention outreach.

Property processAcquireLeaseOccupyMaintainBillRenewVacateDispose

By Don, DoneThat’s AI coach · updated

Overview

Lease events concentrate turnover cost: vacancy, make-ready, concessions, and leasing labor stack up when a household leaves. A tenant churn risk predictor does not renew the lease or write the outreach. It scores how likely a household is to leave, using maintenance request frequency, payment behavior, and communication sentiment, so a property manager can decide whether to intervene before notice is given.

The useful output is a ranked watchlist with a score, the signals that moved it, and a recommended human review window. Staff still own the conversation, the offer, and the file note.

What the predictor is for

Turnover is expensive because it is late. By the time a notice arrives, the household has often already decided. Maintenance tickets, late or partial payments, and the tone of portal messages or call notes often shift weeks earlier. The model’s job is to surface those shifts while there is still time to inspect the unit, fix a lingering work order, or have a retention conversation.

Treat the score as a triage signal, not a verdict. Two households can share a similar risk band for different reasons: one is drowning in unresolved tickets, another is current on rent but sending frustrated messages about noise or billing. The property manager still needs the why, because the outreach is different.

The predictor belongs in occupy-stage operations, next to day-to-day resident service rather than leasing. It complements tools that answer tenant questions after hours, such as the 24/7 Tenant Query Agent, because unanswered or poorly handled queries often show up later as negative sentiment in the same communication stream the model reads.

Signals the model uses

Three histories have to be present and joinable to a household and a lease. If any one is missing, the page should not invent a score.

Maintenance request frequency is not a raw ticket count. Recency, repeat categories, time-to-complete, reopen rates, and whether the same issue spans multiple work orders matter more than volume alone. A household that files one well-handled request is not the same as a household with three open HVAC tickets in a month. Condition at move-in also matters as context: if intake photos and notes are thin, later “pre-existing” disputes are harder to interpret. Move-In Condition Documentation is the usual source for that baseline.

Payment behavior covers more than a single late fee. Patterns include days-to-pay, partial payments, NSF events, payment-plan usage, and sudden changes relative to that household’s own history. A long-tenured resident who starts paying later than usual is a different signal from a household that has always paid on the last allowed day. Do not equate payment stress with an automatic renewal discount. Ability to pay and willingness to stay are related, but they are not the same decision.

Communication sentiment comes from portal messages, email, chat transcripts, and staff notes, scored for frustration, urgency, and unresolved topics. Sentiment is noisy. Sarcasm, short replies, and language mix can flip a label. Use it as a supporting feature, and keep the original text available for the person who will call. Energy or comfort complaints sometimes sit in this stream as well; when usage or billing disputes are in play, the ESG & Energy Consumption Monitor can explain whether the resident’s claim matches metered reality, without turning the churn model into an energy dashboard.

Lease calendar features (days to expiration, remaining options, transfer or roommate changes) are useful as timing, not as substitutes for the three histories. A high score 90 days out is an operations problem. A high score 14 days out is a leasing and make-ready problem.

When the model must return nothing

Empty output is the correct result when the predictor cannot honestly score the household.

If maintenance history is missing (no work-order feed, no unit-level tickets, or the household cannot be matched to a unit), do not backfill with community averages. If payment history is missing (new transfer with no ledger, a system cutover with incomplete aging, or a corporate housing account with opaque billing), do not score from sentiment alone. If communication history is missing (no messages, calls logged without notes, or a channel the model is not allowed to read), do not treat silence as satisfaction.

Also return empty when coverage is too thin to be stable: a brand-new move-in with a handful of days of data, a household whose tickets live under a prior unit number, or a ledger that only contains the current month. Show the gap in the UI so staff know this is “not enough evidence,” not “low risk.”

False confidence is worse than a blank row. A property manager who trusts a low score on a dark record will skip the households most likely to surprise them at notice.

How staff should use a high-risk score

The model ranks. People act.

A practical loop looks like this. Each week (or more often near a large expiration cohort), pull the high-risk list, filter to leases inside the outreach window you actually staff, and open the signal summary. Confirm the data is current. Then assign an owner: community manager, assistant, or a designated retention lead. That person reviews the file, walks the unit if maintenance is the driver, and decides whether to contact, wait, or escalate to a supervisor.

Outreach should start with listening and facts, not with a concession script. Ask what would make staying workable. Check open work orders. Correct a billing error if one exists. Document the conversation in the same system the model reads, so later scores do not keep firing on an issue you already closed.

Keep a human checkpoint before any commercial offer. The predictor must not auto-offer free rent, waived fees, or upgrades. Those decisions have budget, fairness, and precedent effects. A model that emails a discount because sentiment dipped will train residents to complain for price, and it will treat two similar households differently without a recorded reason.

When you do authorize an offer, record the reason, the amount, the expiry, and who approved it. The next review should ask whether the household stayed and whether the underlying operational issue was fixed. Retention that only buys a 30-day delay is not a win.

Limits, fairness, and what not to automate

Do not use the score as a screening tool for future applicants, as a reason to withhold repairs, or as a substitute for legal notice handling. Payment features can correlate with hardship. Sentiment features can correlate with how loudly someone writes. Maintenance frequency can correlate with unit quality that the owner, not the resident, controls. Staff should see the contributing features so they can challenge a score that does not match the file.

Keep a review path: a manager can mark a score as stale, as a data-match error, or as “known situation, no outreach.” Those labels should suppress repeated alerts without deleting history.

Do not auto-generate notices to vacate, auto-start collections, or auto-post charges from this model. Those are different workflows with different evidence standards. The churn predictor’s job stops at ranking risk and explaining which of the three histories moved.

Expect the list to be wrong at the edges. A household may look risky because they file tickets promptly, which is often a sign they intend to stay if you fix things. Another may look calm because they have given up on the portal. That is why empty output on missing channels matters, and why a person still places the call.

Use the score to spend scarce manager time on the households where maintenance, payment, and communication together say “this lease is in play.” Then let staff decide what, if anything, to offer.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other. This one is rated high effort to implement, so the baseline matters more than usual.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first