Three things. A public website for your property where guests book rooms and order food, on a Rooms24 subdomain until you point your own domain at it. An admin panel where your staff run rooms, rates, reservations, folios, menus, inventory, payroll and reports. And, once you opt in, a listing on the map in the Rooms24 app. All three read the same records, so a booking taken on your site is the one your front desk sees.

It is the same record. Your site reads live availability and rate plans out of your own database, and a completed booking is written straight back to it — the reservation your staff see is the one the guest made, not a copy synced across from somewhere else. That is also why a room sold at the desk disappears from the site immediately.

Your property gets its own PostgreSQL database, created when your registration is approved. Nobody else's data is in it, so a mistake in our code cannot show your guest list to another hotel. It also means your data can be exported or deleted as one unit rather than picked out of shared tables.

Yes, and it is the point of the roles module. Every route in the system denies by default and every permission is named, so you decide whether a receptionist can void a charge or open a till. Each staff member gets their own account — sharing one breaks both the audit trail and the staff count on your plan.

Cards anywhere in the world through Stripe, for overseas guests, corporate accounts and your own subscription. Plus local methods in the markets we support them — eSewa, Khalti and Fonepay in Nepal today, with more added as properties ask for them. Each provider is switched on per property, and guest payments taken at the desk are recorded against the folio whatever the method, including cash.