Identify the request and correct booking beyond doubt
Person, case and authority must align before every change.Find the booking by number or linked guest profile and compare name, email, dates, room and source. Verify authority for phone or company requests.
Record the exact request, time and channel. Respect the channel workflow for OTA-origin bookings.
Identify both the request and the booking before editing. Verify booking number, guest identity with more than one matching fact, arrival and departure, room or category, source, current state and the exact requested outcome. Confirm that the caller or sender is authorised to change the stay; a name or forwarded message alone may be insufficient. Read the original booking rather than relying on an email summary, calendar colour or remembered conversation. For an OTA reservation, also check whether the request belongs in the booking channel and whether the platform remains involved. Write a concise instruction: what changes, what remains unchanged, who approved it and by when it must be completed. Stop if two bookings could match, identity is uncertain, the stay is already in-house or completed, or the requested action conflicts with the current state. The identification gate passes only when one original record and one authorised intention are beyond doubt.
| Check | Must match | Stop signal |
|---|---|---|
| Booking | Number, guest, dates, room | Several possible matches |
| Person | Contact and authority | Identity not plausible |
| Request | Concrete new details or cancellation | General question only |
| Channel | Intended change route | Conflict with booking channel |
Distinguish correction, change, cancellation and no-show
The right workflow protects history, availability and finance.A correction fixes entry without changing service. A change alters the agreement. Cancellation ends a confirmed pre-arrival booking. No-show means the expected guest did not arrive and is not a late cancellation shortcut.
An in-house stay uses stay change, early checkout or room move, not pre-arrival cancellation. Historical states are not reactivated by dragging.
Choose the workflow that matches the real event. A correction fixes a wrong master fact such as a spelling error without changing the commercial stay. A change modifies dates, party, room, rate or services while preserving the same reservation history. A cancellation ends an eligible pre-arrival commitment and keeps its policy, fee, refund and audit trail. A no-show records that the expected guest did not arrive under the applicable operating rule; it is not a convenient cancellation label. Checkout and in-house changes follow their own stay workflows. Never delete a booking to remove it from the calendar, and never create a replacement booking before cancelling the original merely to achieve new dates. Explain the selected workflow to the guest and team, including what history and financial effect remain. If the current state does not permit the intended path, escalate rather than forcing another label. Correct classification protects inventory, reporting, guest communication and later dispute evidence.
| Situation | Workflow | Do not use |
|---|---|---|
| Contact typo | Master-data correction | New booking |
| Guest arrives two days later | Date change with availability check | Leave old booking active |
| Confirmed arrival is cancelled | Cancellation by policy | Delete record |
| Guest does not arrive | No-show at the right operating time | Backdated courtesy cancellation |
Calculate before and after completely
Understand the target state before saving the change.Compare old and new dates, nights, occupants, category, rooms, rate, nightly prices, extras, tax, total, paid amount and balance. Extensions may cross pricing periods.
Check full new-period availability. In-house room moves preserve past segments and start on the actual move date. Explain price differences before saving.
Calculate a complete before-and-after view before asking for approval. Compare arrival, departure, nights, room or category, adults and children, rate plan, every nightly price, extras, taxes, total, deposit, cancellation fee, refund and remaining balance. Recheck STRYK availability for every new room-night and capacity for the new party. A date move may enter a different season; an extension may use a new nightly price; a room change may alter included services. Keep accepted extras only when they still apply and remove them only with explicit agreement. Apply the existing payment to the resulting balance without pretending a refund or additional receipt has occurred. Show the guest the exact new total, difference, payment position and conditions, then record consent. If a calculation service fails, do not approximate the effect or enter a balancing manual total. The comparison is ready when old and new values are traceable and the guest can make one informed decision from specific numbers.
| Field | Before | After | Approval question |
|---|---|---|---|
| Dates | 12-15 Sep, 3 nights | 14-18 Sep, 4 nights | Are all new nights available? |
| Room | 108, Double | 202, Studio | Service and capacity clear? |
| Price | Existing total | Recalculated total | Difference agreed with guest? |
| Payment | Deposit | New balance | Payment plan updated? |
Change the original booking with control
A stay remains one case even when its details change.Open the identified booking and edit only approved fields. Wait for availability and pricing to complete, and recheck multi-room allocation.
Do not create a second record for the same date change. A genuinely additional stay is separate, but a revision stays on the original booking.
Edit the original reservation and change only the approved fields. Reconfirm booking number and guest after entering edit mode, then enter target dates, party, room, rate or services from the accepted before-and-after view. Wait for availability, capacity and price checks to complete. Preserve source, history, notes and payments unless the authorised request actually changes their underlying fact. Do not duplicate the stay as a workaround for a conflict, and do not silently move a guest between unlike rooms because a calendar gap looks convenient. Save once and wait for either STRYK confirmation or a visible error. On rejection, read the precise conflict, keep the original unchanged and resolve availability or data at its source. After success, reopen the booking, calendar and guest profile. Exactly one active stay should remain, on the intended nights and room, with the agreed amount and existing history. A changed booking is proven by connected records, not by the edited form still showing typed values.
Save and prove the change
- 01Open original
Read booking number and guest before editing.
Correct case - 02Enter target values
Enter only the approved change.
Before/after documented - 03Wait for checks
Availability, capacity and price must load.
No error state - 04Save once
Do not create another case during delay.
Success or visible error - 05Reopen
Compare detail, calendar and guest profile.
Exactly one active booking
Cancel with policy and financial impact
Cancellation ends the booking but not its traceability.Cancel only an eligible confirmed pre-arrival booking. The stored policy determines fee, refund and any manual review. Courtesy exceptions require approval.
After cancellation, state is Cancelled and future inventory is released. Existing payments remain. Handle refunds through finance rather than deleting payment history.
Cancel only the verified eligible pre-arrival booking and review the policy result before confirming. Read the applicable cancellation window, calculated fee, payments already received, proposed refund or retained amount, currency and resulting balance. Distinguish the commercial fee from the payment action: a cancellation can calculate what is due, but a refund is not complete until the real financial workflow records it. Obtain the required approval for an exception and document the reason without overwriting the original policy evidence. Confirm cancellation once and keep the record with state, time and audit history; cancellation is not deletion. Reopen the calendar to verify the active stay no longer occupies inventory and reopen the booking to verify policy and financial outcome. If the booking comes from an OTA, communicate and reconcile through the correct booking context rather than sending an unrelated manual message. Never mark an arrived guest cancelled to free the room. The cancellation passes when inventory, guest history, fee, payment and communication all describe the same event.
| Check | Expected result | Owner if open |
|---|---|---|
| State | Cancelled with timestamp | Front desk |
| Policy | Stored booking policy evaluated | Management for courtesy |
| Fee/refund | Amount and review state traceable | Finance |
| Availability | Future nights correctly available again | Front desk/rooms |
Verify final state across five connected areas
A success message is not enough for a change with multiple effects.Reopen booking detail, then calendar, inventory, guest profile and finance. A changed stay has one active bar; a cancelled stay has none in the future period.
For in-house room moves, also verify housekeeping. For changed arrival dates, review planned messages and online check-in context.
Verify the final state across booking detail, calendar, availability, guest profile and finance. For a change, the detail must show approved values, the calendar exactly one correct bar, availability released on old segments and consumed on new ones, the guest profile one continuous history and finance the recalculated total with actual payments. For a cancellation, the booking remains traceable with cancelled state, the calendar has no active stay, inventory is restored for eligible nights, history remains linked and fee or refund position is explicit. Reopen each area after a fresh load rather than trusting cached form state. Compare room identifiers and dates closely so a neighbouring unit was not changed. If one layer disagrees, record booking number, expected value, observed value and time, then escalate; do not create another edit to hide the inconsistency. A professional post-check proves both the guest promise and downstream operating effects before the case is declared finished.
Five proofs after the workflow
- Booking detail shows agreed new state and content.
- Calendar contains the correct active period or no cancelled stay.
- Availability is correct for old and new room nights.
- Guest profile keeps the same case and history together.
- Price, payment, fee, refund and balance explain the financial state.
Communicate and hand over the new state
An internally correct change is complete only when the guest receives the right information.Send confirmation from booking context through the intended channel. Include reference, new dates or cancellation, service, price or fee, payment/refund and contact. Verify preview and send state.
Operational handovers reference the same booking. Hotel Nordlicht closes the change only when guest communication, rooms, housekeeping and finance agree; open review remains owned.
Communicate only the verified final state. A change confirmation lists the new dates, nights, room or category, party, services, total, payment position and conditions while identifying the same booking. A cancellation confirmation lists the cancelled stay, effective time, policy outcome, fee, refund status and any remaining action without claiming money has moved when it has not. Use the channel derived from the booking source: direct and manual reservations use email, while OTA reservations remain in their booking conversation. Preview resolved guest and booking values and send once. Record who owns an open refund, room reassignment or follow-up and its deadline. In shift handover, distinguish completed workflow from pending financial action so the next employee does not repeat the cancellation or refund. Ask the guest to report any mismatch against the confirmation, and correct the original record if needed. Communication is complete when hotel, guest and next shift can all reproduce the same current state from one booking number.
