The guest says the booking dates are wrong: finding out who made the mistake and what to offer

A wrong-date booking is a reservation whose arrival or departure date differs from the one the guest meant. The desk pulls three records, the guest's confirmation, the channel's transmission and the hotel's own history, establishes where the dates were entered, then answers with a free change, a paid change or a written refusal under a policy that does not change by shift.

A guest calls at 21:40, certain she booked 14 to 17 September, and the reservation in your system says 14 to 17 October. She has a confirmation email on her phone. You have a screen in front of you. Before either of you decides who is wrong, someone has to read both. This article gives you the sequence: which records to pull, how to compare them, how to decide between a free change, a paid change and a refusal, and how to log the case so the next shift answers identically.

What does it mean when a guest says the booking dates are wrong?#

It means the dates in the reservation record differ from the dates the guest intended, and there are three separate records to compare before anyone is blamed. A wrong dates hotel booking case is almost never one record against one memory. It is three records, each of which can be right, wrong or stale, and the job of the desk is to establish which of them the guest is actually reading.

The guest's version#

The guest's version lives in the confirmation email, the booking site's app screen, a calendar entry or a screenshot. Ask the guest to forward or show it rather than describing it. A guest who says "I definitely booked September" is reporting a memory; a guest who forwards an email that says 14 to 17 September is showing you evidence, and the two are not the same thing.

The channel's version#

The channel's version is the reservation as the booking site or travel agency transmitted it, with the moment it was created and any later modification the channel made. This record matters because the hotel system usually only holds what the channel sent. If the channel sent October, your screen says October, no matter what the guest selected on the website.

The hotel's version#

The hotel's version is what the property system holds today, plus every edit made after creation, each with a timestamp and a user. A reservation that arrived wrong and was never touched is a different case from one that was edited at the desk on Tuesday, and the edit history is the only thing that distinguishes them.

No single record proves intent. That is why the case is built by comparing them, not by finding the one that must be right.

The three records diverge for ordinary reasons. A date picker that keeps the previous search. A guest booking after midnight for the night that has just begun. A group block loaded with the wrong year. A channel that re-sends a booking after a modification. None of these is dramatic, and all of them produce a guest at the desk saying the dates are wrong.

Separate an error from a change of mind before you go further. A guest reporting an error is asking you to establish a fact; a guest who now wants different dates is making a change request. The two get different answers and different records, and confusing them is how a simple case becomes an argument.

Open with the record, not the fault. The sentence "let me read what your confirmation says" buys the two minutes the whole case needs, and it commits you to nothing.

How do you check a wrong-date booking before you answer?#

Read the three records in a fixed order, write one line per record, and only then call the guest back. The order matters less than the writing: a finding that exists only in someone's head does not survive the shift change.

The four fields to compare first#

Compare the confirmation field by field: arrival, departure, number of nights, room type, rate name, guest name. A one-night difference and a one-month difference look the same until you count the nights. Writing the date out in full with the day of the week makes most month errors visible immediately: a guest who believes she booked "the second weekend of September" will notice that the confirmation says a Tuesday arrival in October.

Pull the channel record next: the reservation number the channel issued, the creation time, and whether the channel modified it after creation. Then pull the message history: pre-arrival emails, the guest app, messaging apps, the call log. A guest who wrote "we arrive on the 14th" three weeks ago has given you evidence you did not have to ask for, and it changes the case.

Reading the audit trail#

Check the hotel's own audit trail before you speak. A reservation edited by the desk is a different case from one that arrived wrong, and the trail says which it is. Check the clock and the calendar too: the booking date, the stay date and the day of the week. A booking made at 00:30 for a stay starting that same night is a frequent source of one-night errors, because the guest was thinking of "tonight" and the system was counting from the new day.

Write the finding in one line per record with its source, before you speak to the guest. The written finding is what makes the second shift give the same answer, and it is what you will rely on if the case turns into a dispute. A confirmation that never printed the day of the week invites exactly this dispute, so note that too; it is a fixable weakness in your own guest path. For what a complete confirmation should contain, see what a hotel reservation confirmation must say, with a template.

What can actually be changed: the same rate, other dates, another room?#

What can be changed depends on three things in this order: whether the new dates have inventory, what the rate plan's rules allow, and who owns the reservation. Skipping the order is how desks promise things they cannot deliver.

Inventory first, price second#

Check inventory before promising anything. A sold-out night ends the conversation about that night, not about the booking, so move to the nearest dates that work. Once the nights exist, read the rule attached to the reservation, not the rate's marketing name. A rate sold as nonrefundable usually carries conditions on changes; a flexible rate usually does not. The rule is in the reservation, and it is the only thing the desk may quote.

The cleanest move is the same rate on other dates with the same room type, because nothing about the price has to be recalculated. When the guest's real complaint is the room rather than the date, a room change on the same dates is often cheaper for everyone than a date change. Say the price difference before the guest agrees, not after: moving into a higher season changes the number, and a number discovered later turns a solved case into a complaint.

Moving the booking to a different guest name is a separate procedure with its own checks, and it is not a way to fix a date error; see changing the name on a hotel booking for that procedure. Know the ceiling of the shift: the desk can apply the rate rule, a manager can go beyond it, and nobody can waive a penalty the channel set.

Free change, paid change or refusal: how do you decide?#

Decide with three tests in order: who made the error, how much notice the hotel has, and what the rate and the channel allow. Then apply the same answer to every similar case.

The three tests#

Test one, the record: if the dates the hotel or its channel transmitted differ from the dates the guest confirmed in writing, the error sits on the hotel side of the line and the change is free. Test two, notice: a change requested weeks before arrival costs the hotel almost nothing, while a change requested at 22:00 for a stay that starts tonight costs a room-night that will probably not be resold. Test three, the rule: the rate plan and the channel's terms set the ceiling, and the guest should be told whether the desk is applying that ceiling or a manager is going above it.

For example, a guest who booked 14 to 17 October instead of September, calling four weeks ahead on a flexible rate, is a free change with a price difference if the seasons differ. The same guest calling on the arrival day on a nonrefundable rate is a paid change or a refusal with an alternative. The example is illustrative, not a rule.

Who may go above the policy#

Write the policy as three rows and post it at the desk. The point is that the answer does not depend on who is on shift or how tired they are. Escalate rather than improvise when a case sits between two rows: an improvised answer on the night shift becomes tomorrow's precedent, and the guest who receives a different answer the next morning will remember both.

What do you say on the phone and what do you put in writing?#

Say the same three things in both places: what the record shows, what you can do, and by when. Anything said on the phone and not repeated in writing did not, for practical purposes, happen.

Sentences to use#

On the phone, acknowledge the situation without admitting a fault you have not established. "I have your confirmation in front of me" is honest and calming at the same time. Give one concrete option and one alternative, never a menu of five: a guest choosing between two clear outcomes decides faster than one asked to think of options. Treat the call as a recovery conversation, not a verification exercise, because the guest's memory of the hotel is being formed during these four minutes. For the wider routine, see a recovery routine for guest complaints at the front desk.

Sentences to avoid#

Avoid "the system did it", "you must have clicked" and "there is nothing I can do". Each of them ends the conversation and starts a review. In writing, be shorter than the phone call: the dates in full with the day of the week, the change reference, the price difference if any, and the deadline for the guest to confirm. Never send a written refusal that contains only the word no; a refusal carries the reason, the rule it comes from, and the alternative you can still offer. Confirm the change back to the guest in writing and ask for a one-line acknowledgment: the acknowledgment is what closes the case file.

What changes when the guest booked through an agency or a booking site?#

The channel that took the booking owns the change, and the hotel's job is to answer fast and in writing so the channel can act on a clear request. This is the main structural difference from a direct booking: the hotel's good will is necessary but not sufficient.

Finding the channel of record#

Find the channel of record from the reservation's source field, not from the guest's memory of which site they used. Guests often name the site they searched on rather than the one that took the money. The hotel can usually accept a change and tell the channel it accepts. It usually cannot rewrite the channel's terms, and it should not promise an outcome the channel has not confirmed.

Timing matters more than wording. The channel's own change window closes before arrival, so a request that reaches the hotel after that window has to go back through the channel as a new request. When the hotel itself has to move or cancel a confirmed booking, that is a different procedure with its own steps and its own record; see when the hotel has to cancel a confirmed booking.

What to send the channel#

Send the channel four things and nothing else: the reservation number, the old dates, the new dates, and the guest's written request. Add the price difference if the hotel is quoting one. Whether a guest has a right to a refund or a free change is a question of the booking contract and consumer law, not something the desk should decide at the counter; confirm dates, penalties and your own case with an accountant or legal adviser.

How do you record wrong-date cases so every shift answers the same?#

Log four fields on every case and review them once a month with reservations and front office in the same room; the pattern tells you where the mistakes are made. The log does not need software, only consistency.

The four fields#

Field one, the channel: the hotel's own website, a booking site, an agency, a call, a walk-in. Field two, the screen or step where the dates were entered, as far as the records allow; this is the field that turns a complaint into a fix. Field three, the kind of difference: a month, a day, a year, a missing night, an extra night, because a month error and a one-night error have different causes and different fixes. Field four, the outcome: free change, paid change, refusal, cancellation, and who approved it.

What the monthly review should look for#

Review monthly and look for repetition rather than volume. One channel or one rate plan appearing again and again is a signal; a scattered spread of single cases usually is not. Feed the finding back into the guest's path: a confirmation that prints the day of the week, a pre-arrival message that repeats the dates in full, a booking page that shows the selected dates next to the price before payment. Keep the log internal: it exists to make the hotel's own answers consistent, not to be quoted as a performance figure.

What to do next#

Write the three-row policy and the four-field log this week, post the policy at the desk, and read the first month of cases together. The parts fit in one order: establish the record, check what can move, apply the same three tests, say it in the same words on the phone and in writing, and log the case so the next shift answers identically.