Brief
Two-page version
The calls I made on the ambiguous parts
Core loop — two loops, one identity
Grind loop (daily, free). Open Scout, see what the guides you follow reviewed today, write your own review of a place you went, earn XP, and climb your city's leaderboard for a category (wine bars, coffee, dinner). This is the retention engine and the source of taste-graph signal. Boss loop (4–8×/year, paid). When a trip is detected, the app builds a mandate from the last 90 days of reviews and asks the user to confirm. The agent then bids in a private auction for boutique distressed inventory. The hotel is only revealed at close. The grind is the home mode. The auction is the travel mode. Same identity carries both.
Monetisation — two surfaces, no hotel commission
Free daily action that drives retention
Writing a constructive review earns XP. It's free, takes 30–60 seconds, and is the act that already happens in WhatsApp groups and Instagram stories. Scout just gives it a home and a leaderboard. Every review sharpens the taste graph that bids on hotels later, so the daily action and the eventual auction win share the same currency. Target: DAU/MAU ≥ 40% in seeded cities by month 2. That's a non-negotiable gate before paid acquisition opens.
Social mechanic for organic growth
Guide ranking and outcome cards. Public leaderboards, city by city and category by category (top wine bar guide in Lisbon, top coffee guide in CDMX), create status competition. Locals invite friends because "you'd be #1 for natural wine if you joined." On the auction side, every win produces a shareable outcome card ("Mandate met · saved €127 · Bairro Alto"). It hides the floor and the hotel rate, so the hotel side isn't damaged but the user side is brag-worthy. Full ranking mechanics in §07.
Positioning
Not Booking with an AI skin. Not Priceline's opaque category. Not "Beli with hotels." Scout is the first taste-graph-powered travel platform: a local curation game on the front, a consumer-side hotel auction on the back. The wedge is hotels because the perishability and commission spread is biggest there. The moat is the taste graph because no OTA can replicate months of daily local signal. The brief's Priceline reference is a useful contrast, not a category to copy. Priceline buys on price alone; Scout bids on taste-matched fit at a price ceiling.
Section 00
Market context — the hotel market where supply incentive is unusually strong
Picture a 90-room boutique on a Tuesday. Twelve rooms sit empty tonight, and tomorrow that revenue is gone for good. The obvious move is to drop the price — and it's the one thing the General Manager can't do publicly. A hotel sells one inventory of perishable rooms through six channels, and almost every channel is locked. OTAs like Booking and Expedia carry roughly 85% of online volume. Rate parity contracts cap any visible discount[1][3]. Wholesale operators like Hotelbeds and WebBeds leak even cheaper rates into long-tail sites the hotel never agreed to[9]. The pressure all points one way: hide discounts inside closed channels, stop showing them publicly.
Hotels are really two different markets. At chains like Marriott, Hilton, IHG, and Hyatt, pricing is set by automated revenue-management software (IDeaS, Duetto) and parity is strictly enforced. The property GM can't say yes to anything; selling in is a twelve-month enterprise sale to corporate. Boutiques are different. A single property, or a small group of three to fifteen, runs on basic property-management software (Cloudbeds, Mews). The GM still controls pricing, and parity is loosely policed at best. The GM personally feels every empty Tuesday, and personally signs the contract. That's the only side of the market where Scout can move at startup speed.
Why the existing distressed channels haven't fixed this. HotelTonight, Hotwire, and Booking Genius all do roughly the same thing. They stack a hotel commission on top of an already-discounted room, leak the outcome into public price trackers, and send the hotel whoever happens to click. But rate parity has a contractual carve-out for closed-user-group rates. That's the same legal slot Marriott Bonvoy, AAA, and AmEx Fine Hotels & Resorts already occupy. It's the structural opening Scout fills, and the reason it has to be members-only.
The slice Scout is choosing to operate in.
| Dimension | In play | Out of play (Yr 1–2) |
|---|---|---|
| Inventory | Distressed nights, ≤14-day window | Primary BAR; group bookings |
| Hotel segment | Independent boutiques, lifestyle indies, soft-brand collections (50–150 rooms) | Chain-branded, big-box, chain-managed resorts |
| Counterparty | Property GM with pricing authority | Chain corporate distribution VPs |
| Geographies | Lisbon, Porto, Mexico City, Lyon, Edinburgh | NYC, London, Paris, Tokyo |
| Stack position | Private channel parallel to HotelTonight / Hotwire / Genius — zero hotel commission, mandate-matched | Replacement for primary OTA, RM software, or meta-search |
Section 01
The mechanic call — why a city-curation grind
The frequency gap is the structural problem. A hotel-only mandate fires 4–8 times a year. The auction works the day you use it, but the rest of the year you're a dormant account. Without a daily reason to open the app, the taste graph never deepens, the social graph never forms, and the auction becomes a thin product wrapped around a search box.
So the mechanic call is no longer "what kind of agent competition?" That one is settled (auction house, see §06). The new call is upstream: what daily behaviour earns a user a seat at the auction? There are three readings. Only one survives.
Why the other readings lose.
| Reading | The problem |
|---|---|
| Deal alerts | Drip notifications create engagement without any compounding asset. The user learns nothing about their own taste; the platform learns nothing about them. Alerts get muted within weeks. Worse, it trains the wrong reflex: "open app when discount appears," not "this app reflects who I am." |
| Hotel social feed | You can build the most beautiful hotel feed in the world and it still only activates 4–8 times a year. The frequency problem doesn't go away just because you added a comment section. Booking.com has tried this three times. |
Priceline proved the auction mechanic works twenty years ago[10][11]. The bidder was just blind. Scout's bid agent isn't blind because it carries a taste graph the user spent months building. The grind is the moat. The auction is the payoff.
Loops detailed in §04. First: who this is built for.
Section 02
The user — Local Guide by default, Travelling Scout on trips
Scout has one user, in two modes. At home, they're a Local Guide: the friend everyone texts before a date night, the one with strong opinions on the new wine bar three streets over. On trips, they're a Travelling Scout: the same taste-confident person, just dropped into a city where their taste graph is empty and someone else's needs to fill in. Most users are both, alternating depending on the day. The grind is the home mode. The auction is the travel mode. The same identity carries both.
Today, the Local mode runs entirely on free labour spread across Instagram, Maps, group chats, and Beli. None of it compounds into anything the user owns. The Travel mode opens Booking.com and applies filters that don't really work ("boutique" is a marketing tag, not a real filter). After two hours they either give up or book something they'll second-guess. Mr & Mrs Smith curates well but at full rack rate. Scout's claim: route the daily local opinions into an asset (the taste graph), and that asset finally makes the Travel mode work.
Other segments considered.
| Segment | Why not first |
|---|---|
| The casual eater / passive consumer | Reads reviews but doesn't write them. The grind doesn't engage them — they want the output (a guide to follow) without producing the input. They're audience, not creators. Important for Year 2 but not the seed. |
| The full-time food influencer | Already monetised on Instagram/TikTok with sponsorship economics. Their taste signal is paid, which contaminates the graph. Welcome on the platform but never a trust anchor. |
| The active deal-searcher (travel) | Loves the hunt itself — delegating to an agent removes the reward. The auction strips the experience they value. |
| Chain-loyal / business traveler | Must stay at specific properties for status/points/policy reasons. Mandate-match indifference is a non-starter. (Chain supply is also out of scope — see §00.) |
| Points/miles enthusiast | Already has sophisticated tools (CardPointers, award booking services). The agent's edge is mandate execution, not redemption math. |
| Generic anxious optimizer | "I want a good deal" with no taste signal collapses back to price-only filtering — which Hopper and Going already serve. The taste-confident anchor is what makes the mandate meaningful. |
Two adjacent personas accelerate the wedge once locals are in. The first is the HotelTonight refugee. They've already made peace with not knowing the hotel name in advance, and they only need a trust layer that says "this place actually fits you." The second is the Going.com native: books the cheap flight first, now needs a hotel handled fast. Both are halfway to the boss tier already.
Section 03
User's mandate — derived from the taste graph, not typed in
The whole product hinges on one substitution. The user no longer chooses a specific hotel; they hand the agent a mandate, and the agent chooses. If the mandate is expressive enough, every auction win feels deserved. If it's too crude, every win feels like a gamble, and the trust falls apart. (Priceline's "star rating plus ceiling" was too crude; §01 covers why.)
The conventional fix is progressive disclosure: ask three questions now, learn the rest from rejection reactions. That's better, but it has its own problem. The mandate is still being authored at the moment of travel — when the user has the least patience and the least information about their taste in a new city. Reactions only refine the mandate if the user sticks around long enough to react, and the cold-start period is exactly when they don't.
The real fix: derive the mandate from the daily grind. By the time a Local Guide travels, they've already written 25–80 constructive reviews of places in their home city. Each one carries structured signal: "warm lighting," "natural wine list," "loud but in a good way," "third-wave coffee," "no service charge," "neighbourhood not centre." The taste graph isn't a wizard. It's a residue of months of opinions the user gave for reasons unrelated to travel. At trip time, Scout's agent — Mara — reads that residue, assembles the mandate, and enters the private auction without the user sitting down to write anything.
The design question collapses to a single sentence: "Has the user done enough local curation that the agent can bid in their voice?" If yes, the mandate is one screen of confirmation. If not, fall back to the 3-decision starter plus the reaction-learning path — and flag the auction outcome with lower confidence, because the agent is bidding on borrowed taste.
Section 04
Core loop — daily grind, travel boss tier
The product runs on two loops that compose. Loop A, the grind loop, is the daily local-curation cycle. Most users will spend most of their time here. Loop B, the boss loop, is the per-trip hotel auction. High stakes, low frequency — and the moment everything the user built becomes economically real. The daily loop is the actual product. The travel loop is the payoff.
Loop A · The grind loop (daily)
The grind loop is the daily product. Most users will run it dozens of times before their first trip. XP isn't a vanity number. It's the input weight on the user's taste graph and the signal that ranks them on guide leaderboards. Decay enforces recency. Without it, a user who reviewed 50 places three years ago would outrank someone reviewing three a week today.
Loop B · The boss loop (per trip)
| Category | Example user phrasing | Candidate standing rule |
|---|---|---|
| Location | "Too far from metro / wrong neighbourhood" | "≤5 min walk to metro" · "Stay in [zone]" · "Avoid [zone]" |
| Property fit | "Feels like a chain / not boutique enough" | "Avoid chain hotels" · "Boutique under 80 rooms" |
| Reviews / quality | "Recent bad reviews / dated photos" | "≥4.3 review score" · "≥100 reviews in last 12 months" |
| Amenities / inclusions | "No breakfast / no kitchen / no AC" | "Breakfast included" · "Kitchen required" · "AC required" |
| Price-to-value | "Saved money but still feels expensive" | Adjusts internal savings-threshold, not a standing rule |
| Trip context | "Plans changed / dates moved" | Captured as session signal, no rule promoted |
| Other (free text) | Anything not above | None auto-promoted. Reviewed weekly to refine the taxonomy. |
Next: how Scout makes money from both loops, without quietly recreating the same misalignment it sells against.
Section 05
Monetization — two surfaces, no hotel commission
Scout has two revenue surfaces matching the two loops. The grind loop runs a creator economy. Local Guides earn from activations when their reviews drive real visits. The boss loop runs a savings-aligned auction. Scout takes a cut of verified savings; hotels pay zero commission. The structural rule across both: no revenue from hotels, no revenue from venues. All revenue from users (subscriptions plus savings share). If the user doesn't get value, Scout doesn't earn.
(Platform fees shown in USD; the running Lisbon example uses EUR to match the scenario's local currency.)
Surface A · Local creator economy (grind loop)
Surface B · Boss-tier auction economics (boss loop)
Rejected revenue models (hotel commission, venue commission, paid placement in feed, ads, savings-share without deployment credit)
| Lever | Low case | Base case | High case |
|---|---|---|---|
| Scout Pass conversion (of all users) | 5% | 12% | 20% |
| Bookings / year (per traveller) | 2 | 3 | 5 |
| Avg public rate (€) | 120 | 140 | 170 |
| Savings vs. verified benchmark | 14% | 18% | 22% |
| Pass net to platform (€) | 1.8 | 4.3 | 7.1 |
| Savings share (€) | 7 | 15 | 37 |
| Deployment credits (€) | 3 | 5 | 8 |
| Blended ARPU / year (€) | ~12 | ~24 | ~52 |
| Gross user savings (€) | 34 | 76 | 187 |
| Net €/yr kept by user | 22 | 52 | 132 |
| Median Local Guide earnings (€/yr) | 40 | 180 | 600 |
Honest takeaway: base-case blended ARPU is ~€24 — lower than pure-hotel because most users don't travel often — but the consumer base is 5–10× larger. Active Guide earnings remain a real top-line story: good local guides can earn pocket money from sharing what they already do.
Validation gates — must clear before paid acquisition opens
Defined precisely so they can't be fudged. All must clear in the wedge city before a dollar of paid acquisition, and re-clear in each new city before paid opens there. The build sequence runs against these gates in §09.
| Gate | Threshold | Measured over | If it fails |
|---|---|---|---|
| 1 · Grind DAU/MAU | ≥40% in seeded city | By month 2 of city launch | The daily loop isn't habit-forming. Fix the local review experience, not the funnel. |
| 2 · Pass conversion | ≥10% of Active Local Guides on Scout Pass | Within first 60 days of activation | Pass value is unclear or wrong tier. Re-test perks and the inclusion bundle, not the price. |
| 3 · Bridge rate | ≥30% of Level 5+ guides deploy a mandate when they travel | Trailing 90 days of travel events | The grind-to-boss bridge is leaking. Strengthen trip-detection and mandate-confirmation UX, not paid acquisition. |
If any fails, the response is product-side — never "spend more on growth." Paid acquisition stays off until all three gates clear (§09 Phase 4); each new city re-runs the same three gates before its paid budget opens.
- Aggregated demand and taste signals. Anonymised, opted-in data licensed to revenue-management vendors as a pricing-intelligence feed, distinct from the auction.
- Intent data for non-OTA partners. Loyalty programs, card networks, and DMOs pay for forward-looking travel intent plus city-level taste signal.
- White-label auction infrastructure. License the closed-group auction stack to AmEx FHR and Bonvoy Moments. Per-seat fees, not commissions.
- Restaurant and venue reservation rev-share. Optional, only via partners that integrate as reservation infrastructure (OpenTable-style). Never paid promotion.
Section 06
How the auction works — the boss tier mechanic
The auction has two sides. On the supply side, a hotel quietly lists rooms it expects not to sell, with a secret floor below which it will not go. On the demand side, agents bid against that hidden number — each one carrying a taste-graph-derived mandate from a real user. When a bid clears the floor, the deal closes. The hotel's identity is only revealed at the close, and neither side ever sees the other's full hand.
Four moving parts. The listing is a distressed room plus a sealed floor, with an optional sweetener like breakfast or a room upgrade that only appears at the close. Floor estimation is the work the agent does to guess that hidden floor — triangulating from past closings, occupancy, days to check-in, and what's normal for the neighbourhood. Bid selection is how the hotel picks among bids that clear the floor: it takes the most committed, not the cheapest. And floor movement reflects the fact that floors drop as the room gets closer to unsellable. The agent's Patience setting decides whether to wait for that drop or claim the room now.
How the auction matures. The name on the door doesn't change. What matures is how literal the competition gets, from a few internal bid strategies on day one to a real two-sided live auction once enough hotels and agents are around to support it.
| Stage | Competition | Hotel side | Floor |
|---|---|---|---|
| Day 1 | Internal bid-strategy variants per listing; user sees the winner. 2–3 agents probe a pre-set floor. | Manual review; pre-commits indicative floor for 90 days; can override at reveal. | Indicative (non-binding) |
| Day 180 | 5–10 agents per popular listing, calibrated bids against a sealed floor with real data behind it. | Sealed floor from RM heuristics + Scout calibration; auto-accepts above-floor winner. | Sealed static |
| Day 730 | 20–50 agents per premium listing; floor itself responds to bid pressure. True two-sided auction. | Dynamic yield via PMS/CRS API[2][7]. Floor is an algorithm. | Dynamic function |
Why use AI agents instead of a simple rules engine?
You could in theory write the bidding as a rule engine: "if occupancy drops below 70% and check-in is within 48 hours, bid within 8% of the estimated floor." Rules like that are easy to audit, easy to reason about, and fast to run. They're also brittle in exactly the way this auction punishes. A fixed ruleset is a published strategy. Hotels read its bid pattern over a few weeks, then shift their floor timing to defeat it.
What Scout offers hotels that existing distressed channels do not[6].
| Channel | Commission | Public-rate damage | Demand quality |
|---|---|---|---|
| HotelTonight | ~15% | Indexed in price-tracker forums | Whoever clicks |
| Hotwire opaque | 10–25% | Feeds Kayak comparison anchors | Price-only buyers |
| Booking Genius private | ~10–15% + Genius bleed | High over time | General traveler base |
| Secret Escapes | 15–20% | Limited — members-only | Curated but broad |
| Scout | 0% from hotel | Slower leak — scattered anecdotes | Mandate-matched |
The math from the hotel's side. Take a €130 distressed night. Through HotelTonight, the hotel keeps about €110 after commission. Through Hotwire, somewhere between €100 and €110. Through Booking Genius, €111 to €117. Through Scout, the hotel keeps the full €130 — roughly 30% more per booking at the same headline price to the traveller. The user is still saving against the public rate; Scout's cut comes out of those savings. Lift on the hotel side, savings on the user side, no commission in between. That's the entire spread.
Section 07
Social layer — guide ranking, asymmetric follow, endorsement
The grind loop needs a social shape that compounds. Three primitives do the heavy lifting. Asymmetric following: locals follow locals; travellers follow locals. Guide ranking: a public leaderboard per city × category, with an Active-Guide cap that creates scarcity. Post-trip endorsement: the only social action a traveller can take, and the one that trains the matching algorithm. The social object isn't a feed post. It's the guide profile — a living taste graph that other people use as a mandate.
| Growth feature | Mechanic | Why it compounds |
|---|---|---|
| City × category guide leaderboard | Public ranking by XP, recency, endorsement weight. Top 8 per city × category become "Active Guides" — visible by default, eligible for the higher creator-pool tier, and capped (no inflation). | Scarcity creates competition. A guide who knows there are only 8 Active slots in their city grinds harder. Active status compounds: more followers, more activations, more endorsements, more weight. |
| Asymmetric following | Locals follow ~3–8 other locals (peers they trust to find new spots before they do). Travellers follow ~5–20 locals across the cities they care about. Locals rarely follow travellers back. | Mirrors how taste actually flows — from city-natives outward. Prevents follower-count-as-vanity inflation that destroys discovery on Instagram/TikTok. |
| Endorsement after trip | Post-trip prompt: "Was Ana's taste graph the right call for this trip?" Tap = +trust score on the guide, +5% revenue share if used. This is the only signal a traveller can give a guide. | Closes the loop. Trains the taste-matching algorithm on real outcomes, not stated preferences. Endorsement weight feeds back into guide ranking. |
| Outcome proof card (invite-gated) | Auto-generated on close: anonymised property class + city + bid + savings vs benchmark + guide credited. Each share is also an invite link into the closed group. | Social proof that doesn't read as an ad. Must clear ≥25% of wins shared and ≥1.5 referrals per active user. |
| Borrowed-taste growth loop | Travellers without their own taste graph can borrow a guide's. Borrowing surfaces the guide's profile and triggers a follow prompt at trip end. | The lowest-friction onramp into the grind. A traveller who borrows once is 5× more likely to start writing reviews themselves within 30 days. |
| XP decay | Inactive guides lose ranking weight after 14 days idle, capped at 60% of accumulated XP. Active Guide status is auto-revoked after 30 days idle. | Keeps the leaderboard reflecting current behaviour. Without decay, a guide who reviewed 50 places in 2024 would block a guide reviewing 3/week today — destroying the game. |
Section 08
Positioning — the bridge between local curation and travel commerce
What Scout is not: not another reviews app, not "Beli with hotels," not an OTA, not "Priceline with AI." Each of those framings borrows a category but discards the part that makes Scout structurally different.
Category claim: the first taste-graph-powered travel platform. A local curation game on the front, a consumer-side hotel auction on the back. Locals build a public taste graph by reviewing the places they actually go. That graph becomes a mandate when they travel, deploying into a private auction for boutique hotels' distressed inventory. The platform earns from subscriptions on the local side and verified savings on the travel side. Never from hotels, never from venues.
Why category creation over repositioning.
| Frame | Why it's tempting | Why it loses |
|---|---|---|
| "Beli for everything" | Existing reviews/ranking game has demonstrated daily habit. Easy to explain. | Beli has no economic surface beyond user-paid status. No commerce → no creator earnings → no real competition between guides. Caps at the foodie hobbyist. |
| "Smarter OTA" / better Booking | Easy to explain — fits existing search intent. Low CAC. | Reframes Scout as a hotel-search feature. Taste graph becomes a personalisation tag Booking ships in 6 months. Daily habit collapses. |
| "Priceline with AI" | Leverages known mechanic (NYOP). Familiar discount frame. | Positions Scout as a Priceline feature. Commoditised the moment any OTA bolts an agent on top. |
| Taste-graph bridge: local game → hotel auction | Two daily/episodic surfaces composing one platform. Defensible assets compound across both sides. | Hardest to explain on cold traffic. Requires education. We accept this cost because the bridge is the moat. |
Scout's defensible pieces — labelled taste graphs, the city-by-city guide network, private hotel inventory, bid intelligence — only behave like network effects inside the frame "bridge from local curation to travel commerce." Inside the frame "better reviews app," the auction is irrelevant. Inside the frame "better OTA," the daily grind is irrelevant. Neither Beli nor Booking can copy this without becoming a different company. Beli would need a hotel auction stack and supply relationships. Booking would need to fire its hotel sales team and walk away from public search. That's the moat.
- "Beli can't add hotels." They'd need closed-user-group legal infrastructure, hotel supply relationships, and an auction stack. Three startup-level lifts at once.
- "Booking can't add the grind." Public-search SEO economics are incompatible with a closed-group creator economy that pays Local Guides per activation.
- The bridge is the network. Each Local Guide whose taste powers a successful boss-tier auction strengthens both sides at once.
Section 09
GTM — local guides first, hotels second, paid acquisition last
The sequencing inverts the conventional hotel-first playbook. Hotels are no longer the seed; Local Guides are. A boutique GM partnership in Lisbon is worthless without a critical mass of taste-confident locals whose mandates will eventually deploy there. So we seed locals first (cheap, viral, no commercial conversations), prove the grind retains, and then bring hotel supply online for cities where we have the demand. Paid acquisition stays off until the three gates from §05 clear: grind DAU/MAU ≥40%, Pass conversion ≥10% of Active Guides, and ≥30% bridge rate from Level 5+ guides to first-trip mandate.
City order is unchanged: Lisbon, then Porto, Mexico City, Lyon, Edinburgh. The wedge cities have to be ones where (a) the boutique GM has pricing authority on the supply side, and (b) the local food, bar, and coffee scene is dense and identity-forming enough to support a competitive guide leaderboard. London, New York, Paris, and Barcelona stay out of Year 1. They're chain-saturated on the hotel side and so over-reviewed that no new guide can credibly claim "I know this city."
| Phase | Target | Mechanic | Success signal | Kill signal |
|---|---|---|---|---|
| 1 · Local Guide seeding Wks 1–6 · Lisbon | ~50 hand-picked locals (food/bar/coffee opinion-havers) | Direct outreach: Instagram DMs, WhatsApp foodie groups, neighbourhood Discords. Pitch: "Be one of the founding 8 Active Guides in Lisbon. Earn from activations once we open." Free Pass plus early creator tier guaranteed. | ≥30 actively reviewing within 2 weeks; median 3+ reviews/wk per active guide; visible competition for top-3 slots in 2+ categories. | If <15 are actively reviewing, the city wedge is wrong or the pitch isn't landing. Re-pick city or pitch before Phase 2. |
| 2 · Local audience build Wks 6–12 | ~1,000 invited followers in Lisbon | Each guide invites their real network (15–40 each). Closed-group invite codes. No travel mention. Goal: prove the grind retains on its own. | Grind DAU/MAU ≥40%; Pass conversion ≥10% of Active Guides; ≥3 endorsement-equivalent signals per week per guide. | If DAU/MAU is <25%, the grind isn't habit-forming. Fix the loop before adding hotels. |
| 3 · Hotel supply Wks 10–16 · Lisbon | 30 indie boutique GMs | Direct pitch: 0% commission, ~30% net lift, parity-safe closed-user-group, mandate-matched demand. Show the existing Lisbon user base as proof of demand. 90-day pilot, no exclusivity. | ≥8 partners committed; 5–10 distressed nights/mo each. | If <5 partners commit, the demand-side numbers aren't compelling yet. Deepen Phase 2 before retrying. |
| 4 · Boss-tier beta Wks 14–20 | First 50 Lisbon users to travel | Mandate auto-derived from each user's taste graph plus 3 trip fields. Wizard-of-Oz matcher against Phase 3 inventory. Deployment credit charged. Outcome card credits the guide whose taste was borrowed (or self). | ≥40% mandate booking rate; ≥30% second-mandate within 60 days; median savings ≥15%; ≥50% endorse a guide post-trip. | Savings <10% means the auction is broken. Endorsement <20% means the bridge isn't being felt; rework the outcome card. |
| 5 · Lisbon full launch Mo 5–8 | Invite-gated growth, no paid spend | Each member invites 3. Outcome cards auto-share. Borrowed-taste growth loop live. Press hook (Phocuswire/Skift) for travel side, food press (Monocle, local equivalents) for local side. | Effective CAC $15–25; ≥1.5 referrals/active user; ≥15 boss-tier closings/wk. | If <15 closings/wk, focus on demand depth before geographic expansion. |
| 6 · Multi-city scale Mo 8+ | Porto, then Mexico City, Lyon, Edinburgh | Each new city repeats Phases 1–3 in compressed form (~6 weeks vs 14 in Lisbon). Paid opens after all three gates pass. Travel TikTok/YT, boutique-affinity press (Mr & Mrs Smith). PMS partnerships (Cloudbeds, Mews) for hotel scale. SEA later: Traveloka/Klook partnerships, Agoda-independent boutiques. | All three gates clear per city; ≥8 hotel partners and ≥30 active local guides before opening boss tier. | If per-city DAU/MAU drifts below 30% in month 2, halt expansion and deepen existing cities. |
| 7 · Adjacent verticals Yr 2+ | Bars, coffee, events on local side; spa, restaurants on boss-tier side | Categories are added one at a time. Each category re-runs a mini-Phase 1: seed top guides in the category before opening it to all users. | New category clears 50% of leaderboard slots filled within 30 days. | If a category doesn't fill slots, it's a city or category mismatch. Don't force it. |
Section 10
What's next — once the bridge is real
"Successful" means three things are simultaneously true. The grind is a real habit (DAU/MAU ≥40%, Pass conversion ≥10%). The boss tier is live in at least two cities beyond Lisbon. And outcome cards are generating more inbound than referral codes. None of that is assumed. But if all three hold, the question stops being "does the bridge work?" and becomes "what is the taste graph for?" The answer determines whether Scout is a hotel-deals app, a city-curation game, or something more general.
Year-3 north star: Scout is the taste-graph primitive that powers consumer-side auctions in any perishable, mandate-fit category. Hotels are the wedge. The same mechanic — grind loop, closed group, mandate, savings share — re-runs against any supply where (a) inventory is perishable, (b) the operator has real pricing authority, (c) a closed buyer group can be carved out of public price parity, and (d) the user's daily taste graph carries usable signal for the bid. The 3-bet sequence below is ordered by how much of Scout's existing infrastructure each one inherits.
| Bet | What it inherits | What it tests | Success signal | Kill signal |
|---|---|---|---|---|
| 1 · Deepen the grind into more categories Yr 2 · same cities | Local Guide network, ranking infrastructure, creator pool. Categories beyond restaurants: bars, coffee, events, fitness, salon, kids, niche retail. Each category gets its own leaderboard and creator pool. | Whether the grind primitive generalises off food. Each new category re-runs the seeding playbook from §09 Phase 1: pick the top 8 founding guides before opening. | Two new categories clear 50% of leaderboard slots filled within 30 days, and median guide earnings reach ≥€40/mo within 90 days. | If two consecutive categories fail to fill leaderboard slots, the grind is restaurant-specific. Stay tight; deepen existing categories. |
| 2 · Cross-category boss tiers Yr 2 · same closed group | Mandate primitive, bid intelligence, closed-user-group infrastructure. Boss tiers beyond hotels: small-ship cruises, soft-brand resorts (Autograph, Unbound), high-end spa/wellness stays, restaurant tasting menus at peak release. | Whether the taste graph generalises across boss tiers, and whether new verticals re-run the three structural gates (perishability, operator pricing authority, closed-group fit). | First vertical clears ≥15% savings within 6 months of seeding; bridge rate from local grind to new vertical clears ≥20%. | If two consecutive verticals fail one gate, the boss tier is hotel-specific. Stay a hotel auction house and reinvest in depth. |
| 3 · SEA expansion Yr 2 · supply via partners | Grind UX, auction stack, mandate UX, creator pool economics. New work: localised closed-group framing, language coverage, Traveloka/Klook supply distribution, Agoda-independent boutiques in Bali, Bangkok, Hanoi. | Whether the boutique-GM authority pattern and the Local Guide identity both survive in destinations with lower chain penetration but higher OTA dependence. | Per-city DAU/MAU ≥30%; ≥8 hotel partners committed before boss-tier opens; SEA savings ≥15%. | If DAU/MAU or savings drift below threshold, the wedge is Western-boutique-specific. Pull back and reroute spend. |
| 4 · Taste-graph as infrastructure Yr 3 · post-Series B | Labelled taste graphs, mandate library, closed-group auction stack, floor-estimation models, settlement rails. Licensed to demand owners with their own membership: AmEx FHR, Bonvoy Moments, Substack-scale travel writers. | Whether the taste-graph + auction venue is more valuable than any single distribution surface — i.e. whether other closed groups would rather rent the runtime than build their own. | ≥3 paying licensees; >25% of platform GMV flows through licensed surfaces within 18 months of GA. | If licensees churn within 12 months, the runtime is too coupled to Scout's brand. Convert to deeper integrations with 1–2 strategic partners only. |
§05 lists the four B2B revenue channels that follow naturally from the user-side stack. The four below are second-order. They only become coherent once the bridge is real, mandate sharing is high-volume, and the taste graph is a usable asset.
- Mandate template marketplace. Travel writers, locals, designers, and trusted personalities publish mandate templates ("My Lisbon mandate," "Tokyo for first-timers"). Members deploy them for a small premium; revenue splits with the author. Substack-style economics for trip judgment, layered on top of the borrowed-taste mechanic from §07.
- Public-rate guarantee, paid by hotels. A hotel pays Scout a small premium to defend the strike rate against public-rate drops in the days after booking. It inverts the defection risk opaque-channel users normally absorb. The hotel funds the guarantee because the alternative — a refunded customer who re-books on Booking — is more expensive.
- Outcome-card publishing rails. Verified outcome cards embed into third-party content: travel newsletters, YouTube show notes, podcast pages. Revenue share when an embedded card converts to a deployment. Bid intelligence becomes content infrastructure.
- Taste-graph SDK. The grind-plus-mandate primitive abstracted as a developer surface for any perishable category: restaurant cancellations (Tock-adjacent), last-minute wellness and fitness, salon cancellations, even private-jet empty legs. Scout owns the runtime; the partner owns the supply. Take rate on closings, not access fees.
Constraint, repeated from §05: nothing that gives operators a reason to bid less aggressively, and nothing that exposes mandate-level user data to operators or distribution partners.
- Won't open a public boss-tier auction. Breaks the closed-user-group rate-parity carve-out (§08). Once the auction is public, hotels post to it with Booking-aware floors and savings collapse.
- Won't take venue commission, in any form. Includes "thanks" payments, MDF, paid placement, or "featured guide" tiers. The instant any restaurant, bar or hotel pays Scout, the alignment claim from §05 is rhetoric.
- Won't sell floor estimation or taste-graph data as a public API. Both moats. Licensing either externally arms Booking's vendors and Beli's clones with the only signals they can't otherwise reach.
- Won't chase chain-dominated inventory or food-chain reviews. Chain-managed hotels and chain restaurant reviews degrade the auction and the taste graph respectively. Both cohorts exit if forced.
- Won't acquire or partner an OTA or major reviews site. Scout's category claim depends on being the venue that doesn't work for hotels and the reviews app that does earn its guides money. Either acquisition collapses one side of the positioning.
References
Primary set — distribution, rate parity, NYOP economics
- Lighthouse — Uncover common hotel rate parity issues to combat disparity
- Techspian — How OTA Inventory Systems Revolutionize Travel Operations
- idhotelier — Strategic Governance and Implementation of Rate Parity in Hotel Distribution
- AltexSoft — Travel Agency Inventory System: Main Sources and Management
- EHL Insights — How Revenue Management Works in Hotels
- SiteMinder — Online Travel Agencies (OTAs): Complete Guide for Hotels
- SiteMinder — What Is a Global Distribution System (GDS)?
- SiteMinder — Hotel dynamic pricing: Complete guide with examples
- Lighthouse — 3 ways to tackle rate disparity with wholesalers
- Wikipedia — Name your own price
- Unique Business Models (Substack) — How does Priceline make money?
- UCLA Econ (Sboard) — Priceline: Name Your Own Price Introduction (PDF)
- Review of Economic Studies — Name Your Own Price at Priceline.com: Strategic Bidding and Lockout Periods
- Journal of Retailing and Consumer Services — Posted price and name-your-own-price in a product line design problem
- SiteMinder (YouTube) — The Basics of Online Travel Agents for Hotels
Revenue management — videos & primers
- YouTube — Hotel Revenue Management (overview)
- Hotel-Spider (YouTube) — Revenue management in the hotel industry — Basics
- Little Hotelier (YouTube) — What is hotel revenue management?
- SiteMinder (YouTube) — Hotel Revenue Management — Simplified!
- techtalk.travel + Expedia (YouTube) — Basics & Adoption of Revenue Performance Management Principles for Small, Independent Hotels
OTA supply chain, inventory, bedbanks
- AltexSoft (YouTube) — Hotel Q&A: OTA Connection With Hotels
- Gimmonix (YouTube) — Gimmonix reveals how OTA, bedbanks and wholesalers manage their hotel offerings
- AltexSoft — Bed banks 101: Wholesaler Role in Travel Distribution
- SiteMinder — What is a bed bank? List of examples for hotels
- Mize — The Most Complete Hotel Wholesalers and Bed-Banks List
- HotelRunner — Top 5 Global Bedbanks You Must List Your Property
- Hotelbeds — Hotelbeds: Travel Technology Provider
- Chekin — How OTAs Work: What Every Hotelier Needs to Know
Opaque pricing & Priceline economics
- YouTube — Complete Guide to Opaque Pricing in Hotels
- OccupancyBoost (YouTube) — Opaque bookings explained for Hoteliers and why you need them
- Corporate Finance Institute — Opaque Pricing — Overview, How It Works, Benefits, Example
- YouTube — Priceline: a Startup That Won Travel
- Phocuswire — Opaque bookings on the wane: Priceline, Hotwire, and a changing landscape
Market players — OTAs, channel managers, market share
- Mize — Online Travel Agencies Market Share Across the World
- Cloudbeds — The 10 Best Online Travel Agencies in 2025 for Hotels
- Lighthouse — Top 10 Online Travel Agencies (OTAs) for your hotel
- SiteMinder — Best Channel Manager for Hotels
- SiteMinder — The World's Leading Hotel Channel Manager
- Eviivo — 8 Best Channel Managers for Hotels to Know in 2026
- Statista — Top online travel companies by market cap 2025
- Wikipedia — Trip.com Group
Comparable channel discount & CAC benchmarks (S05 unit econ)
- The Traveler — Booking.com vs. HotelTonight vs. Priceline: Who Has the Biggest Discounts? (HotelTonight ~16% average off published rate)
- SimplyCodes / Hotwire — Hotwire Promo Codes & Coupons (Hot Rate hotel bookings average ~37% more savings than standard bookings)
- Booking.com — Genius loyalty program (10-20% by tier)
- Userpilot — Average Customer Acquisition Cost (CAC) Industry Benchmarks (2026)
- Business of Apps — App User Acquisition Costs (2025)
GTM benchmarks & cross-category perishability (S09)
- Viral Loops — How Robinhood's Referral Built a 1M User Waiting List (~3.0 viral coefficient; 2/3 of waitlist from referrals)
- kwokchain — Notes on Superhuman's Acquisition Loops (70% of weekly new users from referrals)
- Revenue Hub — RevPASH for Improved Restaurant Revenue Management (restaurant tables as perishable inventory; direct hotel-RM analog)