Direct Booker

Transcripts also render “DirectBooker” / “Direct Poker” — same company.

Current truth

• Who: brand-new hotel-booking aggregator startup whose entire strategy is being discoverable inside the major LLM clients (connectors/apps), not classic SEO/brand. Currently the most-visible brand in Claude’s hotel category, out-competing far larger incumbents purely by optimizing for connector discoverability. Ghostteam is “very close with the Direct Booker team.”
• Relationship: currently uses Ghostteam for free (was logged “dormant” — now re-activated as the priority anchor). This is the anchor case study: a real client where Ghostteam can prove a measurable discovery → revenue lift. Working contacts: theresa-directbooker and sanj-directbooker.
• The proof point: an existing case study shows Direct Booker saw ~15% uplift in incoming organic users on Claude (tied to revenue). ⚠️ Direct Booker may not want the revenue figure public — “tweak it” before any external use.
• The 10-week goal (set 2026-06-16): by the end of the ~10-week window, have Direct Booker show a measurable lift from specific actions Ghostteam recommends — the case study that anchors the whole market narrative and fundraise. Research is to be “relentlessly focused” on this (see research-priorities).
• Cadence: weekly calls, run their target prompts, build the features they need — a clean top-level objective in the sprint plan (2026-06-16-q2-goals-gtm). Near-term collaboration = use Direct Booker as the first controlled optimization experiment.
• Investor note: Marriott is looking to invest in Direct Booker (relayed via Sanjay, 2026-06-16) — half-joke that Ghostteam would take a commission for helping land it; it seeded the “which connector types/segments outperform” research idea.
• Adjacent: Moby (built hotel apps for Wyndham) came in via the Direct Booker relationship — see pipeline.
• Usage signal (2026-06-19): Direct Booker’s dashboard showed 19,000 active users in the last 30 days, 7,000 total tool calls, and roughly 1,000 tool calls in the last 7 days across Claude AI + Cowork (~150/day). Cowork appeared to be their largest traffic source, not Claude; hypothesis is that users connect once, then Cowork/Codex becomes the search/work OS, where connector-picker behavior may differ or be absent.
• Claude update/review friction (2026-06-17/19): Direct Booker pushed a new MCP server version adding a hotel lookup tool and changing existing tool descriptions. Claude moved them into a semi-locked / pending-review state with unclear timing; existing tools were not kept live during review and users may need to manually reset connector permissions. ChatGPT review is faster and does not lock tools. This can cause short-term ranking dips and makes single-variable optimization experiments dependent on review/propagation timing.
• Experiment inputs: Theresa will share before/after LLM-facing tool descriptions, consumer-facing directory descriptions, a Claude dashboard screenshot, and summary of key product changes. She also wants more realistic user prompts, potentially via a cheap Useberry survey.
• Controlled experiment design: use Direct Booker as the first rigorous optimization testbed: capture baseline tool data/descriptions, start from Theresa’s prompt set, build a prioritized recommendations backlog around top user intents, make isolated single-variable changes, then re-run after review. Success metric is not just rank; Theresa cares about more users and connections.
• Measurement challenge: for hotel prompts, Ghostteam must distinguish connector-picker/direct MCP invocation from native platform tool calls or web/native answers. Google Maps / hotel search tools can look technically similar to Direct Booker MCP usage unless internal/travel tools and MCP widgets are labeled correctly.
• Strategic product wedge: “sniping” direct hotel prices alongside OTA results — a micro price tool returns direct price + booking link for a known hotel/check-in/out/occupancy, piggybacking on Booking.com/OTA brand recognition rather than owning the whole user journey.
• Recommendation-engine workstream (2026-06-23): the next Direct Booker call (scheduled 2026-06-23) is to align on how we suggest specific changes and why — decode what drives vs blocks selection, then prioritize across surfaces. Agreed we first need a written “how the system works” approach doc before building the recommendation engine; building it is then largely Vincent’s focus. Ties to the Fixes tab in discoverability-framework and roadmap.
• Interim deliverable (2026-06-23): while the platform UI is built, generate reports from existing prompt runs (we’re already running Direct Booker’s prompts; ADO score calc, custom categories, and add-prompts are working). Onboard them into the new platform once it’s ready rather than building a one-off dashboard.
• Blocker (2026-06-23): the hotel category is over-fragmented (3 hotel subcategories), so Direct Booker can’t yet benchmark against the relevant hotel set — fixed by the one-primary-category re-categorization + Perplexity enrichment (see ado-score-model).
• Performance picture (2026-06-26 internal, ~1,000 runs): across ~1,000 runs on DB’s prompts — strong on direct booking (near-100% appearance, niche won; tool name + keywords well-optimized) and corporate discovery; weak on generic booking (retrieved but only ~1/3 shown — keywords right, not getting picked), amenity/filter (“budget-friendly hotel”, “sports bar”), and named-property/chain prompts; no performance on account-history (“pull my hotel stays / how much I spent” — fans out into expenses/receipts keywords DB doesn’t cover; Auto wins those). Improvement vector = keywords + tool description. Connector-picker appearance is category-specific, not universal: clear action prompts (book a hotel) → ~100% picker; advice/research prompts → connector rarely appears (e.g. “Marriott hotels in Boston near Fenway” → zero picker = no rank opportunity; a prompt-category trait, not a DB failure). Score is a directional methodology, not an absolute outcome: relevance/retrievability signals count even at zero pickup (they show you’re doing the right things to win the niche); zero = you don’t exist. The benchmark headline reads low mainly as a prompt-scope artifact — scoped to direct-booking prompts only DB would be 90+. Strategy = ASO-style niche-first: don’t touch the winning direct-booking setup, expand outward.
• Engagement approach (2026-06-26 internal): run DB as a structured, research-paper-style experiment — lock goals + prompt set first, build an exhaustive factor list + hypotheses, then test with isolated single-variable changes (the empirical gold standard) → a case study showing measured rank lift. No recommendations until goals + prompts are locked (even the “obvious” keyword fixes wait), to keep the experiment clean. Refined at the noon deck-review: work from DB’s existing prompt data rather than generating new prompts (avoid weeks of delay; new prompts = a fresh baseline/experiment later); optimize per topic category, not all prompts at once, and ask DB to rank its prompt categories by priority so changes can be isolated. North star = intent-based optimization: optimize for what users actually prompt, not for connector-picker appearance — and build presence now for prompts expected to grow (“book a hotel in Claude”). The “what’s your goal? / here are the prompts to go after” intake is framed as the paid managed-service layer (~$10k/mo aspiration).
• Strategic goal — LOCKED with theresa-directbooker (2026-06-26 client call): win top-of-funnel, generic dateless hotel discovery — get surfaced/recommended as early in the journey as possible, before the user provides dates — while defending the won direct-booking niche, and (later) also winning the availability/price moment (“is it available for my dates? how much?”). Evidence: Theresa’s UserBerry survey (25 real-user responses) found almost no one includes dates in their first prompt (e.g. “cheap hotels in Thunder Bay”, “best hotels in Cape Town for couples”). This finally answers the long-open “where do you want to win?“.
• Competitive hypothesis — the dateless tool: most OTA MCP connectors require dates, so the model can’t call them until dates exist; a DB search tool that doesn’t require dates could get called earlier in the funnel. Theresa saw exactly this in ChatGPT (dateless prompt → tried Last Minute, asked for dates, failed → fell back to Booking.com which needs none → same for Skyscanner). Bonus: cheaper top-of-funnel entry (price pulls cost money; high look-to-book ratios hurt — let users narrow first). Vincent’s caveat: a new tool making the model reach for a connector sooner is possible but likely low-probability (it decides to reach for a connector first, then picks) — flagged as a real experiment. Generalized to signal-set-and-weights.
• Product status — Claude UI held back (2026-06-26): DB’s ChatGPT app has full UI (maps/cards) live; the Claude version is ~95% built but intentionally held back because Claude’s docs say UI elements alter/replace the chat response (anti-duplication), risking the chat quality DB has tuned — they want to QA first. (Claude builds its own maps/places UI; ChatGPT now does too.)
• Commercial/relationship (2026-06-26): Ghostteam walked Theresa through pricing — self-serve = charged purely on prompt volume + a recommendation engine that suggests fixes; enterprise = the hands-on MCP funnel/discovery work we do now. New customers get ~50% off; DB stays the anchor at current (free) terms. Asked Theresa for referrals.
• Optimization experiment RUNNING (2026-07-06 call): the recommendations were agreed and sequenced as four changes, ~1 week apart to isolate impact — (1) shortDescription/one-liner + “availability”/“reservations” — pushed live by Theresa DURING the call (form-based, no code; she confirmed the field caps live: one-liner 200 chars max, hers now 79; long description 2,000 max, hers 977 with keywords stuffed at the end but neither target word); (4) long description follows next week (form-based); (2)+(3) tool-name changes ride the next code release (~1.5 weeks out — engineer vacation). Tool-order guidance given: only the first 8 tools are read, flagship tools on top (DB has 3–4, not yet a concern). Verification = our daily connector snapshots (Vincent confirms the new version the next day); Miro precedent cited — tool-name updates showed ranking improvement the next day, so no indexing lag expected.
• Connector-state anomaly (2026-07-06): production shows 3 tools (hotel search, hotel details, hotel lookup) — all briefly “blocked” after DB’s latest push — but Claude’s directory and registry search show only 2 (hotel lookup missing). Suspected caching; Theresa testing a fresh install post-call; may need to chase Anthropic. A 4th tool lands in the next release (DB deliberately expanding the tool library — small tools over one-does-everything). Note: our 2026-07-03 recommendations were built against the 2-active-tools picture.
• Brand-name keyword risk (Theresa’s read, 2026-07-06): most major-chain contracts carry Google-Ads-era clauses prohibiting bidding on brand terms — they don’t technically cover AI connectors yet, but chains with live apps (per Theresa: Hyatt, Hilton, IHG, Wyndham; she believes Marriott not yet) will likely push back once they notice. Plan: she rewords the chains sentence keeping the actual names (the names are the retrieval trigger — “major hotel brands” loses the benefit), tests less-contractually-sensitive brands first, expects a possible revert. Her broader read [idea]: hosts will get Google-grade sophisticated against keyword tactics over time — “a short-term strategy, and we’ll take it.”
• Directory-rank jump (2026-07-06): DB rose ~30 spots in the Claude connector-directory ranking recently; its Claude popularity score also ticked up. The correlation is [idea] (unexplained; we told DB that merely pushing a connector update does NOT boost directory rank — the measured finding lives in claude-directory-rank-decoded).
• Competitor watch — super.com (2026-07-06): entered DB’s custom prompt universe in recent weeks. Theresa’s read [idea]: discount OTA, “slightly sketchy reputation,” competes on price. Theresa also runs her own competitive intel: she pulls competitors’ tool metadata visible in ChatGPT into a Claude project for analysis (ChatGPT exposes release version numbers — highest she’s seen is v5; Claude hides versions, so we offered our daily snapshots as her source).
• Registry-search recommendations ready (2026-07-03), from the decoded Claude backend (claude-registry-search-decoded): on DB’s nine observed keywords, DB is #4 hotel / #8 travel / #10 booking (last slot, fragile) / 2-of-2 hotel booking — and absent from reservation, reservations, availability, hyatt, which are mostly near-empty, unclaimed result lists (the reservation list is led by Google Compute Engine). Recommended, with per-keyword predictions verifiable the day after shipping: (1) rename the two existing tools → search-hotels-for-booking + hotel-availability-details (predicted: booking #10→3, availability absent→top-2, hotels #5→1, hotel booking contends #1 vs Booking.com); (2) append to the shortDescription ”— search, availability, and reservations” (predicted: reservation/reservations absent→~#2); (3) optional: one description sentence naming bookable chains → hyatt ~#1–2 (third-party brand term — DB’s call). Deliberately rejected: a manage-reservations tool (capability DB doesn’t have = keyword-stuffing), renaming to “DirectBooker Hotels” (helps 1 of 9 keywords), more long-description work (weakest field — DB is absent from availability despite the word sitting in its description), category re-tagging (not indexed). hotel/travel/accommodation are prominence-limited — no honest text edit moves them; the winnable ground is the unclaimed mid-tail. Credibility anchor: the predictive model blind-called DB’s own Jun-23 edit (predicted +2/+3 ranks on its hotel/travel/booking queries; observed +2.2/+3.0). Client-ready report: DIRECT_BOOKER_CASE_STUDY.md in the registry-search repo (~/Dev/mcp_registry_search_simulation).

Open questions

• Why did DB jump ~30 spots in the directory ranking? Popularity uptick is a candidate ([idea]); connector updates alone were ruled out as the cause. Worth a scientific answer — it’s the client-facing face of claude-directory-rank-decoded.
• Does the 2-vs-3 tool discrepancy resolve as caching? Theresa’s fresh-install test post-call; if not, chase Anthropic. (Our recommendations assumed 2 active tools.)
• Do chains notice/push back on the brand-name keywords, and how fast? Determines how durable recommendation #4 is.
• (Resolved 2026-06-26) Goal = top-of-funnel generic dateless hotel discovery + defend direct booking (see Current truth). Residual: which secondary categories to add next (amenity/filter? corporate?) — Theresa to prioritize.
• Does a dateless search tool actually get DB’s connector called earlier in the funnel (the core planned experiment)? And does adding a tool ever make the model reach for a connector sooner (Vincent rates it low-probability)?
• Can we close the loop prompt → picker → usage? DB has session + click metrics (a redirector) + a Looker dashboard (access pending — the engineer who built it is away) and ChatGPT exposes tool-level intent-capture — is that enough for credible attribution (the 10-week deliverable)?
• Prompt set: agreed ~20 focused prompts, Theresa to refine/prioritize + rank categories (drop late-funnel/transaction, add top-of-funnel). Does prompt wording materially change connector selection — Vincent’s hypothesis is yes (single-word nuances can decide whether a prompt even triggers a connector search), vs AEO research (Elliot) suggesting wording variation broadly yields similar results. See signal-set-and-weights.
• Convert from free to a paid/structured relationship?
• Can the ~15% Claude uplift be cleanly attributed to specific Ghostteam-recommended actions (vs general organic)? That attribution IS the 10-week deliverable.
• How long does Claude review take after tool-description/tool-definition changes, and how quickly do discoverability effects propagate after approval?
• Which Direct Booker prompts are realistic enough to optimize against now, and what changes once the Useberry / natural-prompt data arrives?
• How should Ghostteam detect whether Claude answered natively, used web/native tools, or recommended a connector for each hotel prompt?
• What trustworthy data signal separates a connector-picker appearance/invocation from native platform tool usage in Cowork/Codex/Claude?

Timeline

• [2026-07-06] (call — Vincent + Elliot + theresa-directbooker + sanj-directbooker) Recommendations session → the experiment started. Walked the registry-search recommendations (framed on DB’s priority-0/1 prompts only): headroom keywords = booking (ranked low), reservation/reservations/availability (absent, near-empty lists); plurality matters — cover hotel AND hotels. Agreed the four-change sequencing ~1 week apart; Theresa pushed change #1 (one-liner + availability/reservations) live during the call and confirmed field caps live (one-liner 200 chars, hers 79; long description 2,000, hers 977). #4 (long description incl. chain names) next week; 3 (tool names: add booking/availability/reservations, hotel+hotels) ride the next code release (~1.5 wks — engineer vacation; that release also adds a 4th tool). Surfaced: the 3-vs-2 tool discrepancy (prod 3 tools all “blocked” post-push; directory/registry show 2 — caching suspicion, fresh-install test, maybe chase Anthropic); DB’s ~30-spot directory jump + popularity uptick; super.com newly in the prompt universe (her read: discount OTA, price player); the chain brand-clause risk on naming Marriott/Hyatt/Hilton (test cautiously, may revert). We committed: verify the new version in tomorrow’s snapshot; check-in Thursday 2026-07-09, 13:00 Theresa’s time — Vincent sends the invite (out Friday). (Transcript tail after the goodbyes was an unrelated design session — excluded. Elliot’s duplicate recording of the same event was empty and archived alongside.)
• [2026-07-03] (research — Vincent, registry-search project) Registry-search recommendations finalized from the decoded backend (see Current truth + claude-registry-search-decoded): two tool renames + shortDescription append + optional chains sentence, each with per-keyword predicted outcomes and a next-day verification plan. Iteration history worth keeping: manage-reservations was cut on capability-honesty grounds (costs 1 rank on near-empty lists), and the tool-rename-vs-add question was settled empirically (search-equivalent; renames win on zero engineering). Client-ready report lives in the registry-search repo (DIRECT_BOOKER_CASE_STUDY.md) — a MADE artifact, not copied here. Note: the 2026-07-02 DB call transcript on this topic is still in the brain inbox awaiting ingest by its owner.
• [2026-07-01] (internal — afternoon working call 15:00, Vincent + Elliot, recorded by Vincent — the “align on hypotheses” call the morning stand-up planned; distinct from the stand-up entry below) Offer framing for the DB deck settled: drop the “50% off” framing — quote the tool at full price and give the managed-service component free for “one full optimization cycle” (asterisk: typically 1–3 months), deliberately NOT a fixed two-month window so DB’s internal “will we pay after month 2?” budget conversation never starts; we still timebox internally (“we can’t commit forever”). Elliot to finalize wording and send. Prompt-set frustration: Theresa kept her original transactional prompts (“book me a hotel in Lisbon”) as priority-0 instead of adopting the UserBerry top-of-funnel ones — Vincent calls it a mistake given DB’s own locked top-of-funnel goal (realistic flow = planning journey narrows to a destination, then booking triggers); agreed anyway to work her priority-0 prompts and optimize keywords there. Vincent’s lever read [idea]: keywords ≈ 90% of the actionable impact for DB now (other factors — brand training data, reliability/permissions, directory rank, user/tool volumes — are long-term games); correlations “dramatic: you add a keyword, you suddenly show up” (Netlify 0→17% retrievability purely from a tool update). Plan hatched on this call: reverse-engineer Claude’s connector tool search into an internal simulator (predict “does this keyword change get you retrieved + how high” before recommending; validate whether tool name outweighs description) — this became the registry-search decode project (→ claude-registry-search-decoded). Product idea logged: a keyword fan-out view per prompt (which keywords, at what frequency, per priority-0 prompt run). Also noted [idea] from live JSON inspection: rank within the retrieval list correlates with picker selection (later measured properly — see claude-connector-routing); connector “installed” vs “connected” are distinct states in the payload; blocked tools don’t appear in the returned data.
• [2026-07-01] (internal — Ghost Team stand-up, Vincent + Elliot, recorded by Vincent) Onboard DB to the platform ASAP is the near-term priority now the data-platform foundation is stable (background jobs/loading solved → features now ship fast, columns cheap to add/remove). Theresa needs to add prompts and see a priority view from day one. Vincent to reshare his ~2-week-old prioritized hypothesis backlog (not sent then — too early, prompts unknown) for Elliot to review before an afternoon call (~3–4pm Vincent’s time) whose goal is to align on hypotheses and write up + send findings to DB within the same hour. Elliot has a Codex-drafted factor doc (keyword & intent coverage, tool affordance, prompt wording…) to review first. Two parallel lists to produce: (1) core factors believed to drive agent discoverability generally, (2) near-term DB-specific actions. Prompt-priority feature decided: ship as a flexible tag column, not a rigid P1–P5 column (revisit once DB is live) — durable rationale: prompt priority is strategy-dependent and shifts over time (a new entrant should attack winnable niche queries first, e.g. “direct booking query”, not “book me a hotel in London” which Booking.com wins), which is why the platform shouldn’t hard-code a priority meaning; reinforces the niche-first / intent-based north star above.
• [2026-06-30] (internal discussion — Vincent + Elliot, recorded by Vincent) Aligned on the discovery-research framework for the DB engagement: two single-source-of-truth docs — all discovery factors (signal-set-and-weights) and the discovery flow in Claude (claude-connector-routing + the workflow chart) — with a working hypothesis Google Doc (not the wiki). Distinguish actionable levers (keywords, tool order, description length, new tools) from non-actionable ones (training-data familiarity). Planned analyses on benchmark data: directory-rank ↔ visibility within stable categories (project-mgmt/hotels/flights) and connector-update → visibility lift (only ~15–20 connectors updated per the daily catalog snapshot). Elliot sent Theresa the email prompting for her prompts; next is to set DB’s custom prompts and score them. Score Q raised: how keyword presence is weighted / calculated out of 30 (→ ado-score-model).
• [2026-06-26] (call — Vincent + Elliot + theresa-directbooker; Sanj invited, didn’t attend; recorded by Vincent — the actual client call, 3pm) First findings read-out to Theresa (after the two internal prep/deck sessions earlier the same day). Presented the four-R framework + ~1,000-run data on her 33 prompts (direct booking #1, ~100% shown → defend; generic no-brand retrieved but shown ~1/3; amenity/filter retrieved-not-ranked; named-brand competitive but big brands displace; corporate good; account-history ~zero — Theresa confirmed expected, DB doesn’t do transactions). Action prompts trigger pickers; advice/research route to web search (hotel-specific, not universal). Theresa articulated DB’s goal — top-of-funnel dateless discovery — backed by her UserBerry survey (dateless first-prompts) → seeded the dateless-tool hypothesis (OTA connectors require dates; she saw Last Minute→Booking.com fallback in ChatGPT). Tool-health anomaly: our snapshot saw only 2 of DB’s 3 tools; DB’s Jun-15/16 release was unstable on Claude (tools blocked-by-default; Claude may be blocking duplicate tool names across her ~6 local versions) — to investigate. Walked pricing (volume self-serve + enterprise; new customers ~50% off; DB kept free as anchor) + asked for referrals. Attribution: DB has session+click metrics (redirector) + Looker dashboard (access pending) + ChatGPT intent-capture as a path. Agreed next steps: GT sends prompt list (Excel) + deck; Theresa refines/prioritizes ~20 prompts + ranks categories; GT prepares recommendations; follow-up session ~Tue 30 Jun to present + agree, then run as a tracked experiment (existing prompts first, v2 adds more); Elliot to send the Expedia×Google ad link. Routed to signal-set-and-weights + pipeline.
• [2026-06-26] (internal deck-review — Vincent + Elliot, dual recording — Elliot not_oxT9 + Vincent not_xALu; Theresa NOT present) Built/iterated the Direct Booker findings deck (the “first read” to present to Theresa). Deck framing shifted to “to make meaningful suggestions we need to understand your strategy — where do you want to win?” (direct booking only, or broader). Client-facing framework collapsed to Retrievability → Rank (see discoverability-framework). Deck guardrails: keep core/training-data as a verbal caveat, off the slide (a strong-weight rank hypothesis we don’t yet track — don’t hand rivals a method we’re not even running); don’t over-share methodology (under NDA but could leak). Surfaced the ~1,000-run data picture + category-specific picker finding (both folded into Current truth). Experiment plan: existing prompts, optimize per topic category, ask DB to rank categories by priority, intent-based north star. Platform-freeze: Vincent freezing platform changes until after the Contour demo (dev/stage DB merges are messy); for that demo Elliot presents + shows the DB environment, Vincent on standby. Elliot’s score feedback is in the platform chat for Vincent. Findings routed to discoverability-framework, per-client-organic-surfacing (ChatGPT auto-search), company-memory-infra (idea-vs-fact convention).
• [2026-06-26] (internal prep — Vincent + Elliot, recorded by Vincent) Prep for the upcoming Theresa session (Theresa not on this call). Agreed session structure: goals → prompts (categories + volume) → high-level factor overview (oriented around the ADO score) → data-so-far overview → loop back to lock goals + prompt set. No recommendations on the call; ask for a few more days first. Performance read: ~100% on direct-booking prompts (niche won), weak on broad hotel queries; score low chiefly because the prompt set carries keywords DB doesn’t cover (expenses/receipts via “how much did I spend”; Auto wins those) — direct-only scope would be 90+. Niche-first (ASO) strategy: don’t change the winning direct-booking setup; expand from the owned niche. Process tension (resolved): Vincent argued the keyword fixes are already validated/obvious; Elliot insisted on no recs until goals + prompts are locked and the work structured as a research paper (goals → exhaustive factor list → hypotheses → isolated-variable tests) → resolved to gate all recommendations behind locked goals+prompts. Signals routed to signal-set-and-weights (brand-familiarity probe; prompt-trigger sensitivity) and a score-model note (ado-score-model); brain-trust gap routed to company-memory-infra.
• [2026-06-23] (call — “Directbooker next steps”, Vincent + Elliot, recorded by Vincent — internal working session) Discovery diagnostic: Direct Booker scores 76.81 vs Booking.com 92 on its own prompts. Retrieval is strong, but it doesn’t convert to selector/picker visibility for many prompts — the biggest value lever is closing the retrieval → picker-visibility gap. Plan: interrogate Claude prompt-by-prompt on a neutral no-memory account asking why DB was/wasn’t shown (method now lives in signal-set-and-weights). Flagged an API health nuance — DB’s connector is surface-”healthy” while specific tools had API problems; per-tool health (visible in the Claude dashboard) hits UX/outcome even if not discovery directly. Also surfaced that the score weighting (25/25/25/25/5) may overstate DB relative to its real appearance rate → consider weighting Rank more heavily (see ado-score-model).
• [2026-06-23] (call — Vincent + Elliot, recorded by Vincent) Scheduled a same-day Direct Booker call to align on the recommendation engine (how/why we suggest changes; needs an approach doc first). Agreed an interim path: generate reports from existing prompt runs while the platform UI is built. Surfaced the hotel-category fragmentation blocker (can’t benchmark vs relevant hotels) → re-categorization fix. See discoverability-framework and ado-score-model.
• [2026-06-19] (internal discussion — Elliot + Vincent, recorded by Elliot) Direct Booker strategy sync after the customer call. Reaffirmed Direct Booker as the mutual-investment anchor case study. Dashboard stats reviewed: 19k active users / 30d, 7k total tool calls, ~1k recent weekly tool calls across Claude AI + Cowork, with Cowork likely the largest source. Experiment design set: baseline current tool data/descriptions, use Theresa’s prompts while waiting for more realistic prompts, prioritize recommendations by top user intents, make isolated changes, and measure user/connection lift as well as ranking. Key risk: Anthropic review locks the connector and may force manual permission resets; ask Theresa for exact lock duration. Measurement gap: distinguish connector-picker invocations, native platform tool calls, web/native answers, and MCP widget appearances.
• [2026-06-17] (call) Direct Booker optimization call with theresa-directbooker, sanj-directbooker, elliot-garreffa, and vincent-mcleese. Theresa shared the Claude dashboard and the pending-review lock after pushing MCP server changes (new hotel lookup tool + changed descriptions); agreed to share before/after descriptions and screenshots. Ghostteam showed Direct Booker’s prompt summary: 43% picker visibility, visible on 14/33 tracked prompts, won 3 outright, 60% visibility on discovery prompts vs 32% on action prompts, ranked 5th overall / first non-OTA or major brand. Theresa challenged prompt realism and proposed collecting ~100 natural travel prompts via Useberry. Agreed to start optimization from the existing prompt set while better prompts are collected; Ghostteam to send detailed written answers and the Direct Booker prompt-summary deck.
• [2026-06-16] (internal discussion) Promoted from dormant/free to the anchor case-study objective: 10-week goal = a measurable, attributable lift; weekly calls + prompt runs + feature builds. Used as the live example in the awaze call (the most-visible hotel-category brand). Marriott investing interest noted (via Sanjay).
• [2026-06-08] (internal discussion) Logged in pipeline as “dormant (using us for free)”; Moby intro came via this relationship. See pipeline.