Case study, client anonymised
500 students onboarded in 4 days: student housing at scale
2,000+ beds let through university partnerships. An intake that used to take three weeks of non-stop work now clears in four days.
At a glance
500+
Students onboarded per intake
4 days
Intake processing (was 3 weeks)
100%
Access control automation
0
Security gaps from deactivation delays
The client
Asia-Pacific. Named details withheld at the client’s request.
A student housing provider operating in the Asia-Pacific region, managing 2,000+ beds across university partnerships.
the portfolio is concentrated around a small number of campuses, and the majority of beds are filled through university housing offices rather than direct-to-student marketing. Their operating year is shaped by intake. for most of the year occupancy is stable and the work is routine; then, over a few weeks, several hundred students arrive at once. Everything in this study is about that few weeks.
the operator runs two major intakes a year.
Intake week, done by hand
This operator's problem was not demand and it was not occupancy. It was throughput during their busiest period.
Processing 500 students took the team three weeks of non-stop work. That is three weeks in which the same people were also expected to answer partner universities, assign rooms and get residents through the door on their arrival date.
Intake. the housing offices at partner universities begin sending student lists a few weeks before term starts, and the team works through them by hand. Somewhere in the middle of that, a partner university emails to ask what is still available for a student arriving next week. Someone stops what they are doing, checks, and replies. by the time the reply lands the room in question has often already been assigned to someone else, so the exchange starts again. Multiply that across every partner, every week of intake, while 500 arrivals are being processed in parallel.
Intake was the bottleneck, not demand
500+ students per intake, processed over three weeks of non-stop work. the constraint was not beds and it was not applications; it was the number of students the team could physically move through onboarding per day. this capped how many partner universities the operator could take on, regardless of how much inventory they had.
University housing offices had to email for every availability check
Partner universities had no way to see inventory themselves, so every availability question became an email chain. each one required a person to open the inventory record, confirm what was free, and write back, and each round trip took hours during the period when hours were most expensive. availability quoted in an email is stale the moment it is sent, so partners were making placement decisions against numbers that had already changed.
Access control drifted out of sync with resident status
When a resident moved out, their access had to be deactivated by hand. during intake and turnover, when the team was already saturated, that step was the one most likely to slip, leaving a former resident with working credentials for days after their tenancy ended. In a building full of students, that is a safeguarding exposure, not just an administrative one.
No single live view of inventory
room availability, assignments and pending arrivals were tracked separately from the systems partners and staff were working from, so the answer to 'what is free' depended on who you asked and when. double assignments during peak intake were a recurring risk.
What JumboTiger built
The build covered five modules: B2B Partners and Owner Management, the Integrations Hub, Inventory and Occupancy Management, Booking and Onboarding, and Payments and Rent Collection.
Three of them carried the intake problem: bulk onboarding, a self-serve portal for university partners, and access control wired to resident status. the modules were deployed together ahead of an intake cycle rather than sequentially, so the first live test of the system was a real intake.
Bulk intake that processes 500 students in days, not weeks
The automated intake workflow transformed their busiest period from chaos to clockwork.
500+ students onboarded per intake, in 4 days against 3 weeks previously
student cohorts are imported in bulk from the lists partner universities supply, rather than keyed in one record at a time
each student receives their own onboarding link and completes documents, agreement and payment details themselves, so the work happens in parallel across 500 students instead of sequentially through one team
room assignment runs against live inventory, with gender, campus proximity and room-type preferences applied automatically
the team's role changed from doing the onboarding to clearing exceptions, which is what compresses three weeks into four days
University partner portals that eliminated email chains
University housing offices now self-serve instead of emailing for every availability check.
Partner universities check availability themselves instead of emailing to ask
each partner university gets its own login showing live availability and pricing for the properties relevant to its students
housing office staff can place a student directly, without waiting on a reply from the operator
because the portal reads live inventory, partners are never working from an availability figure that has already changed
placements made by partners flow straight into the same intake workflow as direct bookings, with no re-keying
Access control that eliminates security gaps
SALTO integration ensures access is always in sync with resident status.
100% of access control is automated, and deactivation delays no longer produce security gaps
access credentials are issued automatically when a resident's onboarding completes, so nobody needs to be on site to hand over a key on arrival day
credentials are revoked automatically on the tenancy end date, which is what removes the manual deactivation step that used to be missed
temporary, time-limited access can be issued for maintenance and cleaning staff without creating a permanent credential
every access event is logged, which gives the operator an audit trail it did not previously have
The results
| Metric | Before | After |
|---|---|---|
Intake processing time | 3 weeks | 4 days |
Students onboarded per intake | the same 500+, but spread across three weeks | 500+ |
Access control | Manual deactivation | 100% automated |
Security gaps from deactivation delays | credentials stayed live for days after move-out during busy periods | Zero |
Partner availability checks | Email chain, one per request | Self-serve partner portal |
Partner response time | hours, and slower during intake | instant, self-serve |
Access credential issue on arrival | manual handover, on site | automatic on onboarding completion |
Live inventory view for partners | None | live availability per partner university |
The busiest period of the year went from three weeks of non-stop work to four days. University partners stopped emailing to ask what was available. Access control is fully automated and in sync with resident status, and deactivation delays no longer leave credentials live. the operator has not supplied staff-hours or revenue figures, so this study makes no financial claim.
The takeaway
Student housing does not have an average week. It has intake, and then it has everything else. A system sized for the average week will fail in the only weeks that decide whether the year works. The gain here was not a percentage improvement spread evenly across the year, it was removing a hard ceiling from the few weeks that set the ceiling for everything else. with intake no longer the constraint, the operator can add partner universities without adding intake capacity, which is the actual growth unlock.
Want a system built around how you operate?
Book a 30-minute call. We will be honest about whether a custom build is the right answer for your operation.