Collections — Phase Tracker

Team alignment — 27 Aug (founders standup)

Source: the founders standup call (Gera, Federico, Sean), transcript in Slack #transcripts. The headline call: collections is explicitly DEPRIORITIZED behind scaling to ~5,000 units and hardening renewals + human-in-the-loop. Fede: "we're gonna start hitting sales and scaling to properties, I think that should be number one... if one of the customers is like hey we really want collections, I think we could consider going deeper." Sean agreed, and said he'd rather the time collections would take go into making sure renewals is solid, because right now "if it hits a roadblock, it just stops." Read every row below with that framing — this page is not the current top priority, on purpose.

What "Agentic" means here — settled, after real disagreement. The team explicitly rejected "send reminders" as the differentiator: "every PMS has that" (Fede), and AppFolio already sends its own late reminders today. What both Fede and Gera landed on as the actual value-add: (1) auto-drafting the Colorado 10-day demand/pay notice for Joanna to review and sign, pre-filled from the email-derived collection activity — Joanna herself, asked in person, called this "insane... that would save me so much time" — and (2) collecting the tenant's stated REASON for being late (job loss, etc.) and handing that to the property team as a fact they'd otherwise have to chase manually. "Dude, that's Agentic" (Fede); "I think that's a good agent, I like that" (Gera). This is exactly what p3a/p3b/p3g already build toward — the meeting confirms the direction, doesn't change it. Keep the existing 30/60/90 tracking dashboard as-is; both agreed it's good and should stay.

⚠️ Reminder CADENCE is explicitly UNRESOLVED — do not read it as decided. Sean proposed a full pre+post-due escalation sequence (day‑25 email, day‑28 SMS, due‑date SMS, day‑2 SMS+email, day‑4 SMS, day‑before‑late‑fee SMS+email). Fede pushed back hard — called it not-Agentic ("Web 2.0" thinking) and worried it annoys residents who already pay on time or are on autopay — and countered with something much leaner: audit once around day 3 and send one reminder, then hand off to the property team. Gera leaned toward the lean version but noted "a lot of people pay pretty late." Nobody picked a side; Fede: "I'll talk to Sean separately... maybe I'm being stubborn." Deferred to a Fede/Sean 1:1, not this meeting. Ground truth for Camellia specifically: no late fee today, and the real informal practice is Joanna checking the delinquent list around the 2nd–3rd of the month — which is closer to Fede's lean proposal than Sean's multi-touch one. This bears directly on p3i (the preventative pre-due reminder added below) — that row stays unscoped until this cadence question resolves.

New idea, not yet built — demand letters "bake" in Slack before printing. Gera's proposal: whenever a demand notice is ready, post it to the Camellia Slack channel (via Agent Smith) — "hey, we have a demand ready, let's go ahead and print it" — so the team can confirm before it goes out, rather than it being a silent artifact only visible in the product. Same shape as the approve-link Slack carrier shipped earlier today (PR #6423) — likely reuses the same notify() plumbing. Gera said he'd "set up the baking for now." Tracked as p3j below.

Also raised, not scoped: a nightly cron to keep Colorado late-fee/legal limits current, so the system can never draft a non-compliant notice (Gera) — this would be one path toward closing the "five of eight compliance facts are hardcoded false" item already in Standing risks below, not a separate new gate. And a longer-term idea from Fede — the AI giving a compliance "second opinion" on an owner's policy choice (e.g. late-fee amount) since "Colorado law changes all the time" — is a sales narrative point for now, not a scoped build.

Payment plans — reconfirmed Phase 2, and clarified: no AppFolio dependency needed. Fede: "a payment plan is just a promise to pay, with amounts and dates... you could put it in AppFolio, or you could handle it in PropFlow." If a tenant breaks the promised plan, PropFlow notifies the property team — it becomes their problem again, not an automated re-chase. Grace period and lawyer-escalation policy is owner/director-set (Kenya for Camellia), not an AppFolio setting. Gera added a payment-plan question to Camellia's Slack meeting-notes canvas during the call, so there's concrete input from Kenya's team by the time Phase 2 starts even though no work is happening on it yet.

Explicitly rejected, both restated from 25 Aug and newly reaffirmed: no lawyer-referral service for tenants (Gera: "that sounds like a headache... probably not ideal"); no UI-first approach — "there is no need for UI... Clara just does the letter" (Gera/Fede) — the only UI surface anyone wants is a signature step, which is p3a's territory, not a new form.

Open action item, not done: Gera wants Joanna's actual previously-printed demand-letter PDFs (likely sitting in her own email, self-forwarded) so a generated notice can be pre-filled to match what she already sends, rather than inventing a new format. Not yet requested as of this meeting.

⚠️ Do not cite as legal fact: Gera mentioned Colorado's late-fee cap as "like 5% or 50 bucks" on the call, from memory — that is his recollection, not verified research on this page, and should not be treated as a confirmed limit until checked.

Where this stands — 25 Aug

✅ THE FIRST RESIDENT HAS BEEN TEXTED — 2026-08-25, 19:57 MDT. Gera approved it on /review and it left 497 ms later. Twilio's own record says status: delivered, error_code: null, from Camellia's toll-free line, 2 segments — so the carrier carried rent copy without a complaint, which is what the registration question in p2h was really asking. Balance quoted: $2,700, re-read live from AppFolio at compose time. Nothing about the phone number's paperwork changed to make this possible.

Camellia's queue now reads { pending: 77, sent: 1 }. One send, ever. Everything still stops at a person clicking approve.

⚠️ None of the other 77 can be sent. They are 16–28 days old (median 21), and a captured reminder may only be approved within 48 hours of being written — after that the system can no longer vouch that the balance it quotes is still true, so approval refuses with stale_capture rather than sending. Nothing else on the review queue is something a click could turn into a text. That is exactly how the first send worked: a FRESH touch was run for the chosen resident, the cadence re-read the ledger, re-applied every stop (paid, moving out, payment plan, in collections, opted out), and composed against today's balance — which had doubled, $1,350 → $2,700, since his stale row was written on 2026-07-28. Approving the old one would have quoted a real person half of what he owes. That is the two-day window earning its keep on the first real case.

✅ Quiet hours proven too, 23:21 MDT the same night: a fresh capture approved during quiet hours refused quiet_hours, sent nothing, and stayed pending. So the gate is demonstrated in BOTH directions on the same property, four hours apart. Still to exercise: the first real inbound reply — hardship, dispute, or STOP — which is built and tested but has never met a live resident message on this lane. PR #6291 hides the 77 expired captures from the queue once it merges.

Phase 1 is closed. Phase 2 is built — the reply gate, the language gate, escalation, the stage holds, and as of today quiet hours run on the property's clock, refusing to send rather than guessing a building's time zone.

Nothing is left to build, and the carrier paperwork is NOT a blocker — corrected 2026-08-25 after reading Twilio's own guidance. Camellia's number is toll-free and its verification is approved, for a use case that describes maintenance traffic and never mentions rent. The resident-facing half is fixed and live: the privacy policy and consent page now say we text about rent and past-due balances (#6260).

The correction matters, because it points the other way. Twilio has no edit-in-place for an approved toll-free verification: changing the use case or the opt-in flow means delete-and-resubmit, the number drops to Pending, and a Pending toll-free number cannot send at all — maintenance and work orders included — until it is re-approved, at the back of the queue. Twilio's own wording: “No deletion and resubmission is required if you're only making minor changes to your use of the toll-free number for messaging, such as the message content.” So sending a rent reminder touches the registration not at all, while “fixing the paperwork first” is the move that takes the line down. Outbound renewal traffic already rides this number under the same summary.

The registration item that does need delete-and-resubmit is separate and deliberate: the verification declares opt_in_type: WEB_FORM with a web screenshot, while the real provenance is the number the resident gave the property through AppFolio. Worth fixing on a planned window, not as a side effect of a first send.

Counsel: deliberately skipped for the first-party question (Gera, 2026-08-25). Our own research is that the federal and Colorado collections statutes do not bind a landlord chasing its own current residents' rent. The risk being accepted is that nobody outside the company has confirmed it, and the one fact engineering cannot see is whether any balance was acquired already in default. Payment plans stay carved out — the research names that as the capability that genuinely needs a lawyer first, and it is a Phase 3 row.

How to use this

• Tick a box only when there is evidence — a merged PR, a live artifact, or a Slack post. Put the link in the Evidence column so nobody has to re-verify later.
• Amber items are Fede's. He has four collections branches open; those rows are here for visibility, not to be picked up.
• Ship updates to #updates as things land, and drop the permalink in Evidence.