The Hotel PMS Guide — Modules, Buying and Implementation

What is a hotel PMS?

A hotel PMS is the operational database of the property. It holds the room inventory, the rate structure, the guest profile, the reservation, the folio and the room status. Every department reads from it or posts into it.

It is not the website, the OTA or the accounting system. It is the place where the room, the guest and the bill agree.

Which modules should it include?

The core is reservations, front desk, cashier, housekeeping, night audit and reporting. Everything else depends on the property: outlets, banquets, membership, procurement, spa, activities or multi-property.

The test is not the length of the list. It is whether the modules share one guest record and one folio, and whether the handoffs between them are native rather than manual.

How do you choose a PMS?

Start with the operation, not the software. Write down the arrival flow, the group flow, the night audit and the reports management asks for. Then ask each vendor to run those scenarios, not a generic tour.

Compare the three-year cost, the interface ownership and the migration method. Ask for references from a similar property with the same deployment and interfaces.

How long does implementation take?

A single property usually takes four to eight weeks from kick-off to go-live. Groups are phased property by property. Data migration, door locks, payments and channel connections set the pace.

The first night audit is rehearsed before cutover, and the first month-end is supported. A signed acceptance form is not the same as a clean close.

What does it cost?

Pricing combines a subscription or licence by room count and modules with implementation, interfaces, training and support. The exact quote depends on the property and the third-party connections. Compare the three-year total, not the monthly headline.

What should the contract cover?

Data ownership and export, recovery objectives, support hours, interface ownership, price escalation and exit. If the contract does not name the exit path, the vendor has not designed for one.

How do you write a PMS requirements list?

Start with the work, not the software. Walk the front desk through a standard arrival, a group arrival, a room move, a split bill and a no-show. Write down each decision, who makes it and what the system must show.

Then do the same for housekeeping, night audit and finance. Add the reports management asks for and the interfaces the property already runs. A requirement that cannot be tied to a step in the day is probably a preference, not a need.

Separate must-have from nice-to-have and mark the difference in writing. A list of two hundred equal requirements hides the ten that will decide the project.

What are the most common implementation failures?

The first is dirty data. Duplicate profiles, unexplained balances and undocumented open folios surface at cutover, when there is no time to fix them. Clean before the window, not during it.

The second is an interface that was assumed rather than tested. A lock model, a payment terminal or a channel connection that nobody verified becomes a go-live blocker. Test one end-to-end transaction per critical interface.

The third is training that teaches the software instead of the hotel. A generic session produces people who know where the buttons are but not how to handle the property's own exceptions.

What should the first 30 days after go-live look like?

The first week is about stability: arrivals, folios, key issue, payments and the night audit. Keep a named support path and a daily issue review. Do not change the configuration while the team is still learning the flow.

The second and third weeks are about the exceptions: group billing, credit limits, rate overrides and the reports finance actually uses. Collect the workarounds the team invents; they are the next configuration list.

The first month-end is the real test. Reconcile AR, commissions, outlet revenue and the trial balance. A close that requires a spreadsheet outside the system is a gap, not a training issue.

When should you replace a PMS?

Replace when the system of record is no longer trusted: when the desk keeps a parallel spreadsheet, when the night audit needs a specialist, or when the vendor cannot support the interfaces the property needs.

Do not replace only because the interface looks old. A stable system with clean data and a supported interface is often cheaper than a migration. Replace when the operating model, the deployment or the vendor relationship no longer fits.

Plan the replacement like a migration, not a purchase. The data, the interfaces and the first close decide the outcome.

How do you run a vendor demo?

Give every vendor the same three scenarios: a standard arrival with a split bill, a group arrival with a rooming list, and a night audit exception. Ask them to use your rate codes and your room types, not their demo data.

Watch where the presenter hesitates. A polished tour hides the friction; a scenario exposes it. Ask who does each step in the real property and how long it takes at peak.

End with the same question for every vendor: what would you need from us to go live in eight weeks, and what would make that slip?

What should be in the contract?

Scope, interfaces, migration, training, support, data ownership, recovery objectives, price escalation and exit. The scope should name the modules and the number of properties, users and interfaces.

The exit clause should state the export format, the notice period and the deletion terms. The recovery clause should state the tested RTO and RPO, not a marketing target.

If a clause is not in the contract, assume it is not committed. A verbal promise is not a delivery plan.

How do you plan training?

Train by role, not by module. The front desk needs arrivals, folios and exceptions; housekeeping needs the board and tasks; finance needs the close and the reports.

Use the property's own scenarios and data. A generic training deck teaches the buttons; it does not teach the hotel.

Plan refresher training for new starters and for the first month-end. Staff turnover is a training event, not an exception.

What does a 120-room independent hotel project look like?

The reference scenario is a 120-room independent hotel with two outlets, a small sales team and a legacy PMS. The property sells through two OTAs, a corporate account list and its own website. The desk has four workstations and the finance team closes with a spreadsheet.

Discovery takes two weeks: map the current interfaces, the rate structure, the group workflow and the reports finance actually uses. The output is a written scope, not a slide. The property names one project owner with authority to decide.

Configuration takes three weeks: room types, rate plans, packages, folios, taxes, outlets, roles and the night-audit sequence. The team rehearses a group arrival and a split bill in the sandbox before touching live data.

Migration and training overlap. Profiles, future reservations, open folios and the history needed for reporting are extracted and reconciled. Training is two days by role, with a short refresher before cutover.

Cutover is a weekend. The first night audit is supervised, the first week has daily issue reviews, and the first month-end is the real acceptance test. The lessons are usually the same: clean data earlier, test the interfaces once more, and do not change configuration during the first week.