One screen does not mean one transaction type
A hotel guest portal lets guests see reservations, purchases, QR orders and requests without confusing their records. Rezervem Stay is designed as the guest-facing view, while the specialist systems keep each transaction. A hotel guest might book dinner, buy a transfer, order beside the pool and request an extra pillow. A useful guest portal brings these actions into one place without claiming they all share a reservation status.
A practical target is a shared Plans area with action-specific details. Dining needs a date and party size; a purchase needs price and payment; a QR order needs its service location; a request needs the responsible department. Each source keeps its own identity.
Every card should answer the guest's next question
A dinner card can show Saturday at 20:00 for four guests. A transfer card should distinguish payment received from transport confirmed; a sunlounger order should show whether it is being prepared.
A successful charge is not proof that a driver was assigned. A kitchen receiving an order is not proof that delivery happened. A towel request can be completed without any financial movement. Show each lifecycle clearly.
- Restaurant: outlet, date, time, party size and permitted cancellation.
- Experience: product, variant, payment, balance and fulfilment.
- QR Order: items, service point and preparation status.
- Hospitality: request type, assigned team and resolution status.
- PMS: appropriate accommodation information within guest permissions.
Send cancellation and refunds to the correct owner
Cancelling dinner may free a table and affect a dining allowance. Cancelling a paid experience may require refund and delivery handling. QR order and guest-request cancellation follow different operational rules.
Use distinct states for payment completed, refund initiated and refund settled. Clicking Cancel is not evidence that a bank refund has been received. For detailed order rules see the Experience refunds guide, currently in Turkish.
Decide what stays accessible after check-out?
New actions tied to an active stay should end when that entitlement ends, but guests may still need access to an eligible receipt or past booking.
Set separate permissions for creating an action and viewing a retained record. An incoming guest must never see the previous occupant's orders simply because the room number is the same.
Web and branded apps should show the same records
A hotel may offer browser or QR access and optionally a branded mobile application. Both should refer to the same authorised restaurant, purchase and task records.
That does not mean the devices share a session token. The guest may need to sign in separately; access must be validated for each supported channel.
The Rezervem system boundary
Stay is the planned common guest interface. Manager owns restaurant bookings, Experience experience orders, Pay money movements, QR Order service orders and Hospitality team tasks.
Before enabling a combined view, test completed payment, declined payment, refunds, room changes, checkout and cross-property isolation. Card visibility alone is not a launch test. Explore Stay.
