Instant Book vs Request-to-Book Models

By Brian Tr · Updated Oct 7, 2026

Every marketplace has to answer a small question that turns out to shape the whole product: when a buyer says yes, who has to say yes back? In some marketplaces the answer is nobody. The buyer clicks, pays, and the booking exists. In others the buyer submits a request and waits while the seller decides.

The first model is usually called instant book. The second is request-to-book. Neither is better in the abstract. They trade buyer speed against seller control, and the right choice depends on what's being sold, how much the seller has to lose, and what the platform can do to protect them. This article defines both models, walks through how each one changes acceptance rates, cancellations, and search, covers the hybrids that most mature marketplaces end up with, and shows which types of marketplace lean which way.

Platform rules change, so every policy described here is as of 7 October 2026, when we read the cited pages. Treat them as dated snapshots, not permanent facts.

Key Facts

• On Airbnb, listings showing a "Confirm and pay" button can be booked instantly, while listings showing "Request to book" need the host's approval first (Airbnb Help Center, checked 7 Oct 2026).
• Airbnb says that for a request, the host will typically respond within 24 hours, and that outside India the guest isn't charged if the host declines or doesn't respond in that window (Airbnb Help Center).
• In a 2015 field experiment covering roughly 6,400 Airbnb listings across five cities, inquiries from guests with White-sounding names were accepted about 50% of the time versus about 42% for guests with African-American-sounding names (Edelman, Luca and Svirsky, AEJ: Applied Economics, 2017).
• The same paper's abstract reports applications from guests with distinctively African-American names were 16% less likely to be accepted than identical guests with distinctively White names (Edelman, Luca and Svirsky).
• Airbnb's own search-ranking team describes a ranking ecosystem that includes models predicting the likelihood of a host accepting a guest's request (Haldar et al., arXiv 1810.09591).
• In November 2023 Turo announced that, starting in the first half of 2024, guests would be able to book all trips with Book Instantly (Turo Field Notes).

The two models, defined

Instant book means the seller commits in advance. They set rules once (price, calendar, minimum stay, who can book), and any buyer who meets those rules gets an immediate confirmation. The seller never sees an individual transaction before it happens.

Request-to-book means the seller decides per transaction. The buyer submits dates and details, the seller reviews the request, and the seller accepts or declines. Until then the booking doesn't exist.

Airbnb's help center shows both on one page. Its guide to booking a home says that if a buyer sees "Confirm and pay," they can book instantly, and if they see "Request to book," they can add payment info, review the policies, and message the host before submitting (Airbnb Help Center, article 85). Its Instant Book article adds the buyer-side conditions: the guest must have completed account setup and the reservation must be under 31 nights (Airbnb Help Center, article 523).

Notice what's different about the two flows, because it's the whole story. In request-to-book, there's a gap between the buyer's intent and the seller's commitment. That gap is where the seller gets control, and it's also where the buyer gets stuck.

What each model optimizes

Think of the gap as having a price on each side.

For the buyer, the gap costs time and certainty. A traveler who needs a place tonight can't wait a day. A buyer comparing five listings has to hold five pending requests, or send them one at a time. Airbnb's own guidance reflects this: its own summary of Instant Book says it lets guests who meet a host's requirements book immediately instead of sending a request for approval (Airbnb Help Center, article 85, related articles), and its guest page calls the option "especially convenient for last-minute trips" (Airbnb Help Center, article 523).

For the seller, removing the gap costs control. Without it they can't read a profile, ask a question, or decline a stay that doesn't fit. That matters most when a bad transaction is expensive: a stranger in your home, a stranger driving your car, a project that needs a specific skill. The more the seller has to lose, the more they'll want the gap back.

Platforms feel the same trade at the aggregate level. Removing the wait plausibly helps conversion, since fewer buyers have to hold a pending request, though you should test that rather than assume it. The reverse risk is real too: some sellers won't list at all under a model where strangers book automatically. For how that fits the broader funnel, see our reference on marketplace conversion.

Acceptance rates, cancellations, and the cost of "no"

In a request model, the seller's decision becomes a variable the platform has to manage. Two things happen.

First, acceptance isn't guaranteed, so a request is a probability, not a booking. Airbnb's search-ranking researchers say so directly: the ranking model they describe is part of an ecosystem of models that includes ones predicting the likelihood of a host accepting the guest's request for booking (Haldar et al., "Applying Deep Learning To Airbnb Search"). That's a design consequence of request-to-book. If a host is likely to decline a given guest, showing that listing to that guest wastes both sides' time. Instant book removes that prediction problem, because acceptance is already settled by the rules.

Second, the seller's response behavior becomes something to measure and govern. Airbnb tells guests that a host will typically respond within 24 hours and that, outside India, a guest isn't charged if the host declines or doesn't respond in that window (Airbnb Help Center, article 85). That sentence contains a whole policy: requests expire, the buyer is released, and the platform doesn't take payment until the seller commits. Without a rule like that, a slow seller could freeze a buyer's money or plans indefinitely.

Cancellations move too, but in a more subtle way. Under instant book, the seller never agreed to this specific buyer, so any mismatch shows up after confirmation, as a cancellation or a dispute. Under request-to-book, mismatches are filtered out earlier, as declines. The same underlying mismatch lands in a different bucket. A platform that switches models shouldn't expect the problem to vanish. It relocates, from "declined requests" to "cancellations and complaints," and the platform needs a policy for the new place it shows up. That's a trust-and-safety design question as much as a conversion one, and it's why sellers on instant-book platforms are typically given screening tools and some way to cancel without punishment. Protection and recourse for the seller are often the other half of that bargain, and they depend on how well the platform controls supply quality.

The discrimination finding that pushed the industry

The strongest piece of evidence on why request-to-book carries a hidden cost comes from a field experiment on Airbnb. Benjamin Edelman, Michael Luca, and Dan Svirsky created guest accounts that were identical except for the name, with one set of distinctively African-American names and one of distinctively White names, and sent roughly 6,400 messages to hosts between 7 and 30 July 2015 asking about availability (Edelman, Luca and Svirsky).

The result: White-sounding names were accepted roughly 50% of the time and African-American-sounding names roughly 42%. The authors' stated headline is a 16% lower likelihood of acceptance, and they report the pattern held across hosts of all sizes, concentrated among hosts who had never had an African-American guest.

The authors tie this to market design. They note that Airbnb lets hosts accept or reject a guest after seeing a name and often a picture, and that platforms like Amazon, eBay, and Expedia offer little scope for discrimination because sellers effectively pre-commit to accept all buyers. Their suggested remedy included expanding Instant Book, which they say would eliminate the opportunity for discrimination and also offer convenience benefits for guests. They also observed that, in their sample, only a small subset of hosts allowed instant booking. The paper adds that on the day it was accepted for publication, Airbnb announced planned changes including a goal of increasing the proportion of hosts offering Instant Book.

Two cautions. This is one platform, one year, and one type of inquiry, so it's evidence about request-based models in a setting where hosts see personal identity, not a universal law. And the paper explicitly frames the whole issue as a tradeoff for market designers: information that helps sellers decide can also enable bias. Request-to-book isn't inherently discriminatory. It gives sellers a discretionary decision, and discretion is where bias can enter.

Turo made a similar argument in plain terms. Its 2023 announcement said that host screening of guests can be discriminatory, which isn't behavior it wants in its community (Turo Field Notes).

Hybrids: control without the gap

Most marketplaces end up somewhere between the poles. Four patterns are common.

1. Instant book with requirements. The seller pre-commits, but only to buyers who meet conditions. Airbnb describes Instant Book as letting guests who meet a host's requirements book immediately (Airbnb Help Center, article 85, related articles). The control moves from judging each person to setting criteria once. This keeps the speed and gives the seller a filter, though what a platform lets sellers require (and whether those requirements themselves create bias) is a design decision worth auditing.

2. Instant book with carve-outs. The platform falls back to approval where an instant confirmation wouldn't be safe. Airbnb's example is last-minute arrivals: if a guest books within two days of check-in and wants to arrive outside the host's check-in window, the host receives a Request to Book and decides whether the requested time works (Airbnb Help Center, article 85). It's a small rule that handles an operational edge case without abandoning instant confirmation.

3. Instant book plus seller-side controls. Turo's November 2023 post, announcing that Book Instantly would become the standard way to book, paired the change with two host-control features: location-based trip-duration settings and customizable pickup and return hours (Turo Field Notes). The same post points to platform-side screening, saying Turo screens every guest and trip with a machine-learning risk model and applies eligibility restrictions such as age or license-tenure limits for higher-value vehicles. Control moves from per-transaction approval to settings plus platform risk assessment. Turo also states, as its own claim, that vehicles with Book Instantly turned on tend to earn more per month because guests prefer not to wait. That's a platform's statement about its own data and we can't verify it independently.

4. Quotes and negotiated bookings. Where price or scope isn't fixed, neither pure model fits. The buyer describes the job, the seller proposes terms, and both confirm. This is request-to-book with an extra step, and it's the norm wherever the product is customized. It connects directly to how price is discovered on the platform.

Which marketplaces lean which way

The pattern follows a few variables: how standardized the product is, how costly a bad match is, and how much time the buyer has.

A rental-software provider's guidance for hosts lines up with this logic: it suggests request-to-book for hosts offering longer stays only, with unique features, with special requirements about guests, or with availability that depends on other factors (Rentals United help center). That's a vendor's operating advice, not research, but it matches the variables above.

The B2B case deserves a note. When contracts are large and the relationship matters, buyers and sellers both expect a conversation before commitment, so the "gap" isn't a defect. It's part of the product. Our reference on B2B versus B2C marketplaces covers why the buying process differs, and the managed marketplace model is partly an answer to the same problem: the platform steps into the matching step so neither side has to.

Choosing and sequencing the model

A few reasoning steps help when designing or revising a transaction model.

1. Start from the cost of a bad match. If a failed transaction is cheap and reversible, lean instant. If it's expensive or unsafe, keep a decision point, or substitute platform-run screening for the seller's judgment.
2. Decide who carries the risk. Instant book works when the platform absorbs enough of the downside (verification, protection, recourse) that sellers will pre-commit. If the platform can't do that yet, sellers will insist on approval, and forcing instant book will drive them off.
3. Match the model to the supply side's maturity. Early on, when you're courting sellers one by one, flexibility to approve guests can be what gets them to list at all. As supply grows, moving the default toward instant may help conversion. Our reference on seller onboarding covers how to bring sellers in.
4. Make the default do the work. Sellers rarely change settings. Whether the default is instant or request shapes the whole marketplace, which is why Turo's announcement was about making Book Instantly the standard rather than just offering it.
5. Surface the choice in search. Airbnb lets guests filter to show only Instant Book listings (Airbnb Help Center, article 85). Whether and how a platform ranks instant-book listings higher is rarely documented publicly, so don't assume it. The ranking papers we reviewed describe predicting acceptance, not a boost for instant listings. How search and matching uses transaction mode is worth testing on your own data.

Common mistakes

• Treating the models as a pure speed question. Speed matters, but the control and risk trade is the real decision.
• Forgetting where the mismatch goes. Fewer declines can mean more cancellations. Measure both.
• Letting requests sit without a clock. A request model needs an expiry and a release rule for the buyer, as Airbnb's 24-hour language shows.
• Giving sellers discretion without auditing it. The Edelman, Luca and Svirsky experiment is the reminder that approval power can be used in ways the platform wouldn't endorse.
• Copying a rule from a different category. What works for a standardized rental may fail for a custom service.