Full residences, fair allocation, and a bed count you can trust.
Housing and hostel management on the same platform as the student record: book online, allocate on rules, price by the bed, and see occupancy live. Not a housing system you integrate, a housing module that already knows the student.
The problem
Housing runs on a spreadsheet that is wrong by lunchtime.
Allocation season is a queue outside the warden's office, a printed room list and a spreadsheet edited by different people. Beds get promised twice. A student pays at the counter and the receipt lives in a drawer. Soon, nobody can say how many beds are actually free.
Three failures repeat. Inventory is counted, not tracked, so availability is a guess. Allocation is discretionary, so students believe the outcome depends on who they know. And money is detached from the bed, so premium rates, mid-term moves and refunds are reconciled by hand at term end.
What changes
Four outcomes, and the mechanism behind each one.
Housing is judged on whether beds are full, whether students accept how they were allocated, whether the money lands, and whether the buildings stay livable. Features are underneath, named, so you can check the claim.
Beds full, and the count is true.
Every booking, hold, cancellation and checkout updates inventory at bed level as it happens, so the number on the dashboard is the number in the building. Wait-listed students are offered a freed bed automatically.
Allocation students accept.
Preferences, roommate requests, gender rules and priority categories are weighed by the engine, conflicts are blocked before they happen, and every manual override carries a reason and an audit trail. The snapshot is archived.
The fee follows the bed.
Rates are configured per room type and tagged per bed, so premiums for a window or a lower bunk are priced correctly, mid-term moves prorate themselves, and checkout settles dues and deposits before clearance is granted.
Buildings that stay livable.
Students raise issues from their phone with photos, tickets route to technicians on SLA, rooms can be blocked for repair with the work order attached, and scheduled inspections score hygiene and safety on the record.
The operating model
Model the building once. Everything else reads it.
These choices turn housing from an annual scramble into an operating layer: the residence inventory as structured data, allocation as a rule set, money attached to the bed, and residence life recorded rather than remembered.
The residence inventory is live data, not a floor plan on a wall
Buildings, floors, wings, rooms, beds and cot types are configured with attributes: capacity, AC, attached bath, accessibility, hostel type. Versioning tracks renovations and closures, and bulk upload handles the initial setup.
Allocation is a rule set you can defend
Preference weighting, roommate requests, gender and programme rules, priority categories and first-come order are applied by the engine. Approvals are digitally signed and timestamped, and overrides stay possible but recorded.
Price lives on the bed
Fee matrices by room type, bed level tagging, scheduled revisions with effective dates and a historical archive mean billing, proration and refunds come from configuration rather than a manual calculation.
Residence life is on the record
Maintenance, inspections, complaints, guardian details and food preferences are part of the housing record, so a pattern in one block is visible and a serious complaint can escalate into the conduct process.
What it does
What the housing team needs, in one place.
Every capability here maps to something a chief warden or a bursar can be held to. Pick an outcome to see exactly what sits inside it.
A booking journey a student can finish on a phone, in one sitting.
- Online housing catalog with photos and amenity lists
- Filters by location, cost range, room type and facilities
- Real-time availability with waiting list status
- Booking wizard for a single bed or a whole room
- Preference tags such as quiet floor, AC or double sharing
- Policies and house rules shown before confirmation
- Booking reference confirmed by email
The engine decides on stated rules, and the decision is on record.
- Smart allocation across preferences, roommate requests and gender rules
- Weighting that balances first-come order with priority categories
- Real-time conflict checks that prevent double allocation
- Provisional allocation emails for student confirmation
- Manual override and room swap with full audit trail
- Waiting list that moves automatically on cancellation
- Roommate recommendation from a lifestyle and study-habit survey
- Multi-level requisition approval with digital signatures and timestamps
Configured rates, collected in flow, reconciled without a spreadsheet.
- Room type fee matrix by semester or month
- Variable pricing by wing or occupancy level
- Bed wise fee tagging for bunk, window or premium beds
- Automatic proration when a student changes bed mid-term
- Early-bird and scholarship discounts, with scheduled revisions
- Payment gateway with full or installment payment and instant receipts
- Failed payment retry and alert workflows
Residence life recorded as it happens, from a leaking tap to a serious complaint.
- Student maintenance requests from the mobile app, with photos
- SLA priority and automatic assignment to a technician
- Room hold or block for renovation, with work order and reopening date
- Scheduled maintenance and health inspections with digital checklists
- Inspection scoring that sets the next inspection date
- Complaint management with an anonymous option and mediation notes
- Escalation into the student conduct process where warranted
What is full, what it earns, and what next term will need.
- Role-based dashboards for occupancy and revenue
- Heatmaps of demand by room type and season
- Churn analytics on mid-term move-outs
- Maintenance cost against rent, per building
- Drill down by hostel, floor or room type
- Housing history per student, exportable as PDF for visa or scholarship proof
- PDF and Excel exports for management review and audit
Inside the product
From browsing a room to handing back the key.
This is the application, not a diagram. Move through the surfaces a housing office works in: booking, allocation, fees, maintenance, inspections and complaints, and the occupancy dashboard.
| Student | Matched on | Bed | Status |
|---|---|---|---|
| A. Rahman | Quiet floor, AC, roommate requestBoth preferences met | B-214 lower | Confirmed |
| M. Osei | Priority category, first yearRule weighting | B-118 window | Confirmed |
| L. Fernandes | Lifestyle survey matchRoommate score 0.88 | C-207 upper | Awaiting student |
| S. Kaur | Manual swap by wardenReason recorded, logged | B-302 lower | Override |
| Bed | Rate basis | Term fee | Payment |
|---|---|---|---|
| B-214 lower | Double sharing, AC, lower bunk premiumBed wise tag | 42,000 | Paid in full |
| B-118 window | Double sharing, window premiumFee matrix | 43,500 | Installment 1 of 3 |
| C-207 upper | Dormitory, non ACFee matrix | 26,000 | Awaiting payment |
| B-302 lower | Mid-term move, prorated 6 weeksAutomatic proration | 11,600 | Adjusted |
Lifecycle or product
The lifecycle is the operating model. This is the product that runs it.
The lifecycle and the product do different jobs. Read the lifecycle to understand how housing sits inside the student journey; read this page to see the application a housing office opens on Monday.
One of the institutional lifecycles: the governed model for the student record, support, standing and services.
The application that runs the residences: catalog, allocation, fees, maintenance, inspections and checkout.
How do housing, billing, conduct and the student record stay consistent for one student?
What do wardens, housing officers and students actually see and do in each screen?
The full student success model, including records, support, retention and standing.
Booking to clearance: estate master data, allocation, bed wise fees, residence life and reporting.
You are designing the operating model or comparing architectures. See the lifecycle →
You are replacing a hostel register and a fees spreadsheet. See inside the product →
Also part of the operating system
Student Housing is also part of Student Success & Records.
Connect it and housing stops being an island: fees reach the student account, residents match enrolment, complaints can escalate into conduct, and the stay is on the record when a student needs it proved.
Built for every role
One inventory. Five people who need different things from it.
Runs allocation season from a screen instead of a queue, and can explain any allocation that gets questioned.
Sees free beds, holds and wait list in one board, so a cancellation is offered in minutes, not next week.
Housing dues sit on the student account, prorated and receipted, with deposits and refunds tracked.
Tickets, holds and inspection scores give a maintenance case built on record, not on complaints.
Books a bed on a phone, knows the rules and the rate, and raises an issue without finding the warden.
What teams say about running student services on Creatrix.
Creatrix Campus has helped us centralise all student information in one reliable and intuitive system, improving efficiency and reducing errors. We use it to manage student data, schedule sessions, and automatically generate transcripts, which has simplified many of our academic processes.
What I like best is its user-friendly and intuitive design. It makes managing tasks, attendance and academics seamless and efficient.
Go deeper
From the Creatrix library.
Blogs, whitepapers and case studies for the people who run the residences: chief wardens, housing officers, bursars and facilities teams.
Frequently asked
Plain answers about housing.
Can students book a bed themselves?
Yes. The catalog shows photos, amenities and live availability, with filters for location, cost, room type and facilities.
A booking wizard lets a student reserve a single bed or a whole room, with house rules visible before confirmation and a booking reference emailed on success.
How does room allocation work?
The engine weighs stated preferences, roommate requests, gender rules and priority categories against first-come order, and real-time conflict checks stop a bed being allocated twice.
Wardens can still override or swap, but the reason is recorded and the allocation snapshot is archived for compliance.
Can two beds in the same room cost different amounts?
Yes. Rates are configured per room type and can be tagged per bed, so a lower bunk or a window bed carries its own premium. A mid-term bed change prorates automatically, and the bed tag carries into checkout.
How are maintenance issues handled?
A student raises a request from the app with photos. The ticket takes an SLA priority, auto assigns to a technician, and moves through open, in progress and fixed.
A room can be blocked for repair with the work order and reopening date attached, which hides it from booking until it is ready.
What happens at checkout?
Checkout triggers fee settlement, deposit refund steps and a room inspection checklist. Outstanding fines or damages block clearance until paid, and the bed returns to inventory the moment clearance is approved.
Can we run Student Housing on its own?
Yes. It runs standalone, and it connects into the Academic Operating System when you are ready: your call on when to expand.
What can leadership see?
Role-based dashboards cover occupancy and revenue, heatmaps show demand by room type and season, churn analytics track mid-term move-outs, and maintenance cost against rent is reported per building. Everything exports to PDF or Excel.
BRING YOUR HARDEST ALLOCATION SEASON
Bring one block and one term. We will fill it live.
A tailored proof session uses your buildings, room types, fee matrix and allocation rules, not a canned demo. Leave with a named, dated next step.