Test more than a date-change button
A PMS demo should show more than the ability to edit reservation dates. Check availability on the new night, updated night count, treatment of price and the point at which a change becomes confirmed. Ask for unavailable and pending scenarios alongside the successful one. Use fictional records in a demo isolated from live channels and guest communication. These are evaluation questions, not claims that a particular product provides the capabilities. Oracle's public OPERA Cloud 26.2 guide describes an availability-confirmation sales screen for changing stay dates. Airbnb's host guide says a standard change request leaves the reservation unchanged if the guest declines or does not respond; it also documents exceptions for some reservation types. These are different products and processes. A PMS edit is not evidence of an automatic change on every channel or a universal approval route.
Build a small, complete demo file
Start with a fictional arrival on 16 October and departure on 18 October: two nights. First extend departure to 19 October: three nights. Next assume no suitable room for the additional night. Finally assume availability but acceptance in the relevant external process remains pending. Dates describe no real reservation. Make room type, party size and example pricing assumptions explicit so changes can be traced to inputs. The seller should confirm that the demonstration does not trigger live bookings, channels or guest messages. Notification examples remain previews with no real recipient. Compare the initial and final dates, room and total. A scenario is complete only when its outcome can be checked. If live connectivity is required and unavailable in the demo, record an evidence gap and the seller's proposed separate verification. Do not mark unseen functionality as demonstrated.
Questions about availability, price and confirmation
Selecting a date is not proof of availability. Ask where the additional night is verified, what happens when unavailable and whether the existing reservation remains intact. For price, inspect original and revised totals, nightly explanation and conditions retained or reconsidered. Products need not share one repricing method. An unexplained number should not be accepted solely because it appears on a screen. Ask the seller to explain visible behavior rather than inventing another calculation. Distinguish a request, an accepted change and a failed operation. Do not generalize Airbnb's standard host-request process to every channel; exceptions and booking types have their own rules. Ask when completion is declared, which dates remain valid while pending and what the user sees if an external process declines. Where the safe demo allows it, ask for a visible rejection result, not only a verbal explanation.
Record decisions according to evidence
For each scenario record demonstrated, partly demonstrated or not demonstrated. Successful extension should show dates, three nights and an explainable total. Unavailability should show the conflict without appearing confirmed. Pending changes should distinguish the valid current state from the unfinished request. These are proposed acceptance questions, not required screen designs or technical methods. Record product behavior separately from channel coverage. A local demonstration cannot prove identical live-channel results. Compare documented scope, shown scenarios and unresolved questions. Do not import real customer access or booking records into this editorial work. If further evidence is unavailable, retain the uncertainty in the purchase decision. A useful demo explains both successful and unsuccessful changes clearly.