Why Most Schools Still Run Their Lottery in Excel — And Why That's a Problem
Every year, thousands of charter and magnet school admissions directors sit down with a spreadsheet, a list of applicant names, and a prayer that nothing goes wrong.
Excel has been the default tool for school enrollment lotteries for decades. It's familiar. It's free. And for most schools, it's "good enough" — until it isn't.
Here's an honest look at why schools keep using Excel, what actually goes wrong when they do, and what a better process looks like.
Why Schools Default to Excel
The reasons are understandable:
It's already there. Every school has Microsoft Office or Google Sheets. There's no procurement process, no IT request, no budget line to justify.
It worked last year. If a school has run five lotteries without a formal challenge, the instinct is to keep doing what's working.
The alternatives seemed complicated or expensive. Most admissions directors who've looked at enrollment software have found tools that are either enterprise-grade (expensive, complex, requires IT) or niche (functional but dated). Neither option felt worth the switch.
No one showed them a better way. Lottery administration is a small corner of school operations. Most professional development doesn't cover it, and most admissions directors learn the process from whoever had the job before them.
The result: a process built for convenience that creates compliance exposure most schools don't fully understand.
The Technical Problem With Excel Lotteries
Let's start with the most common method: using Excel's RAND() or RANDBETWEEN() function to assign random numbers to each applicant, then sorting by those numbers to generate a ranked list.
This seems reasonable. Here's why it isn't.
RAND() recalculates every time the file opens. Every time you open the spreadsheet after running the lottery, Excel recalculates all the random numbers. The results change. The version you saved after running the lottery is different from the version you open two weeks later. If a parent asks you to reproduce your results, you can't.
There's no seed. Cryptographically sound random number generation uses a "seed" — a fixed input that makes the results reproducible. Excel's RAND() function doesn't work this way. There's no record of what inputs generated your results, which means there's no way to independently verify them.
The formula can be manipulated. An administrator with access to the spreadsheet can change results manually — by re-sorting, by editing values, by deleting rows. Whether or not that actually happens, you can't prove that it didn't. That's a problem when a parent or authorizer asks you to demonstrate the lottery was fair.
Version control is a nightmare. How many versions of your lottery spreadsheet exist? The original, the version where you corrected a typo, the version someone emailed to the principal, the version you archived? Which one is the official record?
The Process Problems Are Worse Than the Technical Ones
Beyond the technical limitations, Excel lotteries create operational problems that compound every year.
Manual offer tracking. After the draw, someone has to track which families were offered seats, whether they responded, when offers expire, and who's next on the waitlist. In Excel, this means manually updating rows as phone calls come in and emails are sent. It takes hours. Errors are common.
Waitlist management requires constant attention. Every time a family declines or an offer expires, someone has to manually identify the next person on the waitlist, contact them, record the new offer, and track the new deadline. For schools with long waitlists, this process can run for weeks.
Parent communication is manual. Offer letters, waitlist notifications, acceptance confirmations — in an Excel-based process, all of these are typically produced and sent manually. Formatting inconsistencies, delayed notifications, and missed follow-ups are routine.
Documentation is assembled after the fact. When an authorizer asks for lottery documentation, schools with Excel-based processes have to gather records from multiple files, emails, and notes. The "documentation" is reconstructed rather than generated — which is exactly the kind of record that doesn't hold up under scrutiny.
What Actually Goes Wrong
Most Excel lotteries don't result in formal challenges. But the near-misses are common:
The spreadsheet gets corrupted. A file saved incorrectly, a formula that breaks, a row accidentally deleted. By the time anyone notices, the original data is gone.
A preference wasn't applied correctly. A sibling preference that was supposed to move 12 families to the top of the list only moved 11 because one sibling's enrollment status wasn't correctly captured in the spreadsheet.
Results were accidentally changed. Someone opened the spreadsheet after the lottery, the RAND() values recalculated, and the file was saved. Now the records don't match the notifications that were sent.
A parent requests documentation and the school can't produce it. The spreadsheet exists, but it doesn't prove anything — it just shows the results, not how they were generated.
An authorizer asks for lottery records during a compliance review. The admissions director spends a week assembling documentation from emails, spreadsheets, and memory, and the resulting record has gaps that create more questions than they answer.
None of these situations are catastrophic on their own. But they're all preventable — and they all stem from the same root cause: using a tool that wasn't built for this purpose.
What a Better Process Looks Like
A compliant, defensible lottery process isn't complicated. It just needs to do a few things that Excel can't:
Generate verifiable results. The draw should use a cryptographically sound random process with a fixed seed — so results can be independently reproduced and verified.
Produce an automatic audit trail. Every lottery action — application received, draw run, offer sent, offer accepted, waitlist promoted — should be logged automatically with timestamps. No assembly required.
Run automatically. Offer notifications, waitlist management, deadline tracking, and reminder emails should happen without manual intervention. The process should run itself.
Keep records in one place. Applications, results, offers, responses — all in a single system, permanently accessible and exportable.
The school that runs their lottery this way doesn't just have a better process — they have a lottery that can withstand any challenge. When a parent asks "was this fair?" the answer isn't "trust us." It's a link to the audit trail.
The Cost of Switching Is Lower Than You Think
The main reason schools stay on Excel is inertia. Switching feels like a project — something to tackle next year.
But the actual cost of switching is a few hours of setup, not weeks of implementation. Modern enrollment lottery software is web-based, requires no IT involvement, and can have a school ready to open applications the same day they sign up.
The cost of not switching is harder to quantify — until you're spending three weeks assembling documentation for an authorizer review or fielding calls from a family whose application may or may not have been included in last year's lottery.
The Bottom Line
Excel is a great tool for many things. Running a legally defensible, auditable enrollment lottery isn't one of them. The technical limitations are real, the process problems are predictable, and the compliance exposure is unnecessary.
Schools that switch to purpose-built lottery software almost universally report the same thing: lottery season got significantly easier, families trust the process more, and they stopped worrying about what would happen if someone challenged the results.
That's not a bad trade for a few hours of setup.