Expertise
Move-in week: getting your building's WiFi ready for arrivals day
No week tests a building's network like move-in week. A student accommodation block sits near empty all summer, then fills in a single weekend. Every arriving resident brings a bag of devices, and every one of those devices tries to get online within hours of the keys being handed over. The impression the WiFi makes that weekend is the one that sticks. It shapes the reviews, the complaints your team fields all term, and whether residents rebook.
The good news is that a bad arrivals day is almost always a preparation failure, not bad luck. Here is how we prepare the buildings we manage, laid out as a countdown you can run against your own property.
What actually happens to the network on arrivals day
It helps to be precise about the problem, because it is not just "lots of internet use". The heaviest strain on arrivals day is the joining itself. Hundreds of phones, laptops, consoles, smart TVs and speakers all try to find the network, get an address and authenticate within the same few hours. That is a load profile the building never sees again until next September, and it stresses parts of the network that normal browsing never touches.
Then comes the traffic. Consoles pull day-one updates the moment they are plugged in. Phones restore cloud backups. Parents make video calls home from the car park. A network that performed beautifully in July, with a handful of staff devices on it, tells you almost nothing about how it behaves under that first evening. The design has to assume the worst hour of the worst day: every room occupied and every device setting itself up at once.
Common areas get hit hardest of all. On arrivals day the lobby, lifts and shared kitchens hold far more people than on any normal Tuesday. If the access points in those spaces were specified for typical occupancy, they will struggle at exactly the moment the building is full of first impressions.
Six weeks out: capacity, hardware and the upstream link
Everything with a lead time belongs here, while there is still time to act on what you find.
Confirm the upstream connection. The building's internet feed is the one part of the network no clever WiFi design can compensate for. Check it is delivering what the contract says, and check what the contract says is actually enough for a full building. If it needs upgrading, providers work in weeks, not days.
Audit every access point. All of them up, on the right channel plan, and cabled to the switch port the design says they are. Firmware updates happen now, in the quiet, never in September. A change that goes wrong six weeks out is an inconvenience. The same change going wrong on arrivals day is a headline.
Look again at the common areas. If last September brought complaints from the lobby or shared kitchens, the fix is more or better-placed access points, and summer is when that work can happen without disturbing anyone.
Order spares. Access points and switches fail on no particular schedule, and arrivals weekend is a bad time to discover a lead time. Replacement hardware on site, plus someone who can swap it, turns a potential weekend-long outage into a short one.
If the network has never been properly measured, this is also the moment for a site survey. Guessing at coverage in a full building is how dead zones survive year after year.
Two weeks out: test like a resident, not like an engineer
With the building in its finished state, verify the experience residents will actually have. Walk the building and confirm coverage in every room, not a sample of rooms. Signal readings on a survey app are useful, but the test that matters is simpler: stand where the desk and bed are, and use the network.
Then test the thing residents touch first: joining. Sit in a room, connect a phone the way a student would, and time how long it takes to get from unboxing to online. Do the same with a games console and a smart TV, because those are the devices that generate the awkward tickets. If onboarding needs a password taped to a noticeboard or a call to reception, fix that before the weekend, not after.
Finally, check the paperwork. Whatever goes in the welcome pack (network name, joining instructions, who to contact when something does not work) should be tested word for word by someone who has never seen it before. A wrong support number printed a thousand times is a very cheap mistake to catch in advance.
Arrivals weekend: everyone knows who does what
Here is the part operators underestimate. On move-in weekend your site team is the busiest it will be all year. Keys, parking, deliveries, parents. If WiFi questions land on the same people, both jobs suffer. Residents queue behind luggage trolleys to report a connection problem, and your staff spend arrivals day doing first-line IT.
The fix is routing. Residents should have a direct line to the people who run the network. In our managed buildings, residents contact AirGen, not the site team, so a connection question on arrivals day goes straight to an engineer who can see the network and fix the problem while your staff get on with moving people in. That is exactly what our tenant internet support service exists for, and move-in week is when it earns its keep most visibly.
The network side should not be passive either. Someone who understands the network should be watching it live through the weekend: client counts per access point, the upstream link, the systems handing out addresses. Watched closely, monitoring turns arrivals day problems into things that get fixed before most residents notice them.
The arrivals day checklist
- Upstream connection tested and confirmed sufficient for a full building
- Every access point up, on the right channel plan, on current firmware
- Common area coverage reviewed against arrivals-day crowds, not typical occupancy
- Spare hardware on site, with someone able to fit it
- Coverage confirmed in every room, from where residents actually sit
- Joining tested on a phone, a console and a smart TV, timed from unboxing to online
- Welcome pack instructions and support contact details verified word for word
- Site team briefed on one line: where WiFi questions go
- An engineer watching the network live through the weekend
The first two weeks: fix the small stuff before it spreads
The first fortnight of term surfaces the issues no test can. The resident with an unusual device. The room where a wardrobe placement muffles the signal. The console that refuses to join. None of these shows up on a quiet-building walk test, and each is small on its own. Left alone, they become the building's WiFi reputation.
So the preparation does not end when the last car leaves. Watch the network closely through those weeks and fix the small problems before they become tickets. The goal is WiFi that nobody mentions. When we brought Graduation House online, residents were connected from the day they moved in, and that is what a well-prepared arrivals day looks like: busy for the network, uneventful for everyone else.
Move-in week WiFi questions, answered
When should we start getting building WiFi ready for September?
Six weeks before arrivals is comfortable. Capacity checks, firmware updates and hardware fixes belong early, because they carry lead times. Room-by-room testing belongs in the final fortnight, once the building is in its finished state. If the network has known problems, or has never been surveyed, start sooner.
Why does building WiFi struggle on move-in day when it worked fine all summer?
Because summer proves nothing. An empty building puts almost no load on the network. On arrivals day, every resident tries to connect every device they own within hours of getting keys, and the joining itself (hundreds of devices associating, getting addresses and authenticating at once) stresses a network in ways normal use never does. A network specified for typical occupancy can pass every summer test and still fail its first real weekend.
Should our site team handle WiFi questions during move-in?
No. Move-in weekend is the busiest your site team will be all year, and they are not network engineers. WiFi questions should route directly to the people who run the network, who can see it and fix it. That is what a dedicated tenant support service is for.