Request to Book

Request to book is a reservation model where a guest submits a booking request for specific dates, and the host must actively review and approve it before the booking is confirmed. Unlike instant booking, nothing is finalised the moment the guest acts. The host has a window, commonly twenty four hours on most platforms, to accept or decline before the request expires.

Request to book gives a host a genuine checkpoint before a stranger is confirmed into their property. This can matter for properties with specific local considerations, group bookings that need verification, or owners who simply prefer a moment to review who is staying before locking in a reservation.

This page explains exactly how request to book works, why some Indian hotels and homestays deliberately choose it over instant booking, how to run it well without losing bookings to slow response times, and the mistakes that turn a useful screening step into a source of lost revenue.

What Request to Book Actually Is

The basic flow starts with a guest selecting dates and submitting a request, usually with payment details attached or a payment method authorised but not yet charged. The host then reviews the request and either accepts it, turning it into a confirmed booking, or declines it, releasing the dates back to availability.

Most platforms enforce a response window on hosts using request to book, typically twenty four hours, after which an unanswered request either expires automatically or is auto-declined. This time limit exists specifically to prevent the slow response problem that makes request to book frustrating for guests when handled poorly.

Payment handling varies by platform. Some systems only capture payment once a host accepts, avoiding any charge on a declined request. Others authorise or hold funds at the time of request and release them if the host declines. Understanding which model a given channel uses matters for how a property communicates with guests during the review window.

Request to book does not have to apply uniformly across a property. Many properties use it selectively, perhaps only for larger group bookings, unusually long stays, or specific room types, while offering instant booking for standard individual and couple reservations.

The dates a guest requests are typically held, at least briefly, while the host reviews, meaning request to book still affects real time availability even though the booking is not yet confirmed. This is different from a casual enquiry, which does not hold inventory at all.

Auto-decline behaviour differs across platforms, and it is worth understanding the specific rules for each channel a property uses. Some systems auto-decline silently, others send the guest a notification explaining the request expired, and a few penalise a host’s response rate metric for every unanswered request, regardless of the eventual outcome.

Request to book can also include a messaging step before the formal request, where a guest asks a question first and only submits the actual booking request once satisfied with the answer. This pre-booking conversation is one of the genuine advantages request to book offers over instant booking, since it creates a natural moment for clarification that instant booking skips entirely.

Guests sometimes confuse Request to Book with a simple enquiry form, but the two work quite differently on the back end. An enquiry just starts a conversation, with no dates blocked and no commitment on either side. A Request to Book submission, by contrast, places a soft hold on the selected dates the moment it is submitted, which is exactly why hosts need to respond quickly. Leaving a request pending for days ties up inventory that could otherwise be sold, which is a cost many small property owners do not immediately account for when they choose this booking mode.

Why Request to Book Matters for Indian Hotels and Homestays

Consider a homestay in Srinagar, Kashmir, offering both houseboats and land-based rooms. The owner deliberately kept request to book active for houseboat stays, since group composition and duration needed a quick conversation before confirming, while switching standard homestay rooms over to instant booking for faster conversion.

This selective approach let him retain a screening step exactly where it mattered most, without slowing down the majority of his bookings. Guests booking standard rooms got the fast, modern experience they expected, while houseboat guests, where a short exchange genuinely helped set expectations about the stay, went through request to book.

Request to book matters for properties navigating specific local or seasonal considerations, such as an area affected by weather-related access issues during certain months, where a host benefits from confirming a guest understands conditions before locking in a booking rather than dealing with a dispute after arrival.

It also matters for properties that host large groups, where verifying the actual number of guests, their purpose of stay, or specific requirements before confirming avoids problems that are much harder to resolve once a booking is already locked in under instant booking.

Response time is the single biggest factor in whether request to book helps or hurts a property. A host who responds within an hour captures nearly all the benefit of screening guests without losing many bookings to impatience. A host who takes most of the twenty four hour window regularly loses guests who book a competing, faster-responding property in the meantime.

For new properties still building a review history and reputation on a platform, request to book can also serve as a deliberate, temporary choice, giving the owner a chance to personally welcome and set expectations with early guests before eventually switching to instant booking once operations and confidence are established.

There is a guest-side consideration too. Some travellers specifically prefer request to book properties, associating the model with a more personal, attentive host, particularly for boutique stays, homestays and properties where the human element of hospitality is part of the appeal rather than an inconvenience to be automated away.

Request to book can also help a property manage capacity during unusually high demand periods, such as a local festival, where an owner wants a moment to confirm logistics like parking, group size or specific arrival timing before locking in a booking that could otherwise create an operational bottleneck.

Imran’s houseboat is a good example of how Request to Book plays out in a competitive, seasonal market. During the Srinagar tourist season, he receives several requests a day for the same set of dates, and because only one guest can actually stay, he uses the review window to compare group sizes, trip purpose, and any special requests before accepting the one that fits best. A homestay running on Instant Booking would not have this flexibility, since the first click would lock the dates regardless of fit.

There is also a trust angle that matters more in India than platforms sometimes acknowledge. Many guests travelling to smaller towns and hill stations feel more comfortable exchanging a few messages with the host before paying, especially first-time visitors to a homestay format they have not used before. Request to Book gives them that reassurance without forcing a phone call, which keeps the process fast while still feeling personal, something that matters a great deal for repeat bookings and word-of-mouth referrals.

It helps to remember that request to book is not a fixed, one-time setting. Many properties start with it applied broadly while they are still building confidence in their operations, then narrow it down to only the room types or seasons where manual review genuinely earns its keep, moving everything else over to instant booking once the process feels predictable.

How Request to Book Works, Step by Step

Request to book follows a consistent flow from submission to resolution.

• A guest selects dates and submits a booking request, typically with payment details attached but not yet charged.
• The requested dates are held, at least temporarily, reducing but not eliminating their visibility to other guests during the review window.
• The host receives a notification and reviews the request within the platform’s allowed response window, commonly twenty four hours.
• The host either accepts the request, confirming the booking and capturing payment, or declines it, releasing the dates back to full availability.
• If the host does not respond within the window, the request typically expires or is automatically declined, depending on the platform.
• The guest is notified of the outcome immediately, whether accepted or declined, so they can book elsewhere quickly if needed.

Request to Book vs Instant Booking vs Booking Link vs Direct Booking

Term	What It Actually Means	Example	Who Controls It
Request to Book	A booking request that a host must approve before it confirms	Host reviews and accepts within a 24 hour window	Host, manually
Instant Booking	A reservation that confirms immediately without host approval	Guest pays and receives confirmation within seconds	Automated, guest-driven
Booking Link	A specific shareable URL pointing to a bookable page	A link shared on Instagram or WhatsApp	Owner, shared per channel
Direct Booking	A booking made through the property’s own channel, not an OTA	A guest books via the property’s own website	Property, without OTA involvement

If you are deciding which to switch on, we work through which one to use on which dates in detail.

What a Good Request to Book Process Should Include

A well run request to book process is not complicated, but it does require a few things to be genuinely in place.

• A clear internal process for reviewing requests quickly, ideally within an hour or two rather than waiting close to the response deadline.
• Notifications set up so the host or reservations team is alerted immediately when a new request arrives, on mobile as well as desktop.
• A defined set of criteria for what makes a request worth declining, so decisions are consistent rather than based on mood or guesswork.
• Selective use of request to book only where it genuinely adds value, such as group bookings or specific room types, rather than applying it everywhere by default.
• A polite, clear decline message template ready to use, since a vague or abrupt decline can hurt a property’s reputation on some platforms.
• Awareness of the platform’s specific payment handling rules for request to book, since this varies between charging at request time and charging only after acceptance.
• A backup person who can review and respond to requests when the primary owner is unavailable, to avoid missed response windows.
• Regular review of how many requests are lost to slow response time, since this is a measurable and fixable problem.
• A plan for eventually transitioning specific room types to instant booking once confidence and operational maturity allow it.
• Clear, upfront property information available to guests before they submit a request, so fewer requests get declined due to avoidable mismatches.
• A clear understanding of each platform’s specific auto-decline behaviour and its effect on response rate metrics.
• A pre-booking messaging option enabled where the platform supports it, letting guests ask questions before submitting a formal request.

Common Mistakes Property Owners Make With Request to Book

Responding too slowly. Waiting close to the full response window before accepting or declining a request is the single most common way request to book loses bookings to faster-responding competitors.

Applying request to book to every room type by default. Using request to book everywhere, without considering which room types or situations genuinely benefit from manual review, adds friction without adding real value.

Declining requests without a clear reason. An abrupt or unexplained decline can damage a property’s reputation and, on some platforms, its response rate metrics, even when the decision itself was reasonable.

Not setting up mobile notifications. A host who only checks requests from a desktop computer once a day will miss the response window regularly, especially during busy periods.

Inconsistent decision criteria. Accepting or declining requests based on inconsistent, undocumented reasoning makes it hard to train other staff to help with reviews and can appear arbitrary to guests.

Ignoring the impact on OTA search ranking. Several platforms weigh response rate and response time in their search algorithms, so a pattern of slow responses under request to book can quietly hurt visibility beyond just the individual lost booking.

Never revisiting the decision to use request to book. Some properties keep request to book purely out of habit long after the specific concern that justified it, such as a lack of trust in early operations, has been resolved.

Not using the pre-booking messaging option where available. Skipping a platform’s built-in messaging feature removes a natural opportunity to answer guest questions and reduce avoidable declines before a formal request is even submitted.

Not setting guest expectations upfront. When a guest is not told upfront that a response can take a few hours, a delayed reply can feel like poor service even when it was well within the platform’s allowed window. A short line in the listing description or an automated acknowledgement message closes this gap easily.

Running Request to Book Well: Step by Step

Managing Request to Book Well: A Practical Checklist

• Are requests being reviewed and answered within an hour or two, rather than close to the deadline?
• Is request to book applied only where it genuinely adds value, not uniformly by default?
• Are mobile notifications enabled so new requests are seen immediately?
• Is there a documented, consistent set of criteria for accepting or declining requests?
• Is a polite decline message template ready to use when needed?
• Is there a backup person who can respond to requests when the primary owner is unavailable?
• Is response time being tracked and reviewed regularly for missed opportunities?
• Is the platform’s specific payment handling model for request to book understood clearly?
• Has the property considered transitioning any room types to instant booking as confidence grows?
• Is property information clear enough upfront that avoidable request declines are minimised?
• Is the pre-booking messaging feature, where the platform supports it, being used to answer guest questions before a formal request is submitted?
• Is each platform’s specific auto-decline behaviour and its effect on response rate metrics understood clearly?
• Does the listing description or an automated message let guests know a response is not instant?

Request to Book in Action: A Short Example

Imran runs a homestay in Srinagar, Kashmir, offering both traditional houseboats and land-based rooms. He kept request to book active specifically for houseboat stays, where group size and trip duration benefited from a short exchange before confirming, while switching his standard rooms to instant booking.

For the houseboat, a quick message back and forth before confirming has genuinely helped, guests get their questions answered and we get a chance to explain what to expect. But we learned the hard way that speed matters even within request to book. Once we started responding within the hour instead of checking once a day, we stopped losing houseboat bookings to other properties that simply answered faster.

Imran, homestay, Srinagar, Kashmir

Frequently Asked Questions

---

This page is part of our glossary on hotel and homestay technology. To understand the alternative approach, read our explanation of instant booking, or see how availability stays accurate during a review window in our page on room inventory. For broader guides on running a compliant, well-managed property in India, visit our Resources section.