Hotel PMS Requirements Checklist — What to Write Down

Why write a requirements list?

It keeps the demo honest and gives every vendor the same scope. Without it, the vendor presents what it does well and the property compares presentations, not fit.

It also gives the project a definition of done. The first close, the first month-end and the reports finance needs become acceptance criteria, not opinions.

Which operating flows should be included?

The standard arrival, the group arrival, the room move, the split bill, the deposit and the no-show. Add the outlet charge and the housekeeping handoff. These are the flows that repeat every day.

For each flow, write who does it, what the system shows and what happens when it goes wrong. The exception is where the system is really tested.

Which reports matter?

The daily pack, occupancy and ADR, segment mix, outlet revenue, AR ageing, the night-audit exception report and the month-end reconciliation. Ask for the exact report, not a category.

A report that cannot drill down to the transaction is a screenshot. Include the drill-down in the requirement.

Which interfaces should be listed?

OTA channels, booking engine, payments, door locks, identity, POS, telephony and accounting. For each, write the exact model and who owns the failure.

A category is not a connection. “Door lock integration” is not a requirement; “this lock model, key issue and revoke” is.

Who signs off?

The front-office manager signs the desk flows, finance signs the folio and reporting, IT signs the interfaces and the general manager signs the scope. One owner coordinates, but the sign-off is by function.

How do you score vendors?

Use the same scenarios and a simple score: works natively, works with configuration, needs custom work, cannot do. Weight the flows that affect the guest and the close, not the number of features.

What does a requirements workshop look like?

Invite the people who do the work: front office, housekeeping, finance and whoever owns the interfaces. A workshop with only managers produces a list of wishes; a workshop with the desk produces the exceptions.

Walk through one real day, hour by hour. Start with the arrival list, then a group, a room move, a split bill, a no-show and the night audit. Write the decisions and the evidence the system must show.

Capture the reports finance uses at month-end and the interfaces that already exist. Ask what happens when each interface fails; the answer is a requirement, not an exception.

End with a scored list: must-have, should-have and later. The property signs it, and every vendor receives the same document.

What should the acceptance test look like?

The acceptance test should use the same scenarios as the requirements list: a standard arrival, a group, a room move, a split folio, a no-show and a night audit exception.

Run them in the sandbox first, then on a controlled live date. Record the result and the owner. A scenario that works in the demo but fails with real data is not accepted.

The property signs the acceptance, not the vendor. The signature means the flow works with the property’s data and people, not that the software exists.