How to run a hotel PMS demo: your own scenarios and a scoring sheet

A hotel PMS demo is a test you set, not a show a vendor performs. Send five to ten scenarios from your own week a week in advance, make your own staff drive each one on screen, score it pass, partial or fail, and ask for a test account with your data before you talk about price.

The presenter checks a guest in, takes a payment, splits the bill and prints a report in eleven minutes. Everything works, because everything was prepared. Your night auditor is watching a version of the hotel that has never had a half-finished reservation in it. After reading this, you will be able to run the next hotel PMS demo as your own test: with your scenarios, your staff at the keyboard and a scoring sheet you can compare across vendors.

Why does a guided demo prove so little?#

Because a guided demo is a rehearsal, not a test: the vendor chooses the data, the order and the path where nothing goes wrong.

The demo property is clean. It has one currency, a handful of rate plans and no reservation left open from last season, so the screens look simpler than yours will. The presenter knows where every button is and has clicked this sequence many times; your receptionist does not, and the demo tells you nothing about how long your team takes to learn it.

Single-user demos also hide the collisions that matter: two people editing the same reservation, a room move while housekeeping is cleaning the room, a payment posted after the bill is closed. A rehearsed path never shows the recovery. What you need to see is what happens after a mistake: how a wrong charge is corrected, who is allowed to correct it, and what the record shows afterwards. And nothing in the demo shows the second month, when the data has grown and the reports have to reconcile with your accountant's ledger.

The fix is simple and uncomfortable for both sides: your scenarios, your sequence, your staff driving.

What should you send the vendor a week before the demo?#

Send a short written pack: your scenarios, your data, your attendees and the reports you expect at the end of each scenario.

Write each scenario as a sequence, not a topic. "A guest moves from room 214 to 310 after check-in; the bill, the key card and housekeeping must follow" can be tested; "room moves" cannot. State the expected end state in one line, so the room can agree on whether the result is right without arguing about it afterwards.

Include the awkward cases from your own week: a guest paying part cash and part card, a company paying for the room while the guest pays the minibar, an early departure that changes the rate. Ask for the demo environment to be loaded with a few of your real room types and rate plans, with names changed if you prefer; a demo on generic rooms teaches you nothing about your own setup. Name the people who will attend and which scenario each will drive, because a demo where only the vendor touches the keyboard is a video, not a test. Ask in advance what cannot be shown and why: a vendor who answers that question honestly is giving you more information than one who promises everything.

This pack pairs well with a wider requirements document; see a template that makes vendor offers comparable.

Which ten scenarios from a real week should you script?#

Pick the ten tasks your team repeats and the three that went wrong last month; those cover more of the system than any feature list.

Cover the four moments where money, identity and the room meet: check-in, posting a charge, splitting a bill, closing the day. Include at least one correction, because a system that cannot void and reverse cleanly will cost you hours at month end. Include one scenario with a travel agency voucher at a net rate, since contracted rates and the bill rarely behave the way a demo implies, and one group or block, because pickup, rooming lists and master bills are where small systems break first. Watch the same scenario twice where you can: once as the receptionist, once as the person who has to explain it to the accountant the next morning. Write down what you saw, not what you were told; the note is what you will compare against the second vendor.

Which compliance steps must you see on screen?#

See the identity notification, the e-document review step and the correction trail run live in the demo, because these are the steps that cost you most when they fail quietly.

In Türkiye, every stay involves a payment, a fiscal document (an invoice or e-document), a guest identity notification (KBS, misafir kimlik bildirimi) and personal data (KVKK). Ask to see each one happen inside a normal workflow, not in a settings menu. Watch where the identity notification is triggered: from the check-in flow, or from a separate screen someone has to remember; then ask what the system does when the notification fails.

Ask to see an e-document held for a person's review before it is sent. Automatic sending without review is a design choice, and you should know which one you are buying. Ask for a correction, not a deletion: financial records should be voided and reversed so the original stays visible, and if a demo shows a charge disappearing, ask where it went. Ask where personal data is stored, how long it is kept, and who inside the hotel can see it; consent captured at check-in is only useful if it is stored with the guest record. Describe your own duties to the vendor in general terms and confirm dates, thresholds and penalties with your accountant or legal adviser; a demo is not the place to settle a compliance question.

For the wider question set, see questions to ask hotel PMS vendors in Türkiye, and for the correction path itself, how to void a folio charge without breaking the audit trail.

Who should sit in the room, and what should each person drive?#

The people who will use the system, each driving the task they own, with the owner or general manager listening rather than clicking.

The front desk supervisor drives check-in, the room move and the split bill, because these are the tasks the desk repeats all day. The night auditor drives the day close and the void after it; this is the scenario most demos skip and the one that decides whether your month end is calm. Housekeeping drives the room status change during a move and asks what the room board looks like on a phone. Accounting drives the invoice or e-document step and the report that reconciles with the ledger, and asks who can reopen a closed day. Reservations or revenue drives the group block and the agency voucher, and asks how a rate change reaches existing bookings.

Keep the room small. Six people who each own a task ask better questions than fifteen who are watching. The general manager takes notes and asks the closing questions.

Before the session starts, each attendee writes one task from last week that went wrong and brings it as an extra scenario. These unplanned cases are usually the most informative part of the demo. For what happens after you choose, see a PMS training plan by role.

How do you score each scenario: pass, partial or fail?#

Score every scenario on the same three-point scale and add one line on the status of the feature, so the comparison between vendors is a document, not a memory.

Pass means the end state you wrote down was reached, by your staff, in a time you would accept on a busy afternoon. Partial means it worked but needed a workaround, a second screen or a manual step someone has to remember; write the workaround down, because it is the real cost. Fail means it did not work, or the vendor could not show it, and a fail is information, not an insult. Add a fourth mark for "not shown" and keep it separate from fail, so you can tell a missing feature from a missing demonstration.

Record the status of each feature in the vendor's own words: built, in use at a reference hotel, or available to you at go-live. Ask for the answer in writing. Score immediately, in the room, before the next scenario starts; scores written from memory two days later all drift towards the middle.

What should you ask for after the demo?#

Ask for a time-limited test account loaded with your data, a reference hotel you may call, and written answers to every partial and fail.

A test account is not the same as a free plan. Ask for a defined period, your own room types and rate plans, and permission to run the same ten scenarios without a presenter watching. Ask for a reference hotel of similar size, type and seasonality, and ask what the hotel uses the system for rather than whether it likes it. Ask who will handle your setup and your data migration, and speak to that person before you sign; the demo presenter is rarely the person who will do the work.

Get written answers to the partials and fails, with dates. Verbal promises made in a demo have a way of becoming next year's roadmap. Ask what the contract says about the data you put in, what happens to it if you leave, and how much notice you need to give; see hotel software contract clauses to read before signing. Then run the same session with the second vendor, on the same sheet, and compare the documents rather than the impressions.

What to do next#

Send your scenario pack to the first vendor on your shortlist today, and book the session a week out so they can load your data. Run the same ten scenarios, on the same sheet, with every vendor you shortlist, and keep the completed sheets side by side. The demo is only the first half of the test; the second half is your own staff using the system in a test account, without anyone guiding them. For what that period should and should not cost you, see whether a free hotel software trial is really free.