I'm parked on you

Everything I could decide myself is decided. What's left needs you. Each one has a recommendation from Fable — if you agree, pick it and press Done. "I'm not sure" is a real answer and becomes work for me. You don't need to open the session — pressing Done sends your answer back and it picks up.

1Owner report: what should 'recovery rate' mean? Both halves of the number already exist — this is the last thing between here and building it.

In plain terms. The weekly report we already email owners has past-due figures in it, and it already shows whether that went up or down since last week. The one thing it does not say is how much of the money owed actually came back. We can add that — the payment records go back to 2010 and are exact. The question is which number you want it to be: how much of the OLD debt we recovered (my recommendation), or just how much of this month's rent got paid. One catch either way: the payment records are filed monthly, so it would be 'last full month', not 'this week'.
Fable recommends: Debt recovered: of what delinquent residents owed at the start of the month, how much of it came in.
It is the only one of the three that answers the delinquency question you asked for, and it is the number a PM would defend in front of an owner: last month these residents owed $X, we got $Y of it back. The other reading measures whether rent gets paid at all, which the occupancy and AR figures already cover.
Tried first, unsuccessfully: I stopped guessing and read prod. The weekly owner report already exists and already carries aged AR, and the delinquency TREND is already computed and rendered — so recovery was the only gap. Then I measured whether it is even computable: not from the charge report, because a charge records one total paid against a LIST of receipt dates, so payments that straddle a week cannot be split — 23% of Camellia's rent charges have multiple receipts, and the unattributable share of dollars runs 49.8% at a week, 35.6% at a month, 8.1% at a quarter. The right source turned out to already be archived: a per-receipt ledger with exact dated amounts, 143 property-months at Camellia back to 2010, ~140 receipts and ~$130k a month. Both halves are persisted. I did not build it because the three readings below produce three different numbers in an owner's inbox.

a7390069 is parked on this.

2Camellia's carrier registration describes maintenance texts, not rent. Fix it (the line goes dark while it re-reviews) or close it and accept the mismatch?

In plain terms. The phone number Camellia texts from is registered with the carriers, and that registration is approved — but it describes maintenance messages and never mentions rent. We have now sent a rent text on it and it went through fine, and renewal messages have been going out on it for months under the same description. To make the paperwork match reality we would have to delete the registration and file it again, and while it is being re-reviewed that number cannot send ANY texts — maintenance and work orders too, not just rent. So the safe-sounding option is the one that costs something. My recommendation is to leave it and accept the mismatch.
Fable recommends: Close it — accept the mismatch. Nothing changes, the line keeps sending.
The resident-facing disclosure is already correct and live, outbound renewal traffic has ridden this same number under this same summary for months, and the first real rent text delivered clean with no carrier error. Fixing it is the only action here with a guaranteed cost — every text from that number stops, maintenance and work orders included, for as long as the re-review takes.
Tried first, unsuccessfully: I read Twilio's own onboarding guide rather than trusting my earlier claim, and it reversed my advice: there is NO edit-in-place for an approved toll-free verification, so changing the use case or the opt-in flow means delete-and-resubmit, and a resubmitted number sits in Pending — which cannot send at all — at the back of the review queue. Content changes need no resubmission. I also confirmed the registration is genuinely approved and that the mismatch is real: the summary describes inbound maintenance help and never mentions rent, and the opt-in is declared as a web form when the real source is the number the resident gave the property. What I cannot tell you is how a carrier would treat that mismatch if a resident complained — only the toll-free aggregator can answer that.

a7390069 is parked on this.

Pick an option above, then press Done.
PropFlow Docs