Key points
- Start with a confirmed event and the latest stay record.
- Treat future tasks differently from work already in progress.
- Test that a repeated event cannot trigger a second delivery.
Identify the authoritative change
Front desk confirms the event, effective date and reservation concerned. An unaccepted extension request does not have the same effect as a confirmed extension. Likewise, an expected arrival does not become a no-show merely because the guest has not arrived at the anticipated time.
Connect each change to the stay reference and its version or confirmation time. A room number alone is insufficient because it can change. The operational owner compares the updated requirement with existing tasks. This extends front desk and housekeeping coordination with an explicit rule for events that alter work already planned.
Adapt the event-impact table
| Confirmed event | Future task | Work already started | Final check |
|---|---|---|---|
| Extension | Reschedule departure; define agreed stayover service | Inform the attendant and reassess the service | No departure task remains active for the old date |
| Cancellation | Cancel preparation no longer required | Stop only authorised actions; retain completed-work history | Recover prepared items where necessary |
| Confirmed no-show | Review arrival-related tasks | Check actual room condition before changing preparation | Front desk decision and room state agree |
| Room move | Redirect stay-related requests | Obtain acceptance of the new destination | Check both original and destination rooms |
Here, cancellation means stopping future execution with a traceable reason. Erasing completed-work history makes it harder to explain consumed supplies or a delivery already dispatched. When two tasks represent the same requirement, choose a primary reference and mark the other as a duplicate rather than counting two services.
Apply the decision to the right people
The scheduling owner first checks whether the task is unassigned, accepted, in progress or complete. An unassigned task may be rescheduled directly under local permissions. An accepted task requires notification to its owner. Work in progress needs an explicit decision about what happens next, not a silent change on a board that the attendant may not be viewing.
Before using this table, ask the administrator to verify what your systems actually change after each event: room status, due date, assignment or notification. Record the actions that remain with the team. This proposed procedure does not assume any particular RoomChecking synchronisation capability; validate each scenario against your own configuration before use.
Test repeated and delayed events
- Create a test scenario with a stay, a scheduled task and an identified assignee.
- Apply a confirmed extension and verify the new date and the original task.
- Present the same event again: it should not launch an additional service.
- Present older information afterwards and verify that it does not replace the latest confirmed state.
- Repeat with a task already under way and check what notification reaches the assignee.
These are intended process outcomes, not guaranteed application features. If a system cannot support the expected behaviour, agree a manual check or usage restriction with the administrator. Record the exception clearly enough that shift teams understand when an apparent update still needs review.
Illustrative example: an extension received twice
Room 515 was due to depart this morning. Front desk confirms another night after the departure task has already been accepted. The scheduling owner informs the attendant, cancels the planned departure service with its reason and arranges stayover service according to the guest’s agreement. The new departure is scheduled for the following day.
The same change then arrives through a second channel. The owner finds the matching stay reference and the confirmation already processed. They update the history without creating another stayover task. The booking-change action is complete only when the attendant has received the instruction and the obsolete task can no longer be executed by mistake.
Frequently asked questions
Should cancelled tasks be deleted?
Keep useful evidence of the cancellation and any completed work under your data policy. The active view can hide a cancelled task without losing the reason or implying that no preparation ever happened.
What if two systems show different versions?
Identify the latest decision confirmed by front desk and pause unexplained automatic changes. The administrator or designated owner investigates the difference. Do not reconstruct the stay from whichever screen looks newest without checking where its information originated.
