How to Choose a Hotel PMS

I run a PMS company, so treat this with appropriate suspicion. I am writing it anyway because the way most properties evaluate this software is close to guaranteed to produce a bad decision, and the pattern is the same whether or not the buyer ends up choosing us.

The core problem is that a demo is a performance of the happy path. Every system looks competent when a salesperson checks in a cooperative fictional guest. Almost none of the things that will frustrate you in year two are visible in that thirty minutes.

Evaluate your exceptions, not your happy path

Before you see a single demo, write down the ten situations that currently cost your team the most time. Not the common ones — the annoying ones. Then insist on seeing each performed live, by you, on a trial account.

• A group arriving with a rooming list that changes twice before arrival
• A folio split three ways, where one part bills to a company and the other two to individuals
• A guest extending mid-stay across a rate change
• A room move after check-in, with charges already posted
• A refund to a card that has since expired
• A booking that needs to be moved to a different room type at the original rate

These are ordinary hotel situations. They are also where systems differ most, because they are the cases that require the underlying data model to be right rather than merely the screens to be attractive. A system that handles all six cleanly is likely to handle the next six you did not think of. One that needs a workaround for three of them will need workarounds forever.

Ask about the boundaries

The second category of question concerns what the system does not do itself. Every PMS sits in an ecosystem, and the quality of those seams determines a great deal of your daily experience.

1. For each integration you need, is it built by the vendor, built by the partner, or a certification the vendor issued to someone else? These fail very differently.
2. When a channel manager sync fails at 3am, who notices — the system, or you when a room double-sells?
3. Is the integration bidirectional, and what specifically flows each way? 'Integrates with' is not an answer.
4. What happens to the connection when the partner changes their API? Who does that work and on whose timeline?

Be equally direct about anything described as on the roadmap. A roadmap item is not a feature, and the honest response to 'that's coming in Q2' is to evaluate the system as though it will never arrive. Sometimes it does. You should not be paying for the possibility.

The question nobody asks

Ask how you would leave.

Specifically: can you export your complete reservation history, guest profiles, folio detail, and rate calendar, in a documented format, without paying an exit fee or filing a support ticket that takes three weeks? Can you do it yourself, today, on the trial account?

This question is against my commercial interest and I think it is the most predictive one on the list. A vendor confident in the product has no reason to make leaving difficult. A vendor who makes your data hard to retrieve is telling you how they intend to retain you, and it is not by continuing to be the best option.

“How easily you can leave is the most reliable signal of how a vendor plans to keep you.

What to weight less than you will want to

Two things reliably absorb more evaluation effort than they deserve.

The first is the feature checklist. Vendors compete on these and it is easy to build a comparison grid where one system has more ticks. But feature count is nearly uncorrelated with daily experience, because the features you use every day are a small subset, and the difference between a good system and a bad one is how well it does those few — not how many others it also lists.

The second is interface polish. It matters, but it is the easiest thing for a vendor to fix and the easiest for a buyer to over-weight. A beautiful system with a wrong data model will still be wrong next year. A plain one that models your operation correctly can be made attractive.

Talk to a reference the vendor did not choose

Every vendor will supply references, and those properties will be happy. That is what makes them references. The more useful conversation is with a property the vendor did not nominate — find one through an industry group, a peer, or by asking a supplier who sees many hotels.

Ask them two things: what took longest to get right after go-live, and what they still work around. Every system has an answer to both. A vendor whose customers all name the same workaround has a known weakness, and you can then decide whether it intersects your operation. That is a far better basis for a decision than any demo, including mine.