Student Room Allocation: Rules, Preferences and Automation

Every summer, student operators solve the same puzzle: fit hundreds of individuals into hundreds of rooms so that legal requirements are met, contractual promises are kept, and as many people as possible get something close to what they asked for. Done by hand on a spreadsheet, it is slow, error-prone and impossible to audit. Done as a constraint problem, it becomes a process you can run in hours and defend afterwards.

This post explains how student room allocation software actually models the problem: the hard constraints it must never break, the soft preferences it tries to satisfy, how to collect those preferences, a worked example, and an honest view of where automation helps and where a human still has to decide.

Allocation is a constraint problem

The mistake is to treat allocation as sorting: order the students, order the rooms, zip them together. Allocation is not sorting, it is satisfying many rules at once, some of which conflict. A student may want a quiet floor, a low price and a specific friendship group, and those three wishes may not coexist in any available room. The job is to honour the rules that cannot bend, then get as close as possible on the ones that can.

So the first discipline is to separate the two kinds of rule. Hard constraints are non-negotiable: breaking one is a failure. Soft preferences are goals: the more you satisfy, the better the outcome, but missing some is acceptable and often unavoidable.

The reason this matters at student scale is combinatorial. With a few dozen rooms and a few dozen people, a careful person with a spreadsheet can muddle through. With hundreds of rooms, hundreds of applicants, and a web of interacting rules, the number of possible arrangements is astronomical, and no human can hold it in their head. Worse, a manual allocation cannot be re-run when one late applicant or one cancellation shifts everything; you either patch it by hand and risk breaking a constraint you had already satisfied, or you start again. Modelling it as constraints and preferences is what makes the problem re-runnable and safe to change late.

Hard constraints: the rules you cannot break

These come from law, contract and the physical building. An allocation that violates any of them is wrong regardless of how happy it makes people.

• Contracted room type. A resident who paid for an ensuite studio must get one. The agreement is the constraint.
• Accessibility requirements. Accessible rooms must go to residents who need them, and those needs must be matched to the right adapted unit.
• Nomination and ringfencing. Where beds are committed to a university under a nomination agreement, those beds are reserved for that cohort and cannot be given away.
• Single-sex flat rules. Where a cluster or flat is designated single-sex, or a resident has requested single-sex shared facilities, the allocation must respect it.
• Capacity and configuration. You cannot place more people in a cluster than it holds, or split a group across incompatible room types.
• Any safeguarding or duty-of-care segregation. For example separating under-18 residents where your policy or the law requires it.

Hard constraints are where automation earns its keep immediately, because a machine never forgets one at two in the morning during peak intake. Every candidate placement is checked against every hard rule before it is even considered.

Soft preferences: the goals you optimise toward

Once the hard constraints define the feasible placements, soft preferences decide which feasible placement is best. These are the levers residents care about and the ones that drive satisfaction and, indirectly, retention.

• Friendship groups. Applicants who ask to live together. Usually mutual requests carry more weight than one-directional ones.
• Lifestyle fit. Quiet versus social floors, sleeping schedules, tidiness, smoking, whether they want to share with the same course or year.
• Course or cohort clustering. Some operators and universities like to group students by course, faculty or year of study.
• Floor, view, price band and proximity. The ordinary wishes: higher floor, specific building, budget ceiling, near the entrance for an accessibility-adjacent reason that is a preference rather than a requirement.
• Returner continuity. Existing residents who want to keep their room or flat.

The mechanics of scoring lifestyle and friendship fit overlap heavily with roommate matching; the housemate matching algorithms post goes deeper on how compatibility is scored, which is the same machinery applied to who shares a cluster.

Collecting preferences well

An allocation is only as good as the preference data feeding it, and most allocation pain traces back to bad inputs. A few principles:

• Ask structured questions, not free text. A dropdown for quiet-versus-social is usable by a machine; a paragraph about someone's ideal flatmate is not.
• Force ranking, not just wish lists. If everything is a top preference, nothing is. Make applicants rank so the optimiser knows what to trade away.
• Capture mutuality for friendship requests. Record who asked for whom so mutual matches can be prioritised and one-sided requests handled carefully.
• Timestamp everything. When preferences conflict and something has to give, a defensible tiebreak (application date, payment date, or a published priority order) prevents disputes.
• Collect at the right gate. Ask for preferences once the resident is committed enough that the data is real, not at first enquiry when it is aspirational.

Preference collection sits inside the wider onboarding flow; how it connects to booking and the rest of the pipeline is covered in the booking and onboarding module overview.

A worked allocation example

Take a hypothetical cluster flat of six ensuite rooms and six applicants. The figures are illustrative. First apply hard constraints:

• Two applicants are nominated by a university under a ringfenced block: they must go into designated nomination beds elsewhere, so they are removed from this flat.
• One applicant requires an accessible room, which this upper-floor cluster does not offer: removed and placed in an adapted unit.
• That leaves three applicants and, after the flat is rebalanced, three seats plus incoming others.

Now score the remaining feasible placements against soft preferences. Suppose two applicants made a mutual friendship request and both asked for a quiet floor; a third asked for a social floor and the same course cohort. A simple weighted score, mutual-friendship weighted highest, places the pair together on the quiet cluster and routes the third to a social-floor flat with coursemates. Nobody's hard constraint is broken, the strongest preference (a mutual request) is honoured, and the one unavoidable compromise (the third applicant does not get this specific flat) is the lowest-weighted wish. That is a good allocation: not everyone gets everything, but the trade-offs are the right ones and you can explain each.

Where automation helps, and where it does not

Automation is decisive on the parts of allocation that are mechanical and unforgiving at scale, and weak on the parts that need judgement.

The right pattern is machine-drafts, human-approves. The system produces a full allocation that respects every hard rule and optimises preferences, flags the placements it is least confident about, and hands a reviewer a short list of genuine decisions instead of a blank spreadsheet and eight hundred names. The reviewer's time then goes where judgement actually matters, the welfare cases and the genuine clashes, rather than being spent re-keying a grid that a machine could have populated correctly in seconds.

Auditability is the quiet requirement

When a resident asks why they did not get the room they wanted, or when a university partner queries how nominated beds were handled, you need an answer that is more than a shrug. Automated allocation produces a record: which constraints applied, which preferences were scored, and why a placement was chosen. That trail is worth as much as the speed, because it turns allocation from an argument into a decision you can stand behind.

Where this fits

Allocation is one stage of a bigger intake operation; the surrounding process is in the PBSA September intake playbook, and the summer version of the same puzzle is in PBSA summer lets. If you are evaluating tooling, our student housing software overview and the best student housing software comparison cover how allocation sits inside the wider platform.