One guest journey does not require one database
A hotel guest integration joins verified access, dining, purchases and service requests without merging the underlying records. Rezervem Stay is the guest interface, while Manager, PMS, Experience, Pay and Hospitality have distinct responsibilities. A guest interface may bring together accommodation, dining, ordering, payments and open service requests. Each status still belongs to its specialist system and business rule.
When a room changes, the booking must not become linked to another guest. A restaurant closure also cannot be inferred from the PMS; these sources make different decisions.
Define identity and access boundaries
Guest access may depend on room and stay verification, but one room can have several guests and may be assigned to different people in successive stays. A room number is not enough as a durable identity key.
Test session expiry at checkout, booking ownership in multi-room stays and permissions for different adults in one room.
Test dining, commerce and staff operations separately
Check PMS data freshness, restaurant availability and the actual booking response. Verify that QR orders use the right service point and that staff receive any operational tasks that were really created.
Experience adds a separate product catalogue and order record. Verify product variant, selling venue and price; Pay collection, declines, repeated requests and refunds need another set of tests.
If one integration fails, the others must respond truthfully. A missing PMS response should not be treated as verified access, and a failed order service should not show a completed sale.
- Room reassignment, early checkout, cancellation and extension.
- Competing requests for the final restaurant table.
- Multi-room party ownership and partial cancellation.
- Wrong QR order destination or unavailable menu item.
- Open task handover between shifts.
- Temporary PMS outage and subsequent reconciliation.
Define acceptance and monitoring criteria
Use safe transaction references, timestamps and property IDs when diagnosing failures. Avoid logging complete identity documents or payment secrets.
For each case, compare the guest message, the staff record and the authoritative service result. A success banner without an actual booking does not pass.
Document retry handling, expected data delay and recovery after interruptions. Ensure a repeated event does not create a second reservation or service task.
An order, charge and PMS folio are different
An Experience purchase, Pay collection, QR food order and PMS room charge are separate records. An item described as 'paid' should not mean that it has been delivered or posted to a folio.
Room changes, checkout and payment-provider timeouts require reconciliation based on each original transaction ID.
Test the same source records on web and mobile
Where a branded app is deployed alongside web access, both should display the same authorised restaurant booking, paid order, QR order and guest request states.
App-store approval is not end-to-end integration testing. Check retries, deep links, session renewal and payment return flows to avoid duplicate transactions.
Verify the boundaries of each Rezervem product
Stay is the guest interface; Manager restaurant operations; PMS stays; QR Order ordering; and Hospitality staff operations. PMS-to-Hospitality updates depend on the actual supported integration.
Experience owns products and orders, while Pay handles collection. An Experience variant appearing in a catalogue does not mean it is automatically sellable in Stay, added to a PMS folio or converted to a Hospitality task.
Test the exact read and write scope of the installed PMS adapter, the hotel's modules and staff processes before promising end-to-end automation. Explore Stay.
