1. A PMS can be installed and configured without being ready to accept live bookings — the difference is whether the setup has been tested against the scenarios that will actually occur
2. Go-live failures cluster in five areas: incorrect room inventory, rates that do not match what was intended, restrictions that do not apply, payment settings that have not been tested, and staff accounts with the wrong access
3. This checklist covers all five areas across 30 verifiable items — each one maps to a specific failure that reaches a guest if it is not caught before the calendar opens
4. Run the full list once before the first live booking, not after
Why Properties Go Live With Errors
The setup steps for a new PMS are clear: create room types, enter rates, connect channels, add staff. Most properties complete all of them. The problem is that completing a step and verifying a step are not the same thing.
A rate entered incorrectly is not visible until a guest books at the wrong price. A channel connection that appears active but is not syncing availability is not visible until a double-booking occurs. A staff account with overly broad permissions is not visible until someone changes a rate they were not authorized to touch.
The checklist below is a verification step, not a setup guide. Each item assumes configuration is already complete and tests whether it produces the correct result.
Room Types and Inventory (Checks 1–6)
1. Every room type matches physical rooms. The names, counts, and descriptions in the PMS correspond to the actual rooms at the property. A room type called "Ocean View Double" should map to every double room with an ocean view — not more, not fewer.
2. Room counts are correct and cannot oversell. The system's capacity per room type matches the actual number of available units. Enter a test booking that fills one room type to capacity and confirm the system blocks further bookings for that type on those dates.
3. Out-of-service rooms are blocked. Any room under maintenance, renovation, or otherwise unavailable is set to Maintenance status and removed from sellable inventory. Confirm the block appears on all connected channels.
4. Room amenities are tagged accurately. Features used for guest filtering — accessible, ground floor, king bed, balcony — are assigned to the correct room types. A guest who filters for "accessible" should only see rooms that actually meet that requirement.
5. Maximum occupancy is set per room type. The system enforces a guest count ceiling for each room type. A room listed for two guests cannot be booked for five.
6. Photos assigned to each room type are current. The images that appear on direct booking and OTA listings match the current state of the room — not a renovation-era version.
Rates and Pricing (Checks 7–12)
7. A base rate covers the full 90-day window. Every room type has a configured rate for every date in the next three months. Gaps produce errors or zero-rate bookings on uncovered dates.
8. Weekend rates are set separately if applicable. If the property uses Friday–Saturday pricing that differs from weekday rates, confirm the differential applies on the correct days and does not bleed into adjacent dates.
9. Peak and event rates are loaded. Known high-demand dates — public holidays, local events, school break periods — have rates that reflect actual demand rather than the default base rate.
10. Minimum rate floors are in place. No room type can be booked at a rate below the property's cost floor. Confirm that automated tools or manual overrides cannot push rates below the defined minimum.
11. OTA channel rates are correct after commission. If the property lists net rates, verify the markup produces the intended guest-facing price after the platform adds its commission. If listing gross rates, confirm the OTA commission is not being added on top.
12. A test direct booking shows the correct total. Place a test reservation through the direct booking link or widget and confirm the displayed total — rate plus taxes plus any fees — matches what was intended before proceeding to payment.
Verify Rates, Inventory, and Channel Sync Before Your First Live Booking
Smart Order's setup checklist walks property owners through rate configuration, channel connections, and staff permissions — so go-live is a verified state, not an assumption.
Restrictions (Checks 13–16)
13. Minimum stay restrictions are applied to peak periods. A holiday weekend with a 3-night minimum cannot be booked as a single night. Test this: attempt a 1-night booking on a restricted date and confirm the system blocks it.
14. Close-out dates are blocked across all channels. Dates when the property is not accepting new reservations are blocked in the PMS and the block is reflected on every connected OTA channel — not just the direct calendar.
15. Check-in and check-out day restrictions are active. If the property does not allow, for example, Friday check-ins during summer, this restriction is configured in the system and tested by attempting a restricted-day booking.
16. Last-minute booking window is defined. The system has a configured cutoff for how close to arrival it will accept new bookings — whether that is same-day, 24 hours, or 48 hours — and the setting is consistent across direct and channel bookings.
Payment and Cancellation Policy (Checks 17–21)
17. Deposit amount and timing are configured for direct bookings. The deposit percentage or fixed amount and the point at which it is collected — at booking confirmation or 48 hours after — is set and applies automatically to every new direct reservation.
18. Cancellation window is defined and tested. The days before arrival when a cancellation forfeits the deposit is configured. Test it: cancel inside the window and confirm the deposit is retained; cancel outside and confirm it is refundable.
19. No-show fee rules are in place. The charge that applies when a guest does not arrive and did not cancel within the window is configured and tied to the payment method on file.
20. Payment processor connection is tested with a real transaction. A test charge has been processed through the connected payment processor and voided. A payment integration that has not processed a real transaction is not confirmed to work.
21. The cancellation policy displayed at booking matches the configured policy. The text a guest reads when booking — on the confirmation page and in the confirmation email — says the same thing the system actually enforces.
Staff Roles and Permissions (Checks 22–25)
22. Every staff member has an active account. Every person who will use the PMS before or on go-live day has logged in and confirmed their credentials work.
23. Front desk permissions are scoped correctly. Front desk accounts can view reservations, process check-ins and check-outs, and handle payments — but cannot change rates, access full reporting, or modify system settings.
24. Housekeeping accounts are limited to room status. Housekeeping users can update room status (Checked-Out → Cleaning → Inspect → Ready → Maintenance) and nothing else. They do not see guest payment data or reservation financial details.
25. Management and owner accounts reflect the correct access hierarchy. The manager account has reporting and settings access. The owner account has full permissions. No staff account has more access than the role requires.
Channel Connections and Messaging (Checks 26–30)
26. Each OTA channel connection is tested with a live booking. Place a test reservation on Booking.com or Airbnb and confirm it appears in the PMS within two minutes. Do not assume the connection works because the setup screen shows "connected."
27. Availability blocks sync across all connected channels. Block a room in the PMS for a specific date and confirm the block appears on every connected OTA channel. Then unblock it and confirm availability is restored on all channels.
28. The direct booking link or widget shows accurate availability. Open the direct booking page as a guest would and confirm the displayed availability matches the PMS calendar — including any blocks or restrictions.
29. Confirmation message content is accurate. The booking confirmation email contains the correct property address, check-in time window, and a working contact number. Send a test confirmation to a staff address and review every field.
30. Pre-arrival message timing covers all reservation types. The 72-hour reminder sends automatically for every reservation source — including OTA bookings, not only direct reservations. Confirm by checking the message schedule for a test OTA reservation.
Open Your Calendar With Confidence, Not Assumptions
Smart Order connects room inventory, OTA channels, payment settings, and automated guest messages in one system — so the 30 checks on this list apply to a single configuration rather than five separate tools.
FAQ
What should I check before going live with a new hotel PMS?
The five areas most likely to contain errors at go-live are room inventory and counts, rate configuration, booking restrictions, payment and cancellation policy settings, and staff account permissions. Each category contains specific items that can be tested before the first live booking — completing setup is not the same as confirming it is correct.
How do I test OTA channel connections in a hotel PMS?
Place a test reservation on the OTA platform and confirm it appears in the PMS within two minutes. Then block a room date in the PMS and confirm the block appears on the OTA calendar. Both tests are necessary — a connection that syncs inbound bookings may not correctly push availability updates outward, and a connection that pushes blocks may not correctly receive incoming reservations.
What hotel PMS permissions should front desk staff have?
Front desk accounts should be able to view and modify reservations, process check-ins and check-outs, handle guest payments, and add notes to reservation records. They should not have access to rate configuration, system-level settings, full financial reporting, or other staff account management. Limiting front desk access to operational tasks prevents accidental rate changes and reduces the scope of any credential-related security issue.
How do I verify cancellation policy is set up correctly in a PMS?
Test both directions: cancel a reservation outside the policy window to confirm the deposit is returned; cancel inside the window to confirm it is retained. Also compare the policy text shown to the guest during booking against actual system behavior — both should describe the same terms.
When is a hotel PMS ready to go live?
A PMS is ready to go live when every item on a pre-launch checklist has been verified by testing, not just configured by entry. This includes a rate check covering the full 90-day window, a live test booking through every channel, a confirmed payment transaction, all staff accounts active and scoped correctly, and automated messages reviewed for accurate content. Configuration and verification are separate steps — go-live follows verification, not configuration.
