Why Small PHAs Still Run Housing Lotteries On Spreadsheets

If you run lotteries and waitlists for a small public housing authority, the quiet cost is almost always labor: two experienced staff spending 12–18 minutes per application on verification, status calls, and exception handling can burn $18,000–$28,000 per intake cycle in loaded payroll alone—before you count applicant frustration, audit prep, or leadership time spent refereeing spreadsheets. We’ve seen this pattern collapse to under 4 seconds per application when the pipeline is rebuilt properly — documented across 20,000+ applications for a New Jersey housing program. Purpose-built lottery and waitlist software for a small PHA typically lands between $8,000 and $45,000 to implement depending on rules complexity, compared with $400–$900 per month for lighter SaaS tiers that still force you into their data model. The honest win is not magic AI; it is replacing a brittle manual pipeline with something applicants can trust and your auditors can read.

Why spreadsheets fail small PHAs first

Spreadsheets feel free until they are not. When every funding round tweaks eligibility, your workbook forks. When applicants upload PDFs that conflict with the portal, staff become human OCR. When lottery draws need defensible randomness and timestamped evidence, the workbook is the wrong system of record. Small teams feel this faster than large housing agencies because there is no bench—one sick day becomes backlog, and backlog becomes political risk.

You already know the symptoms: duplicate records, versioned attachments in email, and status answers that depend on who picked up the phone. The fix is not another column. It is a workflow with states, queues, and reviewer gates that match how your program actually decides.

What “lottery software” should actually cover

• Intake validation that stops incomplete packets before they enter the lottery pool
• Randomized selection with logged seeds, freezes, and appeals handling that your counsel can explain
• Waitlist movement rules that survive mid-year policy changes without a manual merge
• Applicant-facing status that reduces “did you get my fax?” calls without overpromising outcomes

If a vendor pitches AI first and rules second, treat it as a signal to ask harder questions. Housing programs live or die on defensible process, not demos. The best stacks pair deterministic rules with AI assistance only where it speeds document checks or drafting under human review—similar to the production pattern we describe for application processing workflow systems and the housing intake case study.

Build vs. rent: how to think about budget

Renting a generic lottery module gets you live faster, but you will still pay integration tax: identity, document storage, CRM exports, and reporting that matches your board packet. Building a focused portal costs more up front and saves you when your rules do not fit a template—especially for mixed funding sources, local preferences, and exception queues that SaaS products treat as “professional services.”

As a rule of thumb from founder to founder: if more than thirty percent of your lottery work is exceptions, you are already building a custom process in spreadsheets. You might as well put it in software you control, with tests, instead of in Vivian’s head until Vivian retires.

Human review, audits, and the parts AI should not touch

Fair housing and public trust mean some steps should never be fully automated: final eligibility determinations, adverse letters, and anything that looks like a legal conclusion belong in reviewer queues with reasons attached. AI can shorten the path to those decisions by assembling evidence and flagging inconsistencies, but the signature is still human. That is how you keep speed without trading away defensibility.

Operationally, bake in instrumentation before you widen automation: time-in-queue, disagreement rates between staff and suggested outcomes, and reasons for overrides. Those metrics tell you whether you are actually saving minutes or just moving panic to a different inbox. The same discipline shows up when you design transparent lottery communications and applicant status without phone-tag—systems win when the metrics match reality, not slide decks.

A pragmatic rollout plan

Pilot with one program and one cohort. Freeze requirements for eight weeks. Ship read-only reporting first so leadership trusts the numbers. Only then turn on auto-routing for the cases that are statistically boring. If your vendor cannot describe rollback in one paragraph, you are not buying software—you are buying hope.

Small PHAs deserve the same operational dignity as large agencies. The budget is tighter, but the stakes for families are not. Build the smallest system that makes the lottery legible, then iterate. That is how you keep trust while still moving faster than fifteen minutes per packet.