Turnaways and lost requests: recording the bookings your hotel could not take

A denial is a request the hotel refused: sold out, restricted or closed. A regret is a request the guest refused: price, room type or policy. Record each one when it happens, with a fixed reason code plus the arrival date, nights and rate quoted, then read the log weekly to test rates and restrictions.

A guest calls on a Friday for two nights in August, hears the rate and books elsewhere. Nothing in the system records that the call happened. Next year's budget is built from the rooms that sold, so the hotel plans as if it had never been asked. This article explains how to stop that loss: what hotel denials and regrets are, how to record them in seconds with a form staff will actually use, and how to read the log so it supports rate, restriction and opening-date decisions without ever being mistaken for guaranteed demand.

What does unconstrained demand mean for a hotel?#

Unconstrained demand is the number of rooms you could have sold on a date if nothing had stood in the way: no sold-out night, no minimum stay, no closed channel, no price the guest refused.

You never see it directly. You see rooms sold in the hotel system, plus whatever somebody wrote down about the requests that were refused. The estimate is built by people from records, not produced by software.

Three inputs feed it: rooms sold, refused requests from the log, and the restrictions that were in force on each date, such as a minimum stay, a closed-to-arrival rule, a stop-sell or a closed channel. Keep the two words apart. Constrained demand is what your limits allowed you to sell. Unconstrained demand is the counterfactual you are trying to describe.

It matters because a budget, a rate fence or an opening date built only from sold rooms assumes the hotel could never have sold more. That assumption is comfortable and usually wrong. The estimate is always approximate and always arguable, so treat it as a direction of travel for decisions, never as a number to put in a forecast as revenue.

One rule makes the whole exercise possible: record the request at the moment it happens. Nobody reconstructs a Tuesday afternoon phone call three months later. For the wider vocabulary around this, see revenue management terms explained, from pickup to displacement.

What is the difference between a denial and a regret?#

In a denial the hotel said no, because it was full, restricted or closed. In a regret the guest said no, because the price, the room type or the policy did not suit.

Denials test your capacity and your restrictions. Regrets test your price and your product. Mixing them in one column makes the log useless, because the two call for opposite actions: a denial may call for loosening a rule, a regret may call for changing a price.

Denial reasons worth separating: sold out, closed date, minimum stay, closed to arrival, no such room type or bedding, group block held, channel closed, contract or credit issue. Regret reasons worth separating: rate too high, room type or bedding not wanted, dates inflexible, cancellation or prepayment policy, pet or child policy, a competitor offer the guest preferred.

Add a third bucket that is neither: the request nobody answered. A call that rang out or an email that was never quoted is a service failure, not demand information, and it should be counted separately so it can be fixed.

A request can carry both. A guest who asks for three nights, is told about a five-night minimum and declines is a denial caused by a restriction and a regret caused by the same restriction. Code the cause, not the outcome. Reason codes must be a short fixed list chosen from a dropdown: free text cannot be counted, and an uncountable log is a diary.

How do you record a lost request in seconds?#

Put a short lost-request form on the screen your staff already use, with six fields and a fixed reason list, and make filling it part of closing the conversation rather than a separate task.

On the phone, add one sentence after the refusal: ask what the guest was looking for so the hotel can plan for it. Many guests answer, and it takes seconds. At the desk, the same form. A walk-in turned away at eleven at night is the cleanest denial a hotel ever gets, because the guest is standing there with dates and a budget.

For email and messaging, use a shared inbox label or a lost status on the enquiry, so the request does not sit unanswered in a folder and disappear. Booking-engine search and quote logs, where your provider keeps them, are a separate and much noisier source: many searches are curiosity, not requests. Keep them in their own column and never add them to staff-entered lines.

Record the request, not the person. No identity numbers, no payment details, no preferences beyond the room type asked for, and a stated retention period for the log. Guest data protection applies to a lost enquiry exactly as it applies to a confirmed booking; for the detail, see KVKK for hotels: notices, consent, staff access and retention.

Do not capture identity numbers, payment data or guest preferences beyond the room type.

Which dates, room types and prices turn guests away?#

Read the log by date first, then by reason code, then by the gap between the rate you quoted and the rate that eventually sold for the same night.

Start with dates and stay patterns. One refused Saturday is noise. The same Saturday refused in four consecutive weeks, or a run of two-night requests against a five-night minimum, is a signal you can act on.

Then count reason codes. If most denials are coded sold out, the question is price and capacity. If most are coded to a restriction, the restriction itself is the problem, and it is the cheapest thing in the building to change. Self-inflicted denials deserve their own line: closed-to-arrival dates, minimum stays longer than the demand pattern, a channel switched off and forgotten, a rate loaded on one channel and not another.

Compare the quoted rate with what sold. Many regrets at one price point, on dates that did not sell out, says the fence is in the wrong place, not that the market is weak. Look at length of stay and party size: a family of four refused because no room takes four is a product question, while a two-night request refused by a five-night minimum is a lost booking you can count.

Check the channel. The same night can be open on one channel and closed on another, and the log is often the only place that shows it. Respect small samples throughout: three requests are an anecdote and a prompt to look further, not a conclusion to take to the owner.

What decisions does a turnaway log support?#

It supports the decisions that are otherwise made on instinct: rates and fences, minimum stays, group acceptance, room-type mix and opening or closing dates.

On rates, repeated regrets at one price point on soft dates suggest testing a different rate or a different condition, such as a non-refundable or longer-stay price, rather than a blanket discount. On minimum stays and closed-to-arrival rules, denials coded to a restriction tell you how many requests the rule cost. That is a count, not a lost-revenue figure, and it is enough to reopen the question.

On groups, a group request refused for space is a displacement question, and the log gives you the dates and the size to run it properly; see group displacement analysis: should your hotel accept the group?. On opening and closing dates, shoulder-week denials and regrets are the raw material for a week-by-week contribution test, because they show demand on the edges of the season that a sold-rooms report never shows. The method is described in when should a seasonal hotel open and close? A week-by-week contribution test.

Room-type mix and bedding belong in the annual plan rather than the weekly meeting: repeated requests for twins, connecting rooms or rooms that sleep four are a capital question, not a pricing one. Regrets clustered on one agency's rates point at the contract, not at the market.

Give every decision a review date. The log then answers the only question that matters afterwards: did the change reduce the requests coded to that cause?

What are the limits of a lost-business log?#

The log is a biased sample of what people had time to write down, and it must never be mistaken for guaranteed demand or turned into a lost-revenue figure.

Shoppers, competitors checking rates and people planning next summer are not demand. A repeated identical request from the same source is one request, not four. The same guest often asks twice, by phone and then online, so deduplicate on arrival date, nights and room type, not on the guest's name, which you may not have and do not need.

Staff record what they remember to record. Price regrets get logged because they feel like information; sold-out denials get skipped because they feel like good news. Check the denial count against how full those dates actually were. The log is also biased toward the channels where staff had time to write: the phone and the desk are usually well covered, the booking engine and messaging apps often are not.

Turned-away requests are not bookings. They do not enter a budget, a forecast or a report as revenue, and no lost-revenue figure should be calculated from them or circulated. Unconstrained demand is a counterfactual, so it cannot be observed by software; people estimate it from records, and any tool that claims to know what you would have sold should be treated with suspicion until it shows its working.

What should the weekly revenue meeting do with it?#

Fifteen minutes, a fixed slot before the pickup review, three counts, one decision and one check on last week's decision.

Open with the check: did last week's change reduce the requests coded to that cause? If not, revert it or look again. Then read the counts, make one decision per meeting and write it down with an owner and a review date. A log that produces five ideas a week produces none.

Whoever answers the phone should be in the room. A log maintained only by the revenue manager misses the front desk, which is where most denials are born. Keep the room-type and capital questions for a monthly review, because they need the owner and the maintenance budget, not a weekly slot.

The habit matters more than the tool. A notebook with six columns, kept every day, beats a system nobody opens.

What to do next#

This week, add a lost-request line to the screen your reservations team already uses: six fields, five reason codes, one sentence asking the guest what they were looking for. Then put the count on the weekly agenda and give every decision a review date. The log turns a hotel's refusals into a record it can argue from, which is the only way unconstrained demand stops being a guess made in a budget meeting.