Automating Everything Except the One Decision That Can’t Be Automated
We automated the entire administration of a re-rental lottery, intake through appeals, while keeping the one thing that can’t be automated fully in human hands: the selection order itself.
- Affordable Housing
- AI-powered
- 6 min read
Stat Strip
Nine Units, Four Thousand Applicants
Easy to Run, Almost Impossible to Administer
Drawing lottery numbers takes an afternoon. Turning that ranked list into nine housed families, lawfully, in order, with evidence, takes a team months.
In a re-rental lottery, a regulated building with a small number of vacancies opens to public application, usually through an external housing portal. Four thousand households apply for nine apartments. What follows is the hard part.
Lottery administration is where fairness is either demonstrable or merely asserted. Manual processes can only assert it.
Six Reasons Nine Units Take Months to Fill
- The log file lands as a raw export: Thousands of rows from an outside platform, in that platform’s own format, need reconciling against the organization’s applicants and unit inventory.
- Order is legally binding: Households have to be worked strictly by log number within their preference and set-aside category. Any deviation must be documented, or it becomes a finding.
- Screening depth dwarfs the prize: To fill nine units, teams typically process ten to twenty times that many candidates, most of whom turn out ineligible, unreachable, or uninterested.
- Every rejection can be appealed: Each ineligibility has to produce a compliant notice, an appeal window, a reviewed decision, and a record, for hundreds of applicants, not nine.
- Applicants have no visibility: Which drives call volume, complaints to the oversight agency, and reputational damage that outlasts the lottery itself.
- The evidence sits scattered: Months later, when someone asks why applicant number 1,842 got passed over, the answer lives across an inbox, a spreadsheet, and a filing cabinet.
Automate the Administration, Never the Draw
One deliberate design decision sits at the center of the module: the system handles every task around the lottery, and no model touches the selection order itself.
Ranking stays deterministic, reproducible, and derived from the imported log number within the applicable preference and set-aside categories. Re-run it a year later on the same inputs, and the list comes out the same, which is exactly what a regulator, an auditor, or a court needs.
- AI log-file and application extraction: Lottery logs and application files from external housing platforms get parsed by a multimodal model straight from the source document, with an OCR fallback for large or poor-quality files. Thousands of rows become structured applicant records with log numbers intact.
- Deterministic, reproducible ordering: Applicants get ranked by log number within preference and set-aside categories. No model, no scoring, no discretion. The same inputs always produce the same order, and it can be regenerated on demand.
- Automated eligibility down the list: The rule engine screens candidates in order against income limits, household composition, student status, unit fit, and set-aside rules, so the team reaches the qualified households at the top of the list in days instead of working blindly through hundreds of files.
- Document reading and confidence scoring: Submitted documents get classified, extracted, and scored on field presence, profile match, date validity, and source. Low-confidence items route to a reviewer; the rest clear automatically.
- Compliant notices at lottery scale: Eligibility and ineligibility notices, information requests, unit offers, offer refusals, and appeal decisions get generated from case data and dispatched by email, text, and mail with per-recipient delivery evidence.
- Structured appeals: Appeals exist as first-class records with their own queue, deadlines, decision letters, and audit trail. Response time drops from weeks to days, and every decision stays attributable.
- Self-service applicant status: Applicants track their own position and outstanding requirements through the public portal, which removes most of the where-am-I-on-the-list call volume.
- An agency-facing review portal: The supervising agency reviews the lottery log, marketing plan, applications, and certifications in place, with review requests and findings recorded against the file instead of exchanged by email.
- Audit trail as a by-product: Every step, decision, override, and communication gets timestamped against a named user as the work happens, so the defense file exists before anyone requests it.
What gets automated, and what stays deliberately out of the system’s hands:
| Automated | Log import and matching: thousands of rows extracted and reconciled to applicants and units |
| Never automated | Selection order: deterministic ranking by log number within category, with no model involvement, by design |
| Automated | Eligibility screening: versioned rules applied identically to every applicant, with recorded overrides |
| Human decision | Appeals and exceptions: a named reviewer decides, and the platform records who, when, and why |
| Automated | Notices and offers: generated, dispatched, and tracked at lottery scale |
| Automated | Evidence capture: a full audit trail assembled continuously |
The Lottery Cycle, Before and After
| Lottery step | Manual process | With the platform |
|---|---|---|
| Log file import | 4,300 rows reconciled by hand over weeks | Extracted and matched automatically |
| Ranking | Sorted manually in a spreadsheet, re-sorted after every correction | Deterministic ranking, regenerable on demand |
| Working the list | Hundreds of files opened one at a time to find nine households | Rules screen in order, staff engage qualified candidates first |
| Document review | Read page by page for every candidate reached | Machine-read and scored, exceptions only |
| Ineligibility notices | Hundreds of letters produced individually | Generated in bulk with delivery evidence |
| Appeals | Email threads, about 30-day turnaround | Structured queue, about 6-day turnaround |
| Applicant inquiries | Constant inbound calls to the leasing office | Self-service status in the applicant portal |
| Agency reporting | Log and evidence packaged manually after the fact | Available live in the oversight portal |
A Ten-Person Lottery Team Down to Three
A lottery cycle for nine units is a ten-person effort under manual administration, because the workload is driven by applicant volume, not unit count. Automation breaks that link.
| Conventional team, 10 people | 1 lottery administrator, 2 log and data clerks, 3 eligibility screeners, 2 document reviewers, 1 appeals coordinator, 1 applicant hotline |
| AI-enabled team, 3 people | 1 lottery administrator, 1 exception and appeals reviewer, 1 applicant-relations specialist |
| Role | Manual load per cycle | Absorbed by |
|---|---|---|
| Log and data clerks (2) | 4,300 rows keyed, matched, and re-sorted | AI extraction plus deterministic ranking |
| Eligibility screeners (3) | Hundreds of files screened by hand, in order | Rule engine screening down the ranked list |
| Document reviewers (1) | Every document read against the declared profile | Extraction plus confidence-threshold routing |
| Hotline (1) | Continuous where-am-I-on-the-list calls | Applicant self-service status portal |
The appeals coordinator’s function does not vanish. It gets absorbed into a single exception reviewer, because the queue, deadlines, and decision letters get managed by the platform instead of a person with a calendar.
What Defensibility Is Actually Worth
- 5 weeks lottery close to first offer, down from 16.
- 70% reduction in lottery administration staffing.
- About 6 days appeal turnaround, down from about 30.
- 0 model involvement in the selection order.
- Defensibility is the product: Lottery outcomes get challenged. When they are, the question is always the same: why this household and not that one? Because ordering stays deterministic, screening rules are versioned, overrides get recorded, notices carry delivery evidence, and every action gets attributed, the answer is a report that can be produced in minutes and reproduced years later. That is a materially different legal position than a spreadsheet and an inbox.
- AI where it helps, absent where it would cause harm: Automated selection in regulated housing is a liability, not a feature, and buyers, regulators, and tenant advocates all know it. Keeping models out of the draw while using them heavily for extraction, screening support, and correspondence is a position that holds up publicly, and survives scrutiny that a fully automated selection story would not.
- Faster occupancy on the units nobody else fills quickly: Lottery-allocated re-rentals are typically the slowest units in a portfolio to fill because of the administrative overhead. Cutting eleven weeks out of the cycle converts that overhead directly into collected rent and into households housed sooner.
- Applicant trust as an asset: Transparent status, timely notices, and quick appeals reduce complaint volume to the oversight agency, the kind of operating reputation that determines whether an owner gets awarded the next allocation.
- Why it compounds: Workload scales with applicants, value scales with units. That asymmetry is exactly what automation is built for.
- It shares the same foundation as the other modules: The same rule engine, document intelligence, and audit trail run underneath lease-up, recertification, and re-rentals.
- Portable across jurisdictions: Set-aside and preference structures live in configuration, so a new lottery regime onboards without engineering work.
Run a Lottery You Can Defend Line by Line
Ariel builds the systems affordable housing teams run their highest-scrutiny event on. If your next re-rental lottery will draw thousands of applicants for a handful of units, our team can show you the full cycle: import, ranking, screening, notices, appeals, and the audit file, running against your own preference and set-aside rules.
Figures in this case study model a reference re-rental lottery cycle: 9 vacancies drawing roughly 4,300 applications. They illustrate the operating leverage of the module rather than one named client’s result. Actual outcomes vary with applicant volume, preference structure, jurisdiction, and incoming data quality.
