What should a group-booking demo test?
Do not judge a PMS group feature only by whether several bookings share a name. Observe capacity held by date and room type, the portion converted to individual reservations, and how unused rooms return to sale. This guide uses public documentation checked on 10 October 2026 to help you build a test. It claims neither common functionality across all PMSs nor specific Stayax capabilities. The aim is a verifiable acceptance record. Cloudbeds describes module and version scope; its allotment guidance distinguishes held inventory from availability-based access. This does not establish a common screen for every supplier. Ask which purchased plan and version the demo uses. A different version's video is not evidence for your offer.
Define fictional data and expectations
Request six rooms on each of three nights: potential capacity is 6 × 3 = 18 room-nights. Use fictional records, not real guests. Define room types, dates and block status. Ask the supplier to show the difference between an enquiry and confirmed capacity holding. Compare remaining public availability with your expected outcome at each transition. Clarify terminology rather than assuming matching labels mean matching behavior. Then turn four rooms on each night into actual reservations. This scenario produces 12 reserved room-nights and six held but unreserved room-nights. The calculation assumes equal dates and quantities. Recompute if someone arrives later or leaves earlier. Guest count and room-nights are not interchangeable. Establish which quantities mean enquiry, block, reservation and available capacity before judging a screenshot.
Test release and partial changes
Choose an explicit condition for releasing unused capacity. If automation is offered, demonstrate its date, time and scope. Otherwise record the manual step and its owner. Does the action affect every date together or individually? What happens to already reserved rooms? How does staff notice incomplete or failed execution? These are questions about observable user outcomes, not requests for internal algorithms. Leave undocumented behavior as an open question rather than inventing it. Cancel one of the four three-night reservations: the remaining three represent nine room-nights. This guide does not claim canceled capacity automatically returns to public sale; demonstrate the block rule and behavior. Check whether cancellation affects one booking or the whole group. Add a room-type or date difference and ask what the report totals include. Booking cancellation, group-account closure and inventory release should not be treated as synonyms. Run no real payment action in this capacity test.
Base selection on evidence
For each scenario, record initial state, action, expected result, observed result and open question, together with plan and version. Watch missing-room, changed-date and partial-cancellation cases, not only success. Do not score a promised future feature as available today. Ask a fictional user to repeat the workflow; feature existence and usability differ. Real guest lists, private rates and access credentials are unnecessary. Finish by identifying what is actually held, how unused rooms return, who confirms changes and where results appear. Resolve important gaps before purchase. This is no best-PMS ranking or perfect channel-transfer guarantee. Use related PMS and channel guides to evaluate observed operating outcomes rather than a group label.