What does on request mean in hotels? Selling with confirmation and answering in time

On request means the sale waits for the hotel's yes. An agency or tour operator asks for a room, but no room is held and no booking exists until the hotel confirms. It sits between free sale, where the agency confirms instantly from an agreed allotment, and stop sale, where nothing is offered at all.

The request arrives at 22:40 on a Friday. The agency's screen says on request, the reservations desk is closed until Monday, and the room is still sitting in the system as available. By Monday the traveler has booked a property that confirmed at once, and nobody at the hotel even knows a sale was lost. This article explains what on request means in a hotel contract, when to use it instead of free sale or a stop sale, how to answer inside a window you can actually keep, and how to record pending requests so a room is never promised twice.

What does on request mean in a hotel contract?#

On request means the hotel keeps the decision: the agency may ask for the room, but the booking exists only when the hotel says yes. The request is a question, not a reservation. The agency passes the dates, room type, board and rate to the hotel and waits for an answer.

Nothing is held by default. Unless the hotel deliberately blocks the room while it decides, the room stays on sale in every other channel at the same time. The traveler has no confirmed booking yet; the agency normally shows the booking as pending until the hotel answers. The hotel replies with a yes, usually carrying a confirmation number, or with a no. A no is a legitimate answer, not a failure: it lets the agency move the traveler to another date or another property while there is still time.

In a contract, on request is a status attached to a rate, a room type or a date range, not a separate product with its own price. The phrase also appears outside hotels, as price on request in shops or salary on request in job ads. In a hotel contract it always means a sale waiting for the hotel's yes.

One point worth knowing: these terms are industry practice, not definitions written in a regulation or a standards document. What binds both sides is the contract wording, so it pays to be exact when you write it.

Free sale, allotment, on request and stop sale: how do they differ?#

The four modes differ in one thing: who holds the room and who is allowed to say yes. Free sale keeps the rooms in the hotel's inventory but authorizes the agency to sell up to an agreed limit at agreed rates, and the agency confirms instantly. Allotment sets a block of rooms aside for the agency; unused rooms return to the hotel at the release period written in the contract. On request holds nothing, or holds with an expiry, and the hotel confirms each booking itself. Stop sale offers nothing for those dates; the channel is closed until the hotel reopens it deliberately.

The modes can be mixed by room type and by date. A hotel can run free sale on standard rooms in March and on request on suites in August. Each mode also has its own failure mode: free sale can oversell, allotment leaks rooms that never sell, on request loses the sale to a slower answer, and stop sale loses the sale entirely.

If you are weighing how much inventory to commit, see allotment vs free sale: how much inventory to commit. For the decision to close a channel entirely, see stop sale in hotels: when to close a channel.

When should a hotel sell on request instead of free sale?#

Use on request when the cost of a wrong yes is higher than the cost of a slow yes. The clearest case is the last rooms on a high-demand date, where an instant confirmation from an agency can push the hotel past its real capacity. Room types with very few units belong here too: suites, connecting rooms, family rooms, accessible rooms. Groups and long stays touch several room types and need a person to look at the whole picture before committing.

A new agency with no booking history, or rates loaded recently and not yet checked, also argue for on request. So do dates where the hotel is waiting on something: a group block that may release, a room out of order, a renovation end date. In each case the hotel is not refusing to sell, it is keeping the decision until it can make it correctly.

The trade-off is time. Every request is a delay, and a traveler who is told to wait often books a property that confirms at once. Keep the on-request scope narrow and its duration short, and review the scope every season: a rate that needed on request last August may be safe for free sale this year.

How fast should a hotel answer an on-request booking?#

There is no industry norm to copy: the reply time is the hotel's own promise, and it belongs in the contract. Define the clock before you promise anything: working hours or calendar hours, and whether weekends and public holidays count. Name who answers, by person or by rota, including nights, weekends and holidays. A promise with no name behind it is not a promise.

Give the agency a channel that works when the office is closed, and state what happens to requests that arrive outside hours. Write the reply time into the contract next to the rate and the release period, so both sides work to the same deadline. If you are loading agency rates into your systems, the contract loading checklist covers where these terms belong.

State what happens when the window passes: the request lapses and the agency is free to sell the traveler something else. Answer fast even when the answer is no, because a quick no lets the agency rebook the traveler and keeps the relationship. Keep the same window for every agency unless there is a written reason, because a shorter window for one buyer is hard to defend later.

What happens to an on-request booking that nobody answers?#

It expires quietly, and the cost lands on both sides. The agency's screen shows the request as expired or cancelled, and the traveler books elsewhere. The hotel keeps the room, but the demand is gone, and nothing in the system records the loss.

The dangerous case is a late yes: the hotel confirms after the room has been sold to another guest, and now two bookings exist for one room. The traveler also remembers the wait. A guest who waited two days for an answer may not try the same hotel again. If your own log shows late answers clustering, expect the same agencies to test you less; only your records can confirm it.

The fix is procedural, not technical: a single queue, a named owner, a deadline on every item and a fixed time of day to clear it. Say in the contract what a lapsed request means, so neither side argues about it later. For where these clauses sit, see a sample hotel and agency contract.

How do you record a pending request so a room is not promised twice?#

Give every pending request an owner, a deadline and a place in the inventory, and make the expiry automatic. Log the request with the agency, the dates, the room type, the board, the rate code, the number of rooms, who received it and when. Decide whether the room is blocked while you decide. If it is, the block needs an expiry time and must be visible in the same inventory that feeds every channel. If it is not blocked, write that in the log, so nobody on the team assumes it is held.

Feed one queue, not three: the email inbox, the messaging app and the agency portal all end in the same list. On expiry, release the block automatically and tell the agency, so the request does not sit open in their system either. On confirmation, convert the request into a reservation in the same system, with a confirmation number, and close the request in the log. Reconcile once a day: list every pending request older than the promised window and clear it before the shift ends.

What do your own records show about late answers?#

Your own log answers the question no industry benchmark can: how many requests did you answer inside the window you promised? Count four things each month: requests received, answered inside the window, answered late, and expired without an answer. Look at when late answers cluster: a particular shift, the evening, the weekend, or the days around public holidays.

Look at which room types and which agencies generate the most requests, because that is where on request is doing the most work. Read the late answers next to the bookings you did not get; the log shows the pattern even when no revenue figure is attached to it. Turn one finding into one change: a rota, a narrower on-request scope, or a shorter window with a faster no.

Keep the log simple enough that the front desk fills it in during a shift. A record nobody completes tells you nothing.

What to do next#

Pick one rate or room type you currently sell on request, write down the reply window and the person who owns the answer, and run it for a month with the log from this article. On request is not a weaker form of selling; it is a decision you keep, and it only works when the answer arrives inside the time you promised.

The AI Otel distribution hub is built, with seed data, and no agency is connected yet: one engine confirms instantly for connected hotels and routes requests to hotels that confirm by hand. That is where the reply promise becomes a mechanism rather than a habit: instant confirmation where the hotel allows it, a routed request where a person must decide. To see how it works, request a briefing.