Hotel PMS Demos: Test the System, Not the Pitch

Every PMS demo you will ever watch is rehearsed. It runs on clean invented data, in a property with no history, driven by somebody who uses the software every working day and knows exactly which route avoids the awkward screens. None of that is dishonest. It is simply a sales presentation, and a sales presentation is close to useless for deciding which PMS system your team will still be able to work with at eleven o'clock on a Saturday night in eighteen months.

The fix is not to be adversarial. It is to take control of the agenda. Bring your own scenarios, your own messy data and your own staff, and the same forty-five minutes that would have shown you a polished walkthrough will instead show you how the product behaves when reality arrives. This article covers the evaluation itself: what to prepare, which scenarios expose weakness, what to ask, what to ignore, and how to score it afterwards without fooling yourself. It stops where the commercial terms begin, because what to check in a hotel PMS contract is a separate piece of work, and so is the question of whether a bundled booking engine is genuinely part of the licence.

What follows assumes an independent or small-group property with no procurement department. If you have one, most of this still applies; you will just have more people in the room.

Why Every Demo Looks Good

Understanding why demos flatter software is the whole basis for evaluating one properly. Four things are working against you, and none of them requires anyone to behave badly.

The data is perfect. Demo properties have tidy guest profiles, no duplicates, consistent rate codes and no fifteen-year accumulation of half-migrated records. Almost every real difficulty in a hotel system comes from data that is wrong, ambiguous or historical. You cannot see how a product handles that by watching it handle data that is none of those things.

Nothing about the second point is unique to software. The presenter is an expert user, and expert users make any interface look coherent. They know that the thing you cannot find is behind a right-click, that the report lives under a different menu than you would expect, and that a certain screen is best avoided. Your night auditor will know none of this in week one, and the gap between expert and novice is exactly what a demo hides.

The path is rehearsed. A demo follows a route chosen because it works. Every product has areas that are older, clumsier or unfinished, and no presenter walks into them voluntarily. The absence of a topic is information, and it takes deliberate effort to notice what you were not shown.

You are primed to like it. By the time you reach a demo you have usually spent weeks reaching a shortlist and you want the search to be over. Watching a competent presenter solve problems fluently is genuinely persuasive. That feeling is not evidence.

What to Do Before You Book Anything

The most valuable part of an evaluation happens before you speak to a single vendor, and it is the part most often skipped because it feels like delay.

Write down what is actually wrong today. Not features you would like, but the specific things that cost you time or money this month. A useful list looks like: the group rooming list takes two hours to enter by hand, the housekeeping board is a printed sheet that is out of date by ten, we cannot see net revenue by channel without a spreadsheet, and the night audit fails whenever a folio is left open. That list is worth more than any feature matrix, because it is the only thing that will tell you afterwards whether a system solved your problems or merely had a lot of features.

Then separate the list into three groups. Things that must work or the property cannot operate. Things that would save real, quantifiable time. And things that would be pleasant. Be strict, because everything migrates upward if you let it, and a requirements list where everything is essential provides no basis for choosing between two products that both do most of it.

Two further pieces of preparation pay for themselves. Write down the hotel PMS integrations you genuinely cannot live without, naming the specific products and versions, since a partner logo on a website is not the same as a live certified connection. And decide who will make the decision before you start, because an evaluation that ends in a committee with no owner tends to end in no decision at all, or in whichever option the loudest person preferred.

Take Control of the Agenda

When you book the demo, send the vendor a short written brief several days in advance. Four to six scenarios drawn from your own operation, a sentence each, plus your must-have list and your integration list. If you can produce a de-identified sample of your own data, send that too.

Say plainly how you want the session to run. Something like: twenty minutes for your standard overview, then we work through our scenarios, and we would like one of our team driving for the last part. Most vendors accept this readily, and the ones who resist have told you something useful before the meeting has started.

This does not exist to ambush anybody. It exists because a prepared demo of your scenarios is far more informative than an unprepared one, and because how a vendor handles the brief is itself a signal. The good response is a call beforehand asking what you mean by two of the scenarios. That is what implementation will feel like: someone trying to understand your operation rather than fit it to their template.

One practical note on recording. Ask whether you may record the session, and if the answer is yes, do it. Three demos blur together within a fortnight, and the specific answer to a specific question is exactly what you will want to check later, particularly if it turns out to have been optimistic.

The Scenarios That Actually Reveal a System

Good scenarios share a property: they are ordinary in a hotel and awkward in software. Anything can take a clean reservation. What separates systems is what happens when the situation is untidy, which is most of the time.

The Arrival That Does Not Match the Booking

A guest arrives a day early, for three nights rather than two, wants a different room type, and the booking came through an agency at a rate that does not apply to the new dates. Ask them to handle it start to finish.

Watch for whether the reservation is amended or cancelled and rebuilt, because rebuilding loses the history and the original rate evidence. Watch what happens to the agency commission, whether the rate recalculates or has to be overridden by hand, and whether an override needs a manager. Then ask the question that matters afterwards: can you see, tomorrow, what this booking originally was and who changed it? Systems that handle amendments by discarding the past make disputes unresolvable.

The Bill Nobody Wants to Split

Two colleagues share a twin room. The company pays room and breakfast for both, they pay their own extras, and one of them has already paid a deposit online. At checkout, one wants a single invoice to their employer and the other wants a personal receipt.

This is routine in any hotel doing corporate business, where the balance usually lands on the city ledger, and it is where accounting-side weakness shows up immediately. Can charges be routed by type before arrival rather than untangled at checkout? Can a folio be split across payers without re-keying? Does the deposit apply to the right side? Can you produce two documents with correct tax treatment on both? If this takes the expert user several minutes and a workaround, remember that your receptionist will be doing it with a queue behind them.

The Group That Changes Twice

A block of fifteen rooms drops to eleven inside the cutoff, then two names change and one becomes a double. Ask to see the whole path: block setup, rooming list, the reduction, the release of inventory, and what the group bill looks like at the end.

The specific things to watch are whether released rooms return to sale automatically, whether the rooming list can be imported or must be typed, and whether attrition is tracked against the contract or lives in somebody's memory. Hotel group block management is one of the widest quality gaps between hotel systems and one of the least likely topics to appear in a standard demo.

The Night Audit and the Morning After

Ask to watch a hotel night audit run with something wrong in it: an open folio, an unposted charge, a failed card authorisation. Then ask what the morning reporting looks like.

The useful questions are whether the audit blocks on the error or carries it forward silently, whether it can be run again if something was missed, and who is expected to fix what it finds. Also ask what happens if it does not run at all, which happens more often than anyone admits. A system that treats the night audit as an irreversible ceremony is harder to live with than one that treats it as a repeatable process.

Two more scenarios are worth adding if you have time: a rate change that has to reach every channel, so you can see the distribution path end to end and how long it takes to propagate, which is where channel manager and PMS sync issues surface; and a same-day cancellation with a card charge, a partial refund and a guest complaint, which shows you the payment path and the audit trail together.

Count the Clicks, Not the Screens

Bring a way to record two numbers for each scenario: how many steps it took, and how long. Not to hold anyone to a stopwatch, but because those numbers are the only part of a demo that is comparable across three vendors a fortnight later, when everything else has become an impression.

Scale the result against frequency. Check-in happens hundreds of times a month. If one system takes four clicks and another takes nine, that difference is real work, repeated by tired people, forever. A monthly report taking two minutes longer matters far less. Weighting by frequency is what stops a scoring exercise being dominated by whichever feature was demonstrated most impressively.

Pay attention to three specific things while you count. How much of the work happens on one screen rather than across several, because context-switching is where mistakes enter. Whether the system prevents errors or merely reports them afterwards, since a warning before a double-booking is worth a great deal more than a report listing it. And how the product behaves when something goes wrong: a clear message that says what happened and what to do next is a sign of a mature product, and a generic failure notice is a sign of the opposite.

Who Should Be in the Room

The most common evaluation mistake is that it is done by the person who will use the system least. Managers choose, and receptionists live with it.

Bring the people who will touch it daily. A front desk supervisor, whoever runs housekeeping, whoever handles the money, and, if you have one, whoever does revenue and distribution. They will each ask a question you would not have thought of, and they will notice things you cannot: your night auditor will spot in ninety seconds that the closing routine has a step that cannot be undone.

Give them a specific brief rather than an invitation to attend. Ask each person to judge one thing, write it down during the session, and share it immediately afterwards. Otherwise the meeting produces a general feeling, and general feelings are dominated by whoever speaks first.

There is a second, quieter benefit. People who were consulted during selection behave differently during a rollout. Change resistance in hotels is often not about the software at all; it is about a decision having been made elsewhere and handed down. An hour in a demo buys a surprising amount of goodwill later.

Questions That Get Honest Answers

Open questions get marketing answers. Specific questions get information. The distinction is entirely in the phrasing.

Two questions are worth asking of every vendor because the answers are so revealing. What are you not good at, or what do customers most often ask for that you do not do? A vendor who names something specific is telling you the truth and is usually the more reliable partner. A vendor who cannot think of anything is either not listening to their customers or not telling you.

And: what kind of hotel is a bad fit for you? Every product has a shape. A system built for city-centre business hotels will handle a resort with activities, spa treatments and half-board badly, and the good vendors know this and will say so rather than sell you a difficult first year.

Red Flags During a Demo

Some signals are worth more attention than the feature list, and most of them are about behaviour rather than software.

Deflecting a scenario to a later session. Once is fine, since something genuinely may need setting up. Repeatedly deferring the awkward scenarios means the awkward scenarios are awkward for the product.

Answering a capability question with a roadmap date. Treat anything not shipped as though it does not exist. It might arrive; you cannot run a hotel on it in the meantime.

Slides where a screen was expected. If a module is presented as a diagram rather than a working screen, ask to see it working. Sometimes the answer is that it is in beta, which is fine to know and expensive to assume.

Pressure tied to a deadline. Discounts that expire this week are a sales technique, not a commercial reality. A vendor confident in their product does not need you to decide before you have finished evaluating it, and this one is worth remembering when you reach the contract stage.

Vagueness about who does the work. Ask who will run your implementation, whether they are employed by the vendor or a partner, and how many properties they handle at once. Implementation quality varies more between people than between products.

No willingness to give you access. A vendor who will not put you in a sandbox is asking you to buy a system your team has never touched.

The Sandbox Is Where the Truth Lives

If you take one thing from this article, take this. A guided demo tells you what the software can do. A sandbox tells you what your team can do, unaided, and only the second predicts whether a rollout succeeds.

Ask for a trial environment for your two finalists, ideally loaded with a sample of your own data, for one to two weeks. Loading that sample is also an early read on how a PMS migration would actually go. Then give your team real work in it rather than letting them explore. Explore is not a task and produces nothing comparable.

Set the same short list of jobs in both systems: create and check in a booking, split a folio, amend a group, run a night audit, produce the report your owner asks for every month. Ask each person to note where they got stuck and what they had to ask about. Then compare the notes rather than the opinions.

Pay particular attention to who struggles. If your most experienced receptionist finds something confusing, that is a product problem. If your least confident staff member struggles with everything, that is a training question and a different kind of cost, which is still worth knowing about before you commit.

Watch out for one trap. A system that feels familiar is not the same as a system that is good, and teams reliably prefer whatever most resembles what they already use. Ask whether something is genuinely worse or merely different, and be honest about the answer, because familiarity fades within a few weeks and bad design does not.

Reference Calls, and Getting Past the Happy List

Every vendor keeps a list of customers who will say nice things. That is not a scandal; you would do the same. The task is to get useful information out of a conversation the vendor arranged.

Ask for references that resemble you: similar size, similar segment, similar integrations, and ideally one that went live in the last twelve months so the memory of implementation is fresh. Then ask questions that cannot be answered with a verdict.

What surprised you after go-live? What did implementation actually take against the estimate? What have you given up trying to do in the system? Tell me about a time support really mattered, and what happened. What would you check if you were choosing again? Each of these produces a story rather than an assessment, and stories contain detail that assessments do not.

Then go slightly beyond the list. Ask the vendor directly whether any customer has left in the last year and why, which is a question that produces either a candid answer or an informative silence. Independent hotel communities and regional associations are also worth asking, and a single conversation with somebody running your exact combination of systems is worth more than any amount of published material.

How to Treat a Roadmap Promise

At some point in every evaluation, a gap will be answered with a plan. The right response is neither to dismiss it nor to count on it.

Buy the product as it exists today. If the gap is genuinely fundamental, the honest conclusion is that this system does not fit yet, however credible the plan is. Software timelines slip in every industry and a delivery date given during a sales process is an intention, not a commitment.

If you decide to proceed anyway, make the promise real. Get it in writing with a date, attach it to the agreement as a schedule, and ask what happens if it does not arrive. A vendor genuinely committed to shipping something in the next two quarters will usually put that in a document. One who will not has told you how firm the plan is.

A useful calibration question costs nothing: what did you ship in the last twelve months, and what was on the roadmap a year ago that has not arrived? A vendor who answers that comfortably is a better bet than one who only talks about what is coming.

Scoring Without Fooling Yourself

Scoring matrices are useful for one reason and dangerous for another. They force the team to record judgements while memory is fresh, which is genuinely valuable. They also produce a number that looks objective and is not, because the weightings were chosen by people with preferences.

Keep it simple. Score against the must-have list you wrote before you spoke to anyone, weighted by how often the thing happens, with each attendee scoring their own area rather than everything. Record the click counts and the sandbox notes alongside the scores rather than folding them in.

Then treat the total as a prompt, not a verdict. If the winner on points is not the one your team wants to use, do not simply override the team; find out why the gap exists. Usually it is one of three things: something important was left off the matrix, a weighting is wrong, or the preference is familiarity rather than quality. All three are worth knowing and none is settled by arithmetic.

One discipline is worth imposing. Write a short paragraph explaining the decision before you sign anything, naming what you are giving up by not choosing the others. If that paragraph is hard to write, the evaluation is not finished. If it is easy, you will be glad to have it in eighteen months when somebody asks why the hotel runs what it runs.

Turning an Evaluation Into a Decision

Evaluations do not usually fail because the wrong system won. They fail because they never end: the shortlist grows, a new option appears, the person driving it gets busy, and a year later the hotel is still running what it was running, with the same problems on the same list.

Set the timetable at the start and hold it. For an independent property, one to two weeks of preparation, two or three weeks of scripted demos, one to two weeks of sandbox with reference calls running in parallel, then a week to decide. That is roughly six to eight weeks, and it is enough. Compressing it usually means dropping the sandbox, which is the part that actually predicts the outcome. Stretching it past a quarter means starting again.

Two things are worth deciding before the final meeting. What would make you walk away from the front runner, agreed in advance so it cannot be rationalised away afterwards. And who signs, so the decision has an owner rather than a committee. Price belongs in that conversation too, but as total cost of ownership across the term rather than a monthly rate.

Then move to the commercial stage with the evaluation still in hand. Everything you learned about response times, implementation scope, integration certification and roadmap commitments belongs in the paperwork rather than in a memory of a good meeting. The gap between what was said in a demo and what appears in an agreement is where most post-purchase disappointment actually comes from, and closing it is the last piece of work the evaluation owes you.