Hotel software, vendors and consultants all assume you know the vocabulary. Here it is, defined the way a working hotelier would use it rather than the way a textbook would.
Quick answer (for the impatient)
Hotel terms compress recurring operating ideas. Learn the decision behind the acronym, not only its expansion.
Metrics answer different questions. ADR, occupancy and RevPAR should not be treated as interchangeable.
Product terms still require verification. A label in a sales discussion does not prove a reachable workflow in your tenant.
The revenue metrics
ADR (Average Daily Rate) — room revenue ÷ rooms sold. What the rooms you actually sold went for. Says nothing about how many you sold.
Occupancy — rooms sold ÷ rooms available, as a percentage. How full you were. Says nothing about what you charged.
RevPAR (Revenue Per Available Room) — room revenue ÷ rooms available. Combines the two above, which is why it's the number that settles arguments. See the full explanation.
TRevPAR — total revenue (including F&B and other income) ÷ rooms available. Relevant once your restaurant or banquet operation is material.
GOPPAR — gross operating profit ÷ rooms available. Profit rather than revenue; the one investors care about.
Booking pace — how many rooms are on the books for a future date compared with the same point last year. The most useful forward-looking number a small hotel can track.
The meal plan codes
These appear on rate plans constantly and are rarely explained:
EP (European Plan) — room only, no meals.
CP (Continental Plan) — room with breakfast.
MAP (Modified American Plan) — room with breakfast and one other meal, usually dinner.
AP (American Plan) — room with all meals.
These are what rate plans exist to express: one room type carrying several of these at different prices.
Front office
Folio — the running bill for a stay. Every charge attaches to it; the invoice is generated from it. See why one stay should have exactly one.
Night audit — the daily close that fixes the day's figures and posts what needs posting. See how it works.
Walk / walking a guest — relocating a guest you can't accommodate to another property, at your cost. See walk policy.
No-show — a guaranteed booking whose guest never arrives and never cancelled.
Out of order (OOO) — a room removed from sellable inventory, usually for maintenance.
Stayover — an occupied room where the guest isn't departing today, requiring a shorter clean than a departure.
Rack rate — your published, undiscounted rate. Increasingly notional, since almost nobody pays it.
Distribution
OTA (Online Travel Agency) — a booking platform that sells your rooms for a commission.
Channel manager — software connecting your inventory to OTAs. See what it does.
Booking engine — what lets guests book on your website. Distinct from a channel manager; see the difference.
Rate parity — a contractual obligation to not undercut a platform's displayed rate on your own channels.
Billboard effect — guests discovering you on a platform and then booking direct.
Mapping — declaring which room on a platform corresponds to which room type in your system. The step that makes everything else work.
Compliance
Form C — the foreign guest reporting obligation. See the detail.
FRRO — Foreigners Regional Registration Office, the authority Form C reporting goes to.
HSN / SAC — classification codes that must appear correctly on tax invoices.
E-invoicing — registering invoices with a government portal before issuing them. Turnover-based; see applicability.
Fire NOC — fire safety clearance, and the approval that gates several others. See the process.
Systems
PMS (Property Management System) — the system of record for the hotel's operations.
POS (Point of Sale) — the restaurant/bar billing system. Ideally posts to the folio; see why.
KDS (Kitchen Display System) — screens replacing printed kitchen tickets.
RBAC (Role-Based Access Control) — permissions attached to roles rather than individuals. See how it applies.
Multi-tenant — one software platform serving many separate businesses with their data isolated. See what to verify.
Housekeeping and operations
Par level — how many sets of an item you need in circulation to cover every stage of its cycle. See linen par levels.
Turndown — evening service preparing a room for the night.
86 / 86'd — an item that's run out and is off the menu. Borrowed from restaurants and used in hotel F&B constantly.
Preventive maintenance — scheduled servicing before failure rather than after. See the schedule.
A realistic hotel example: what the team sees during a working shift
Picture Lakeview Residency, an independent property where the same manager may answer a booking query, approve a rate, settle a guest account and help a new employee before lunch. The question behind Hotel Management Terms, Explained Plainly does not arrive as a neat software task. It arrives while somebody is waiting, another department needs an answer and the record must still make sense at the end of the day.
The first useful observation is this: Most of this vocabulary exists to compress a common idea into fewer syllables. None of it is complicated, and a vendor using it to sound authoritative rather than to be clear is telling you something. See the questions to ask vendors , the numbers to watch , or pricing . Run the… The manager should translate that statement into a visible hand-off. Who starts the action? Which record do they open? What information must already be present? Who checks the result? If any answer depends on one experienced employee remembering an exception, the process is not yet reliable.
The second observation is equally practical: Most of this vocabulary exists to compress a common idea into fewer syllables. None of it is complicated, and a vendor using it to sound authoritative rather than to be clear is telling you something. See the questions to ask vendors , the numbers to watch , or pricing . Run the… At Lakeview Residency, the team would test this with one ordinary case and one awkward case. The ordinary case confirms the expected path. The awkward case exposes missing permissions, incomplete data, unclear ownership or a decision that still happens in a private message. Both tests matter because hotel operations rarely fail on the clean example shown in a demonstration.
The third observation is about the downstream record: Most of this vocabulary exists to compress a common idea into fewer syllables. None of it is complicated, and a vendor using it to sound authoritative rather than to be clear is telling you something. See the questions to ask vendors , the numbers to watch , or pricing . Run the… A completed action should leave enough context for the next person to understand what happened without reconstructing the story from calls and chat messages. That does not mean collecting every possible field. It means keeping the few facts that change the decision, the status, the responsible role and the next action together.
Rollout checklist: move from a good idea to a repeatable process
Use this checklist before the team treats the workflow as normal operating procedure. It deliberately separates product reachability from management discipline: software can make a record available, but the property still decides who owns it and how exceptions are handled.
Name the owner. Choose the role responsible for starting and completing the process. "The office" or "the front desk" is too vague when several people share a shift.
Confirm access. Test with the real role and tenant configuration, not an unrestricted demonstration account. Check enabled modules, feature permissions and the property or outlet context.
Define the minimum input. Agree which guest, room, date, amount, document or operational detail must be present before somebody can act.
Run the normal case. Complete one realistic example from beginning to end and ask the next team member to explain the result using only the saved record.
Run the exception. Try a correction, cancellation, missing value, late change or disputed instruction that genuinely occurs at the property. Record the fallback if the product path does not cover it.
Check the hand-off. Make sure the relevant people in front desk, reservations, housekeeping and accounts can see the status they need without receiving unnecessary access to unrelated records.
Write the fallback. If the system is unavailable or the case sits outside the verified path, state who records the temporary decision and who reconciles it later.
Review after live use. Ask staff where they paused, duplicated work or returned to a spreadsheet. Fix the process before adding more fields or automation.
Decision table: evidence to collect before you approve the workflow
A manager does not need a large transformation project to evaluate this topic. A short evidence review is enough to distinguish a reachable workflow from an attractive claim. Use the table during a property review and write the answer in plain language.
Review point What to verify Evidence to keep Decision if it fails
Reachability The responsible role can open and complete the path in the correct tenant and property context. A completed test record and the role used. Do not announce the workflow; check provisioning and permissions.
Data quality The minimum information needed for the decision is present, understandable and current. The input checklist and one reviewed example. Fix the collection step before adding automation.
Ownership One role owns the next action and another can review where separation is appropriate. The operating owner and escalation path. Assign responsibility before rollout.
Exception handling A correction, cancellation or disputed case has a documented path. The tested exception and fallback note. Keep the process in controlled trial use.
Downstream hand-off The next department sees the status it needs without manual re-entry or excessive access. A hand-off check by the receiving role. Use a documented interim hand-off and reconcile it.
The honest AXOIX limit and what to review after the first live cycle
The first review should focus on behaviour, not vanity metrics. Ask the people who performed the work where they hesitated, what they entered twice and which decision still escaped into a phone call or personal message. Compare the saved record with what actually happened. If they differ, find the earliest point where context was lost.
Then separate a training problem from a product boundary. A training problem means the verified path exists but the team did not understand the trigger, required input or next action. A configuration problem means the module, property context or permission is not available to that role. A product boundary means the audited path does not support the case. Those three diagnoses require different responses; calling all of them "user error" guarantees a repeat.
Keep the limitation visible while reviewing this article: Verify the workflow and its applicability before relying on it. That boundary is part of the buying and rollout decision, not a footnote to remove from the sales conversation. Where the workflow is usable, test it honestly. Where it is partial, keep the manual control explicit. Where applicability depends on law, policy or professional judgement, confirm it with the appropriate adviser.
FAQ
How should a hotel test this before rolling it out?
Use the real tenant, property context and staff role. Complete one ordinary case and one exception from start to finish, then ask the receiving role to verify the saved result without relying on a private message.
What should the team do if the verified product path does not cover its case?
Keep a documented manual control, name the person responsible for reconciliation and avoid describing the unsupported step as automated. Recheck module provisioning and permissions before concluding that a capability is absent.
Who should own the final operating decision?
Assign one role to complete the action and a clearly named reviewer where separation is required. The software record should support that responsibility rather than replace it.
Does this workflow behave identically for every AXOIX customer?
No. Tenant configuration, provisioned modules, vertical settings, property context and role permissions can change what a user can reach. Verify the exact setup before publishing an internal promise.
The bottom line
Most of this vocabulary exists to compress a common idea into fewer syllables. None of it is complicated, and a vendor using it to sound authoritative rather than to be clear is telling you something.
See the questions to ask vendors, the numbers to watch, or pricing.
Run the whole hotel from one system. Start free →
Comments