Skip to content
Operations / Hostels & PG

Run the stay. Collect the rent. Stop chasing the follow-up.

Property → Building → Floor → Room → Bed → Tenant → Stay → Invoice → Payment → Receipt. Hostel operations connect physical inventory to communication — so the team follows through without retyping between tools.

Live — standalone workspace. One platform foundation. Bed/stay/invoice data stays product-owned.

Operational hierarchy — typography carries it, not icons
01
Property
Building host
02
Room
Floor → Room
03
Bed
Inventory unit
04
Tenant
Resident record
05
Stay
ACTIVE unique per tenant/bed
06
Invoice
INV- · stay + month unique
07
Payment
PAY- · Razorpay server amount
WhatsApp templates · idempotent metadata · receipts → timeline
Problem

Beds are occupied. Rent is due. Someone still has to chase it.

Hostel work is physical inventory plus human follow-through. When that follow-through lives on a phone, rent slips.

01

Bed allocation lives in a sheet

Room → bed → tenant mapped manually. Double bookings happen when two people update the same sheet.

02

Invoices made, not followed up

Invoices generated, but reminders depend on memory. Late fees applied inconsistently.

03

Tenant has no place to see what is due

Residents call the warden to ask the same invoice question the system already knows.

Operational flow

Property → Bed → Stay → Invoice → Payment

The workflow the page is visually about — no stock hostel photography, no house icon wallpaper.

01

Property & building

Property → Building → Floor → Room → Bed hierarchy created once.

02

Tenant & stay

Tenant record → stay ACTIVE (unique per tenant/bed).

03

Invoice

INV- generated, stay + month uniqueness enforced.

04

Payment

Razorpay order — server-side amount calc, idempotency, receipt.

05

Follow-up

WhatsApp reminder + tenant portal — resident sees due, pays, gets receipt.

Verified: Stay ACTIVE unique per tenant/bed, Invoice stay+month unique, Payment PAY- with Razorpay idempotency, receipts to timeline.

What’s live

Verified modules — reused, not rebuilt.

Each group is editorial, not a 12-icon grid.

Property

Property hierarchy

  • Property → Building → Floor → Room → Bed
  • Bed allocation with availability

Stay

Tenant & stay

  • Tenant resident record (user=null supported)
  • Stay ACTIVE unique per tenant/bed

Finance

Invoices → Payments → Receipts

  • Invoice INV- · Payment PAY- · Razorpay server amount
  • Receipts, stay+month uniqueness

Tenant portal

Resident experience — existing

  • Dashboard, Stay, Invoices, Payments
  • Complaints, Notices, Documents, Leaves
  • Housekeeping, Meals, Visitors where configured

Standalone workspace on RapidRoot Core — identity/orgs/billing shared, bed/stay/invoice data product-owned. No unified cross-product customer graph claimed.

Communication connection

WhatsApp helps the operation follow through.

Not a second WhatsApp tool — the same RapidRoot messaging that sends rent reminders and receipts.

Reminders

Rent due, overdue, receipt — template WhatsApp via RapidRoot messaging, idempotent.

Tenant reads

Resident sees due in portal and on WhatsApp — no call to warden for what system already knows.

Team stays in sync

Operational events (invoice generated, payment received) drive the next WhatsApp template — reused, not rebuilt.

One platform foundation. Different operational workspaces — not one database. See Platform.

Live — standalone workspaceHostels / PG — standalone product on same platform foundation.

See hostel operations live.

Guided pilot on your hostel data — beds, stays and collections in one timeline.