The platform Live

One database, not five that talk to each other

Every integration between two systems is a place where a guest becomes two guests and a bill becomes two bills. The way not to have that problem is not to have two systems.

Most hotel software is a PMS with things bolted to it: a POS from one vendor, a channel manager from another, a CRM from a third, housekeeping on a tablet app, accounts in Tally, each with its own idea of what a guest is and a nightly export to keep them roughly in step. Every seam is a place where the record splits.

What "one" means here

One table of people. The guest the desk checks in, the guest the CRM segments, the guest the restaurant charges, the guest housekeeping remembers a hard pillow for — one row.
One folio. The room night, the dinner, the minibar, the hall — one bill, or windows on it, by rule.
One chart. The desk, the booking page, the central desk and the channel manager all read the same rooms and the same restrictions.
One log. Every change, from every module, on one page.
One set of books. The night audit and the outlet's day end close into the same ledger.

What it costs

A module cannot be replaced by a competitor's — the POS is not swappable for somebody else's POS. That is the trade, stated plainly. What is bought instead is that the dinner is on the folio before the guest reaches reception, every time, with nobody reconciling anything.

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 — and the price is one number per room, not a list.

More on The platform

The hotel ID, and who may see whatSign-in is a hotel ID, an email and a password; row-level security in the database decides what that login may see; a platform user sees nothing until a hotel has let them in. Roles and capabilitiesFront desk, housekeeping, back office, manager, administrator — and under each role a catalogue of capabilities that reach down to the button, gated by the module the account has bought. A group of hotelsOne hotel or twenty, on one account: each with its own business date, rates and rooms; the group with one guest list, one central desk, one heatmap and one set of consolidated numbers. Support access is granted, time-boxed and loggedOur own people cannot open a customer's hotel. The account lets them in for a window, the session is logged, and the account can see afterwards who was inside and when. The manual ships with every screenA hundred and twenty-four pages, written for the person at the desk, filtered by module and role, opened with one key on any screen — and published free at pms.theorionhotels.com/help. When the system refusesEvery refusal is a sentence written for the person at the desk, in the manual, findable by pasting it in — and the rule for what gets refused is one line. The log is the priceEvery change to every record carries who, when, from which login, which address and which machine — and the log is read on one page, by support and by the hotel. Opening a hotelThe wizard takes the code, the GSTIN, the room types with real room numbers and a rate each; readiness says what is still missing; the board tracks it to open — and the hotel opens itself. Modules and the subscriptionEach module is licensed on its own, switched per account by the platform, and the switch has teeth — a suspended account cannot sign in. EmailConfirmations, invoices, payment links, the morning sheet, scheduled reports — sent in the hotel's name, replies routed to a person, every send on the log. SecurityRow-level security in the database, credentials in an encrypted vault, host-only sessions per door, SSH guarded by fail2ban, backups before every migration, and a test suite that signs in as the application role.