Skip to main content

PBSA September Intake: Onboarding Hundreds of Students in Weeks

Purpose-built student accommodation compresses a year of move-ins into a fortnight. This is the bulk intake process: a pre-arrival stack, a worked T-8 to T+2 timeline, room allocation, an arrivals-day operation, and the staffing maths behind it.

August 19, 2026

Most property operations spread their move-ins across the year. Purpose-built student accommodation does the opposite. A PBSA scheme signs a year of licence agreements over the spring and summer, then delivers almost all of them in a single fortnight in September. The intake is not a busy period. It is the operation, and everything from cash collection to your first-term reputation is decided by how well you run it.

This is a playbook for that fortnight and the weeks that feed it. It treats bulk intake as a pipeline rather than an event: a sequence of steps that each resident has to clear before their key works on arrivals day. Get the sequence right and a student accommodation bulk intake process scales from fifty beds to a thousand with the same shape. Get it wrong and you are re-keying rooms at midnight while a queue forms at reception.

Why bulk intake breaks generic tools

A conventional lettings workflow assumes move-ins arrive one at a time, with slack between them to chase a missing document or a late payment. PBSA removes the slack. Suppose a 600-bed scheme with a September arrivals window of ten days: that is an average of sixty move-ins a day, and in practice they cluster on the first weekend, not spread evenly. Every task that is fine to do manually once becomes a failure point when it happens six hundred times against a deadline.

The three things that break first are document collection, payment reconciliation, and room allocation. Each is individually simple. Together, at volume, they are where operators lose control. The fix is not more staff on arrivals day. It is moving as much of the pipeline as possible to before arrivals day, so that the day itself is a key handover and nothing else.

Map the intake as a pipeline, not an event

Every resident has to pass through the same gates before they can collect a key. Name them, and track each resident's position against them, and the intake becomes measurable weeks ahead. A workable set of gates:

  • Offer accepted: the applicant has confirmed and the room type is agreed.
  • Agreement signed: the tenancy or licence agreement is executed. For the legal shape of these agreements and where Right to Rent exclusions may apply, see the sections below and confirm your own position.
  • Guarantor cleared: a UK guarantor is in place, or the resident has taken the alternative your policy allows. Guarantor rules are their own topic, covered in the companion post on student guarantor requirements.
  • Deposit and first payment settled: the money has cleared, not just been promised.
  • Compliance complete: identity, right to occupy, and any nomination or sponsorship paperwork is on file.
  • Room allocated: a specific bed is assigned and ready.
  • Arrival slot booked: the resident has a date and a time window.

The single most useful report during intake is not occupancy. It is the count of residents stuck at each gate. If four hundred residents have signed but only two hundred have cleared their guarantor with two weeks to go, you know exactly where to point your team, and you know it early enough to act.

The pre-arrival stack: what to clear before the doors open

Work backwards from arrivals day. Anything that can be completed in advance should be, because advance work is calm and arrivals-day work is not. The pre-arrival stack, roughly in order:

  1. Agreement execution. Send agreements as early as the cycle allows and chase signatures as a distinct workstream. An unsigned agreement blocks everything downstream.
  2. Guarantor and payment setup. These two travel together, because a resident without a UK guarantor often resolves it by paying more rent in advance. Decide your policy once and apply it uniformly.
  3. Deposit protection. Where a deposit is taken under an assured shorthold tenancy, protection obligations and prescribed information deadlines apply. PBSA licences and some student lets are structured differently, so confirm which regime each of your agreements falls under rather than assuming.
  4. Right to occupy and compliance checks. Identity and, where applicable, immigration status. Note that certain specified student accommodation may fall within a Right to Rent exclusion, but the exclusion turns on how the accommodation is provided or nominated, not simply on the occupier being a student. Do not assume it applies. The mechanics of checking are covered in the Right to Rent checklist for HMO landlords, most of which carries across.
  5. Room allocation. Assign specific beds once the cohort is largely known, so you can honour preferences and group requests.
  6. Arrival scheduling. Give every resident a booked slot. Unmanaged arrivals all land in the same four hours.

A worked intake timeline

Suppose a 600-bed scheme with a ten-day arrivals window opening on a Saturday. The dates are illustrative, but the shape holds at any size.

WhenMilestoneTarget state
T-8 weeksAgreements out to all confirmed residents90%+ of the cohort has an agreement to sign
T-6 weeksGuarantor and payment driveGuarantor policy communicated, first payment requests issued
T-4 weeksCompliance sweepIdentity and right-to-occupy checks underway, gaps flagged
T-3 weeksRoom allocation lockedEvery cleared resident assigned a specific bed
T-2 weeksArrival slots bookedArrivals spread across the window, peak day capped
T-1 weekReadiness checkRooms cleaned and inspected, keys cut, welcome packs assembled
T-0 to T+10Arrivals windowKey handover only; exceptions handled at a separate desk
T+2 weeksReconciliationNo-shows chased, unlet beds released to clearing, payments reconciled

The two dates operators most often underestimate are T-2 (arrival scheduling) and T+2 (reconciliation). Without booked slots, the first weekend overwhelms reception. Without a reconciliation step, no-show beds sit empty for weeks because nobody formally released them back to the letting pipeline.

Room allocation and rooming groups

Allocation is where student housing differs sharply from unit-based property. You are not letting a flat, you are seating a person into a specific bed within a shared cluster, and the mix of who sits together shapes the community and the complaint volume all year. A few rules that hold up at scale:

  • Allocate at bed level, not room or flat level. A cluster flat with five bedrooms is five separate agreements and five separate allocations.
  • Honour explicit rooming groups first. Students who applied together to share a flat should be seated together, and breaking those groups is a reliable source of early cancellations.
  • Hold a buffer of unallocated beds for late arrivals, clearing, and swaps. A scheme allocated to 100% on paper has no room to solve the inevitable problems.
  • Keep allocation reversible until arrival. People withdraw, defer, and change room types right up to the day, so freeze allocations as late as your operation can bear.

The arrivals-day operation

If the pre-arrival stack has done its job, arrivals day is a logistics exercise, not a lettings one. The design goal is that a fully cleared resident can collect a key in minutes without anyone opening a laptop to check their file. A workable arrivals-day checklist:

  • Split the queue. One fast lane for fully cleared residents (key handover only), one exceptions desk for anyone with an outstanding gate. Never let one blocked resident hold up the cleared ones behind them.
  • Pre-print and pre-pack. Keys, fobs, and welcome packs assembled and labelled by room the week before, not cut on the day.
  • Staff the exceptions desk with decision-makers. The people handling missing guarantors or unpaid balances need the authority to make a call, not to escalate.
  • Capture arrival, not just handover. Record who has physically arrived, because that is what drives your no-show list and your released-bed count.
  • Have a maintenance runner on shift. The first thing residents find is the broken blind or the shower that will not drain. Fixing it in the first hour buys goodwill for the whole term.

The staffing maths

Staffing an intake is a throughput problem, and throughput is easy to size once you know your service time. Suppose a fully cleared resident takes four minutes at the fast lane and an exceptions case takes twenty. If 600 residents arrive across a ten-day window but 45% land on the first weekend, that is roughly 270 arrivals across two days, or around 135 a day at peak.

Peak-day cleared arrivals   = 135 x 0.85 = ~115
Fast-lane minutes needed    = 115 x 4  = 460 minutes of desk time
Exceptions (15%)            = 20 x 20   = 400 minutes of desk time
Over an 8-hour (480-min) day: ~2 fast-lane desks + 1 exceptions desk

The lesson in the arithmetic is that exceptions dominate. A resident who is not cleared consumes five times the desk time of one who is. Every resident you move from exceptions to fast lane before arrivals day is worth five arrivals-day residents of saved capacity. That is why the pipeline work pays off, and why the metric to obsess over in the run-up is the percentage of the cohort fully cleared, not the percentage signed.

What to measure during intake

  • Cleared rate: share of the arriving cohort past every gate. Your single leading indicator.
  • Gate bottleneck: which gate holds the most residents. Tells you where to deploy staff this week.
  • Peak-day load: arrivals booked on your busiest day, so you can cap and redistribute before it hits.
  • No-show rate: booked arrivals who never came, driving your release-to-clearing decisions.
  • Cash cleared vs committed: money actually settled against money promised.

Where a purpose-built PMS earns its keep

Every gate in this playbook is a data field, and every report is a filter across those fields. That is precisely the work a spreadsheet does badly at volume: it cannot chase a signature, remind a guarantor, reconcile a payment, or tell you at a glance that 180 residents are stuck at the compliance gate with nine days to go. A system built for student housing runs the pipeline as a workflow, with the booking and onboarding and inventory and occupancy views doing the tracking so your team can do the chasing.

JumboTiger is built for exactly this shape of operation. See how it handles the wider student-housing workflow on the PBSA software and student housing software pages, or compare the field on the best PBSA software roundup. If your September beds are partly filled through a university, read the companion post on how university nomination agreements work, which changes who you onboard and who you bill.

Mayank Pokharna profile picture

Written by

Mayank Pokharna

Founder, JumboTiger

Mayank has been building software for shared and rental living operators since 2018. He has shipped PMS deployments for coliving, BTR, and PBSA operators across the UK, EU, and India. He writes about per-bed inventory, deployment economics, and the operator-led PMS thesis.