Ask four separate questions in the demo
A PMS housekeeping demo should answer four different questions: is a room occupied, has it been cleaned, has the required inspection happened, and does an unresolved fault affect its use? Reservation occupancy does not answer physical readiness, and completed cleaning does not resolve a maintenance issue. Cloudbeds’ calendar guide displays occupancy and housekeeping condition separately. Test how the candidate handles this distinction, what reception sees and who approves the outcome. Agree what “ready” means before accepting the presenter’s terminology.
Set up fictional rooms and roles
Request a test environment without real customer data. In a fictional scenario, one room is vacant and dirty, another occupied with cleaning pending, and a third cleaned but awaiting inspection. Show reception, housekeeper, inspector and maintenance roles in separate sessions, even if a small property combines some roles. Capture the starting conditions and note enabled settings, permissions or modules. Give every vendor the same script. Do not let the scenario change for presentation convenience: the point is to examine conflicting room decisions, not just an attractive calendar.
Test inspection after cleaning finishes
First, have the housekeeper mark the vacant dirty room as cleaned. Return to reception and inspect what changed: did the task close, did the condition update, and is inspection still pending? Cloudbeds’ room-condition guide distinguishes cleaning from inspection and inventory availability. Ask the candidate to demonstrate its own equivalents; identical labels may not mean identical behaviour. If your process requires inspection, do not assume guest release before approval. Try the approval with an unauthorised role too. Obtain a written answer about which record takes precedence when task completion and room condition disagree, then replay the complete workflow.
Separate a repair task from an inventory block
Next, create a fictional water-leak task for a cleaned room. Show ownership, priority, next action and the verification outcome. Creating a maintenance task must not be assumed to close inventory; demonstrate the effect separately. Mews’ status report explains the inventory effects of maintenance blocks. Ask the vendor to define its own maintenance note, use restriction and sales block. Inspect both room display and inventory across the selected dates. Close the task and test whether the block clears, inspection becomes pending and the correct role authorises release. Distinguish completing a repair from approving the room for use.
Expose exceptions and delayed information
Include exceptions rather than replaying only the ideal path. For an occupied room, show what a do-not-disturb request does to cleaning work. Reassign a room and inspect the previous attendant’s view. Ask how reception identifies current information when a mobile connection fails and an update arrives later. Correct an accidental status selection and check whether earlier information remains understandable or an explanation is required. Define the team’s reference screen. For a small hotel, preserving open work and clear ownership matters more than accumulating features.
Record results against observable acceptance steps
Do not mark the demo simply “passed” or “failed”. Record starting state, acting role, action, expected result, demonstrated result and unresolved question for every step. A fictional acceptance requirement might be: reception sees cleaning completion, recognises pending inspection and separately notices open maintenance. Return unsuccessful steps to the vendor with notes and rerun from the start after configuration changes. Compare under identical conditions. Keep working, configuration-dependent and undemonstrated flows separate. A roadmap promise should not substitute for a capability that the presenter could not show.
Base the purchase decision on demonstrated evidence
Have housekeeping, reception and maintenance review the same record before deciding. Request written confirmation of package inclusion, dependencies, permissions, training responsibilities and starting configuration. Check document versions and access dates because products can change. The supporting public documentation was opened on 14 October 2026. Arrange further verification for candidates that cannot demonstrate critical steps. A suitable choice makes occupied, cleaned, inspected and maintenance-ready states understandable to your actual team. Before first use, rerun the fictional acceptance scenario and close remaining questions with an assigned owner.