The demo does not end when connectivity returns
A PMS outage demo should establish more than whether the screen opens again. Test which information reception can trust, which tasks remain pending and how records are checked after recovery. An availability percentage in a sales presentation does not explain the state of an interrupted check-in. The following is our general buying-test proposal, not a claim about any brand’s offline capabilities or a Stayax feature. Run it only in an agreed demonstration environment with two entirely fictional records, without interrupting a live operation.
Define the outage boundary first
A frozen device, a property internet outage and a provider incident are different scenarios. Name the one being demonstrated before drawing conclusions. Cloudbeds’ public troubleshooting guide likewise distinguishes local conditions from service issues and points to its status page. That is context, not a resilience rating. Ask the supplier to show the reception-facing route: whom to notify, which official service information to read and how staff avoid repeating actions without knowing their outcome. Keep the demonstration within the agreed scope.
Record the starting state with fictional entries
Let fictional entry A await check-in and entry B contain a room-assignment change that has not yet been completed. Real names, documents or reservation details are unnecessary. Before the interruption, write the last confirmed state, action start time and expected result for each entry. After recovery, compare outcomes with this baseline instead of judging the appearance of the screen. The question is who completes an interrupted task and on what evidence, rather than another permissions or data-export demonstration.
Visible information may not be current
If a list remains visible without connectivity, ask when it was last confirmed and which later changes might be missing. Reading a list is not the same as saving a new action. If nothing is available, document that limitation instead of assuming an offline mode exists. Examine your organisation’s approved alternative working material and its update responsibility. NIST’s general continuity framework includes alternate processing; it does not guarantee that every hotel task can safely continue manually. Record information age together with its permitted use.
Prove the outcome of interrupted work
Ask for an agreed interruption after a change has started in the demo environment. Was the work completed, merely shown on screen, or explicitly rejected? Do not collapse these outcomes into a generic retry instruction. Have the supplier identify the visible confirmation or record that proves the result. Demonstrate checking current state before repeating work whose outcome is unknown. This specifies a buyer-visible result, not a technical architecture or automatic retry design. Keep completed, pending and uncertain outcomes distinct in the notes.
Reconcile differences after recovery
When connectivity returns, compare A and B with the starting form. Has the pending check-in completed, was the assignment applied once, and does a later change conflict with the note? Ask how differences are found and who verifies them, not just for a final success screen. See how unresolved work reaches the next shift. Distinguish demonstrated reconciliation from untested assumptions about automation. Finish with two clear record states and any follow-up assigned to an owner; an open screen alone is not closure.
Separate objectives, promises and observations
Derive acceptable interruption for each task from your operating needs. Keep that objective, the supplier’s written service scope and the duration actually observed in the demo in separate fields. A quick demonstration does not create a recovery promise for every incident, and an objective is not a measured result. NIST’s 2010 continuity guide addresses assessment of priorities; we are not announcing a new regulation or mandatory hotel deadline. Describe which work matters first and where its last reliable record can be verified.
Ask for a support handoff and evidence
If the issue remains unresolved, demonstrate one coherent incident note: start time, affected fictional task, visible outcome and checks already completed. Use minimal evidence from the demo rather than collecting real guest information. Identify the first contact, who keeps ownership while teams hand work over, and where updates appear. A support-team name or sales promise is not an observed outcome. Keep the contact route, responsible party, follow-up state and the question requiring another test together in the buying record.
Classify demonstrated, conditional and open results
Do not score only presentation fluency. Mark a scenario positively when starting and final states reconcile, uncertainty stays visible and a responsible follow-up route is demonstrated. Record a result as conditional if it depends on another service, setup or unshown requirement. If the record outcome remains unclear, leave it open and write the exact question for a second demonstration. Unrelated features cannot replace missing outage evidence. Comparing these categories makes accepted limitations and unresolved buying conditions visible to the team.