A caller asks, “What happens if I cancel?” That is a question, not an instruction to change a booking. A useful cancellation record makes the difference visible: which reservation was discussed, what the guest requested, what an authorized colleague completed, and what still needs follow-up. Practise that distinction before working in a live reservations system.
Start with the exact booking and request
Use the hotel's approved identity and authorization checks. Match the property, reservation reference, arrival and departure dates, and relevant guest details. A surname alone can lead you to the wrong stay. If a caller mentions two reservations, write their references separately and establish the requested action for each. Do not extend an instruction for one booking to another.
Read back the scope in plain language: “You are asking to cancel reservation R612 for 6–8 November, and keep R613 for 20–22 November. Is that correct?” This practice sentence assumes the required checks have already been completed. If the answer is unclear, record the question and refer it to the authorized team rather than choosing an outcome.
Keep three stages separate
- Request received: record the time, channel, exact booking and requested action.
- Action verified: record the actual system result, responsible colleague and reference, if provided.
- Confirmation handled: record whether the approved confirmation was prepared, sent or remains pending. A saved draft is not evidence of delivery.
Oracle's reservation-cancellation documentation describes a reason, description, cancellation number and confirmation. Available controls vary. Use your property's current procedure and permissions; this exercise does not prescribe cancellation charges, refund outcomes or software settings.
Worked example: two stays, one cancellation
The following is fictional. At 10:05 on 3 November, a guest asks about cancelling R612, a stay from 6 to 8 November. R613, from 20 to 22 November, is also on the record. The employee notes “information requested; no cancellation instruction yet” and obtains the appropriate explanation through the hotel's procedure. Neither booking is changed at this stage.
At 10:12, after the required checks and explanation, the guest clearly requests cancellation of R612 only. The authorized reservations colleague processes that instruction. At 10:16, the colleague verifies that R612 is cancelled and records fictional cancellation reference C905. R613 is checked and remains unchanged. The note identifies who verified each result, rather than treating the original phone call as proof of completion.
At 10:18, the confirmation is prepared but sending fails. The handover therefore reads: “R612 cancelled, C905 verified at 10:16; R613 unchanged. Confirmation sending failed at 10:18. Reservations colleague to follow up through the approved channel at 10:30.” The cancellation is completed; the communication task is still open. Do not repeat the cancellation merely because the message failed.
Check the record before handover
- Can the next colleague identify the exact property, reference and stay dates?
- Does the note distinguish an enquiry from a confirmed instruction?
- Is each booking's actual outcome recorded separately?
- Are verified results and pending communication clearly labelled?
- Does every unfinished task have an owner and follow-up time?
Practise rewriting “guest cancelled both, email done” using the example's evidence. That sentence gets both the scope and communication status wrong. Keep necessary details in the hotel's approved record, without copying guest information into personal practice notes. Use fictional references when practising with a colleague, then compare their understanding with what actually happened in the example.
O*NET's desk-clerk profile includes reservation work and recordkeeping. Develop those skills with HCA front-office training, then explore hospitality vacancies.
