A spreadsheet the size of a car park
Every summer someone in the lettings team builds the allocation spreadsheet. It has every booking, the room type they paid for, and a notes column full of requests: "wants to be with Aisha and Priya", "quiet flat please", "postgrad, not with first-years", "ground floor for medical reasons". Some requests came through the booking form, some by email, some through a parent phone call.
The person doing it drags names between rows for days. A late cancellation undoes a flat that was perfectly balanced. When allocations go out, the complaints start.
Why allocation is so hard to get right
The job is a puzzle with many constraints, and the constraints are held in free text rather than as data. Some are firm, such as an accessible room or single-sex flats if you offer them. Others are preferences. Without a clear order of priority, each allocator decides differently, and the process cannot be repeated or explained.
- Requests arrive by form, email and phone and are copied into notes by hand.
- Firm requirements and nice-to-haves are mixed together.
- Friend group requests are not mutual: one student names another who never named them back.
- Cancellations and late bookings break flats that were already planned.
- Nobody can explain afterwards why a student ended up where they did.
What a messy allocation costs
The allocator's time over several weeks is the obvious cost. The bigger one is the start of the year: room swap requests, unhappy flats, students who feel their request was ignored and parents who ring to say so. Rooms with accessibility features given to students who do not need them, while someone who does ends up elsewhere, is the kind of mistake nobody wants.
How we build room allocation
- Students fill in one allocation form, linked to their booking, with structured options: flat preferences, study level, quiet or social, and named friends. Accessibility needs have their own section that goes only to the staff who handle them.
- Friend requests are checked for mutual matches, and one-sided requests are flagged.
- Your rules are written in priority order, for example accessibility first, then room type paid for, then friend groups, then study level and lifestyle preferences.
- The tool proposes an allocation across buildings and flats that meets firm rules and as many preferences as it can, and shows each preference it could not meet.
- Staff adjust the proposal on screen by moving students between rooms, with warnings if a move breaks a firm rule.
- When a cancellation or late booking arrives, only the affected flat is re-planned, not the whole building.
- The final allocation is written back to your booking system, and students receive their room details.
| Request type | How it is treated |
|---|---|
| Accessible room needed | Firm rule, handled first |
| Room type paid for | Firm rule |
| Mutual friend group | Strong preference, kept together where possible |
| One-sided friend request | Flagged for staff |
| Quiet or social flat | Preference |
The rules and their order are yours. The tool proposes; staff decide.
What allocation season looks like after
Requests arrive in one place in a form that can be used. The first proposal takes minutes rather than weeks, leaving staff time for the awkward cases. When a student asks why they were placed somewhere, the answer is on screen. Room swap requests in the first weeks of term still happen, but for fewer reasons.
Does your allocation process look like this?
- Allocation is done by one person on a spreadsheet.
- Requests come in through several channels.
- Cancellations undo planned flats.
- Students often say their request was ignored.
- You could not explain the allocation rules if asked.