Purpose built student accommodation runs on two very different systems. One holds bookings, tenancies, rent and the student record. The other decides which rooms are cleaned today, which maintenance job is late, what condition a room was in when the student arrived, and what gets deducted when they leave. The second one is operations software, and in most UK and Irish PBSA schemes it is still a spreadsheet.
This guide sets out what PBSA operations software should do, how it sits alongside the booking system you already run, and what to check before you buy.
StarRez, Kinetic, Mercury and the rest are systems of record. They know who holds bed 214, what they owe, when their tenancy starts and ends, and what was signed. That is exactly what they should do, and no operations tool should try to replace them.
Operations software is the system of action. It knows that bed 214 is on today's turnaround list, that its shower has been reported twice this term, and that the mattress was already marked at check in. It reads occupancy and tenancy dates from whatever you already run, including a reservations spreadsheet, and does not ask finance to migrate anything.
In PBSA the cleaning workload is not evenly spread. Weekly communal and kitchen rotas run all year, then the summer turnaround compresses a full portfolio of room cleans into a few weeks before the September intake. Planning that in a spreadsheet is where most schemes lose control, because a spreadsheet cannot tell you which flats were actually completed by four o'clock.
Look for automatic rota generation from occupancy and departure dates, live completion status per room, photo sign off on communal areas, and the ability to reassign a cleaner's list mid shift without rebuilding the plan.
Reactive maintenance and scheduled compliance work belong in the same queue, because they compete for the same technicians. Fire door checks, emergency lighting tests, legionella flushing and PAT testing should be generated on a schedule with a record of who completed each one and when, in a form you can hand to a regulator without assembling it first.
Reactive tickets should carry the building, flat, room and asset, a photo, and a priority band with a published response target. Repeat faults against the same asset are the signal that tells you to replace rather than repair.
A deduction only survives a dispute if the evidence was created at the start of the tenancy. That means a dated check in record with photographs per room and per asset, confirmed by the student, and the identical template used again at check out so the two records can be compared line by line.
Prices should be agreed in advance on a published asset list, so a charge is a fact rather than a negotiation. Deposit schemes decide on the evidence in front of them, which is why the paired photo record matters more than the wording of the notice. Our student check out checklist and the guide to billing damage charges back to students set out the full process.
Students will not download an app for a broken kettle. Reporting has to work from a QR code in the flat that opens in the phone browser, attaches a photo, and knows the building, flat and asset before the student writes anything.
The return on this is not just convenience. Issues get reported early, when they are cheap, rather than discovered at turnaround when they are expensive and impossible to charge to anyone. It also gives your team a clean count of how many issues each building actually generates.
A regional manager covering eight schemes needs one view: rooms ready by building, open jobs by age, compliance checks due, and damage recovered against target. If that view requires an analyst to assemble it each Monday, it will not be looked at.
Expect pricing per bed per month with everything included, rather than modules that are quoted separately once you have committed. Campus Pilot runs cleaning rotas, maintenance, compliance checks, inspections, damage recovery and the student app on that basis, alongside your existing booking system rather than in place of it. The Social Hub uses it across roughly 15,000 hybrid rooms. See every feature, or book a demo and we will run it on your own scheme.
It is the system that runs the day to day operation of purpose built student accommodation: cleaning rotas, maintenance and compliance jobs, check in and check out inspections, damage recovery and student requests. It sits alongside the booking or tenancy system, which holds the student record and the money, and handles everything that happens to the building and the staff.
No. Those systems remain the record for bookings, tenancies and rent. Operations software reads occupancy and departure dates from them and manages the work that follows. Most operators run both, and the integration is a read of who is in which bed and when they leave rather than a migration of anything.
That works. Campus Pilot connects to a live Google Sheet or Excel file in the same way it connects to a PMS, so schemes without a booking system are not excluded. The rotas and turnaround lists are generated from whatever occupancy data you already maintain.
Per bed per month, and you should expect everything to be included rather than paying separately for cleaning, maintenance and the student app. Ask specifically whether inspections, damage recovery and reporting are in the base price, because module based pricing is where PBSA quotes usually grow after signature.
A live walkthrough of Campus Pilot on your own buildings, reservations and checklists. Live within a week.
Book a demo →