The front desk, the restaurant, housekeeping, banquets, the channel manager, central reservations, the sales desk and the books are not eight products here. They are 12 sets of screens over one database — so the bill a guest runs up at dinner is on their folio before they reach reception, and the company that booked them is the company the invoice is raised to.
Built inside a working hotel group — on the floor, at the desk. Nothing to install: a browser and a hotel ID.
The real screen, on a demo hotel. Click to enlarge.
A person comes in through a door, works on a product's screens, and every screen reads and writes the same database. The outside world — the OTAs, the payment providers, the accountant, the tax portal — is connected to that database once, not to each product.
Why one database matters → · Every integration → · Who may see what →
Every step below is a different product. Not one of them sends anything to another — they are all looking at the same record.
The channel manager applies it to the chart in the same request that accepted it. The room count goes back out to every other channel the moment it changes.
On the hotel’s own booking page, at the hotel’s own rate, with no commission — or through the central desk, which sees every hotel in the group.
The registration card, the room and the folio are one record. The guest is the same guest the CRM knows, at every hotel in the group.
The restaurant closes the table to the room, and the bill is on the folio in the same transaction — before the guest is back at reception.
The GST invoice is raised to the company that booked the stay, with the dinner on it, and the bill closes at zero.
The attendant works one tap per step on a phone; the supervisor passes the room; the room keeps its own story of everything that happened to it.
At the hour the hotel chose, it posts each night’s room charge, marks the no-shows, refuses a day that has not ended — and closes into the books.
Every hotel a row, before breakfast. The day’s journal is already in the ledger, and the accountant gets it in Tally, Zoho or QuickBooks once.
12 of the 12 are live on working hotels today. Each is a heading with its own pages under it — 141 in all — and each page names the screen it is about. What none of them is, is a separate database.
The screen a hotel lives on. Rooms down the side, nights across the top, every booking drawn as a bar, the price and the rules above it. Check-in, the folio, the GST invoice, the registration card and check-out are all one record from the moment the booking is taken — the restaurant bill is on the folio before the guest reaches reception, and the company that booked them is the company the invoice is raised to.
A hotel sets its own price, on one form, for every plan at once. Seasons, extra adults and children, the gap between room-only and breakfast, minimum stays and stop-sells — all written once and carried to the chart, the booking page and the channel manager. The tax slab follows the tariff by law, so the system reads the rate and picks the slab, and the rate typed at booking is the rate the guest is charged.
The connection to the OTAs is part of the product, not a second subscription. Rates, inventory and restrictions go out the moment they change; bookings, modifications and cancellations come back and land on the chart in the same request. Every push and every inbound call is kept with what was sent and what came back, so a dispute with a channel is settled by reading, not by remembering. The AxisRooms connection has carried real bookings from Go-MMT, Booking.com, Agoda, Expedia and Cleartrip into two working hotels since 10 September 2026.
A guest books on the hotel's own page, at the hotel's own rates, with no commission on the price and a payment link they can settle from before they arrive. Inside the group, one desk sees what every hotel can sell — including the ones that cannot, and why — and books into any of them without leaving the screen. Every hotel keeps its own business date, and the central desk respects it.
Nobody imports anything. Every guest, company and travel agent the hotels have ever sold to is already here, with stays, room nights, ADR and what is still owed beside the name — because the CRM reads the same record the front desk writes. Enquiries sit on a board weighted by stage, every call and message is on one timeline, and outreach respects do-not-email absolutely.
Tables, menus, KOTs that print per kitchen station, bills that split and tables that merge. A bill settles at the counter or goes to the room — and when it goes to the room it is on the folio, not in a second system. Sells on its own to a restaurant with no hotel, and to a hotel group with an outlet in each.
Nine stages, all shipped. Every room keeps a story of everything that happened to it; every clean has a kind, a checklist and a cost; attendants get one tap per step on a phone that works without a signal; supervisors pass rooms on an inspection sheet; guest requests carry a clock; the day is planned from the bookings, shared out fairly and handed over in writing; and by the ninth stage the system predicts how long each room will take and recommends the move.
The day rolls by itself at the hour the hotel sets, posts every night's room charge, marks the no-shows and tells the channel, and refuses to close a day that has not ended. The closed day can be read back as one statement, every log the system keeps is read on one page, and the owner is sent one sheet for the whole estate before breakfast.
Not an export to somebody else's ledger — a set of books the hotel keeps. The night audit closes into a double-entry general ledger per legal entity; receivables, payables, TDS, bank, gateway and OTA settlements, GST returns and e-invoicing all read the same journals; and the accountant who lives in Tally, Zoho or QuickBooks gets the day there once, never twice.
Every report reads the live record and says when it cannot. The manager flash, the occupancy heatmap for every hotel the reader may see, the revenue report bill by bill, the channel report both ways, the night audit statement and the owner's morning sheet — all view-only, all readable by anyone who can log in, several delivered to an inbox on a schedule.
A hall is a room that sells by the hour. The diary per venue, the banquet event order, charges onto the same folio as the rooms, and — in the books — an event that is a ledger of its own, so a wedding booked in March and billed in November can say whether it made money.
What sits under every module. One database with row-level security, a hotel ID that is the first thing typed at sign-in, roles that reach down to the button, a group that can hold twenty hotels or one restaurant, support access that is granted and time-boxed, a manual that ships with every screen, and refusals written for the person at the desk. The part of the product a demo never shows and a second year depends on.
Every integration between two systems is a place where a guest becomes two guests and a bill becomes two bills. The way to not have that problem is to not have two systems.
Not an export, not a midnight sync, not a matching job somebody runs on Monday. The POS and the folio are the same row.
The desk writes the record; the CRM reads it; housekeeping remembers the hard pillow. Nobody imports anything.
The day's journal is written by the audit and the outlet's day end, and the accountant gets it in Tally, Zoho or QuickBooks once.
A module cannot be swapped for a competitor's — the POS is not replaceable by somebody else's POS. That is what buys the rest.
The first row is read from the live database each time this site is published; the second is counted in the repository, dated. Where each one comes from.
The owner of the group runs its hotels on this. What he says to the engineers is quoted in the change that did it, and the pages here quote him back.
“You can show me it has three people — shall we allow or shall we not? If I say allow, then do it. Why are you making someone’s life difficult? Keep a log.”
“Treat admin as a super boss. He can do anything — just keep a log of what they did and what date.”
“When the guest has paid the OTA and the OTA is supposed to pay us, show the amount paid and balance zero — to be collected from the OTA. Otherwise the front office will start asking guests again, and they get frustrated.”
“If reports are view only, then allow everyone who logged in to see reports.”
No. The desk, the restaurant counter, the central desk and the sales team each open an address in a browser and sign in with the hotel ID, an email and a password. Housekeeping works from a phone.
Yes. Each module is switched on its own: a restaurant with no rooms runs the POS and never sees a booking chart; a resort with no outlet never sees a KOT. What none of them is, is a separate database. The restaurant on its own →
Your logins, and only what their role allows — the database itself enforces it, not just the screen. The people who run the platform see nothing in a hotel until that hotel grants them access, for a limited time, and the visit is logged. The hotel ID, and who may see what →
The night audit closes the day into a double-entry ledger per legal entity. The accountant gets the day in Tally, Zoho Books or QuickBooks once — or keeps the books here. Accounting →
One price per room, per month, and every module on this site is in it. A group pays per room across the group on one invoice; a restaurant with no rooms pays per outlet. Pricing →
A door-lock interface, WhatsApp as a channel, and metasearch — each will be a module when a hotel needs it. Everything built but not yet on a customer's hotel is marked Next, so the pages marked Live can be believed. What is next →