Blueprint GTM Playbook

Data-Driven Outreach for Tripleseat

About This Playbook

This playbook was generated using the Blueprint GTM methodology—a system for creating hyper-specific, data-driven outreach that proves prospects are in a painful situation using publicly available data sources.

Methodology by Jordan Crawford | Blueprint GTM Intelligence System

The Problem: Generic Outreach Doesn't Work

❌ The Old Way (Generic SDR Email)

Subject: Quick Question about Tripleseat Hi [First Name], I noticed on LinkedIn that Tripleseat recently expanded. Congrats on the growth! I wanted to reach out because we work with companies like SevenRooms and OpenTable to help with event management challenges. Our platform streamlines booking workflows, improves conversion rates, and provides better pipeline visibility. We've helped companies achieve 20-30% increases in event revenue. Would you have 15 minutes next week to explore how we might be able to help Tripleseat? Best, Generic SDR

Why this fails:

No specific data about the prospect's situation
Generic "noticed on LinkedIn" opener (obvious template)
Features and benefits that apply to everyone
Asks for a meeting without providing value
No proof the prospect has the problem you solve

✅ The New Way (Blueprint GTM Methodology)

Hard Data vs. Soft Signals: The Blueprint methodology replaces soft signals (LinkedIn activity, funding announcements, hiring posts) with HARD DATA from public databases—government records, competitive intelligence, velocity signals, and operational data that PROVES a prospect is in a painful situation.

PQS (Pain-Qualified Segment): Messages that mirror an exact painful situation using specific data the prospect can verify. These create immediate recognition and curiosity.

Strong PQS: These plays identify pain with verifiable data and seek engagement. They don't provide the complete solution upfront—they earn a reply by demonstrating you've done research and understand their situation.

Your Target Market

Company: Tripleseat provides event management software for restaurants, hotels, and venues to streamline private event bookings, group sales, and catering operations.

ICP (Ideal Customer Profile):

Multi-location hospitality operators (restaurant/hotel chains with 5+ properties)
High-volume independent restaurants/venues (50+ events per quarter)
Restaurants dependent on 3rd-party delivery platforms (DoorDash, Uber Eats) for catering

Target Persona:

Title: Catering Director, Event Manager, Group Sales Manager, Director of Operations
Responsibilities: Event bookings, catering sales coordination, group revenue management, operational efficiency
KPIs: Event revenue growth, booking conversion rate, average party size, commission costs, operational efficiency
Pain Points: Manual booking processes (email/Excel chaos), platform commission fees (20-30%), fragmented multi-location systems, poor pipeline visibility

Strong PQS Plays

Play 1: Multi-Location Visibility GapStrong (8.8/10)

Segment: Multi-location restaurant/hotel chains (5+ properties) without unified event management system

Trigger Event: Brand operates multiple locations with per-location event business but no centralized booking/reporting system, causing operational fragmentation and zero corporate visibility into aggregate pipeline.

Why It Works (Buyer Critique Insights):

Situation Recognition (9/10): "7 locations, 5 active" is hyper-specific to multi-location brands and directly hits corporate-level pain
Data Credibility (9/10): Location count and review analysis are both publicly verifiable via Google Maps
Insight Value (8/10): "5 of 7 locations show event business" is NEW information—prospects typically don't track this across properties. "No way to see which convert best" hits a major blind spot.
Effort to Reply (10/10): "Want the breakdown?" is ultra-low friction (yes/no answer)
Emotional Resonance (8/10): "Zero visibility" triggers pain point (they KNOW they're blind to aggregate performance). "Which locations convert best" is a gap they feel acutely.

DATA SOURCES:
1. Google Maps Places API (Text Search) - Location count via results[].place_id field
2. Google Maps Places API (Place Details) - Per-location reviews via reviews[].text field
Confidence: 75% (official API data, but event volume threshold is proxy-based)

Subject: 7 locations, zero visibility I mapped your 7 locations—5 of them show active event business in reviews, but each appears to run booking independently. Corporate has no way to see which locations convert best or where event pipeline is strongest. Want the breakdown?

CALCULATION WORKSHEET:

CLAIM 1: "7 locations"

Data Source: Google Maps Places API Field: results[].place_id URL: maps.googleapis.com/maps/api/place/textsearch/json?query=[Brand+Name]+restaurant Calculation: - API returns results[] array - Count unique place_id values = 7 locations Confidence: 95% (official Google data) Verification: "Search your brand name on Google Maps, count locations"

CLAIM 2: "5 of them show active event business"

Data Source: Google Maps Places API (per-location reviews) Fields: reviews[].text for each place_id Calculation: - For each of 7 locations, fetch reviews - Count locations where ≥5 reviews contain event keywords: ["private event", "birthday party", "rehearsal dinner", "corporate event", "wedding reception", "booked the room/space"] - Result: 5 out of 7 locations meet threshold Confidence: 80% (API data, but threshold is judgment-based) Verification: "Check reviews for each location for event mentions"

CLAIM 3: "each appears to run booking independently"

Data Source: Website/listing inspection per location Method: Manual observation of booking methods Calculation: - Inspect each location's Google listing or website - Check for unified booking system vs. independent contact methods - Boolean: Different phone numbers/forms = independent Confidence: 70% (observable via manual inspection) Verification: "Check how customers book events—same system or different per location?"

Play 2: Platform Commission AuditStrong (8.4/10)

Segment: High-traffic restaurants with 20%+ menu markup on delivery platforms (DoorDash, Uber Eats) and no direct ordering infrastructure

Trigger Event: Restaurant paying 20-30% commission on catering orders via 3rd-party platforms without direct ordering alternative, resulting in $2,000-5,000/month avoidable margin erosion.

Why It Works (Buyer Critique Insights):

Situation Recognition (8/10): "28% markup" and specific examples ($14→$18 burger) are verifiable and mirror platform dependency pain
Data Credibility (8/10): Menu pricing is directly verifiable. "$3,200/month" is estimated (extrapolated from review velocity), but disclosed with "likely"
Insight Value (9/10): Prospects KNOW they pay commissions but haven't calculated exact monthly cost. "$3,200/month" quantifies what they felt vaguely. "28% markup across items" is specific audit they haven't done.
Effort to Reply (8/10): "Does this match your statement?" is easy to verify (check DoorDash statement)
Emotional Resonance (9/10): "$3,200/month" hurts—that's real money leaking. Specific enough to trigger urgency. Question is CURIOUS, not accusatory.

DATA SOURCES:
1. Web scraping (restaurant website + DoorDash) - Menu item prices
2. Google Maps Places API - Review velocity via reviews[].time field
Confidence: 60% (scraping reliable, but commission calculation requires inference: reviews → orders → revenue)
Disclosure in message: "I tracked" (research done) and "likely" (estimate)

Subject: $3,200/month to DoorDash I tracked your menu pricing—28% average markup on DoorDash vs. your website ($14 burger → $18, $22 pasta → $28). At your review velocity (42/month), that's likely $3,200/month in platform fees you're conceding. Does this match your statement?

CALCULATION WORKSHEET:

CLAIM 1: "28% average markup on DoorDash"

Data Source: Web scraping (website + DoorDash) Fields: Menu item name, price per source Tools: Playwright/Selenium or manual comparison Calculation: - Sample 15-20 comparable items from both menus - For each item: (DD_price - Web_price) / Web_price - Average across all items = 28% Confidence: 75% (scraping reliable, but menus may differ in portions/options) Verification: "Compare 5-10 items on your website vs. DoorDash app"

CLAIM 2: "review velocity (42/month)"

Data Source: Google Maps Places API Field: reviews[].time (UNIX timestamps) Calculation: - Filter reviews to last 30 days - Count reviews with time within (current_date - 2,592,000 seconds) - Result: 42 reviews in last 30 days Confidence: 95% (API data, exact count) Verification: "Check Google Business Profile for last 30 days"

CLAIM 3: "likely $3,200/month in platform fees"

Data Source: Derived (multiple inference layers) Calculation: - 42 reviews/month ÷ 3% review rate = ~1,400 monthly orders - 1,400 orders × avg ticket $18 × 28% markup ÷ 1.28 = $3,136/month - Rounded to "$3,200/month" Confidence: 60% (heavy inference - assumes review rate, avg ticket) Disclosure: "likely" signals estimation Verification: "Compare to actual DoorDash monthly statement"

Play 3: Commission Range AnalysisStrong (8.2/10)

Segment: Platform-dependent restaurants (same as Play 2, variant approach)

Trigger Event: Same as Play 2—high-traffic restaurant with 25-30% platform markup paying $2,800-3,500/month in avoidable commissions.

Why It Works:

Situation Recognition (8/10): Same verification path as Play 2, specific data
Data Credibility (8/10): Range instead of exact figure provides better disclosure of estimation
Insight Value (8/10): "25-30% markup" and "$2,800-3,500 range" quantify hidden cost. "TripleseatDirect could eliminate" adds solution context.
Effort to Reply (9/10): "Want the breakdown?" is yes/no, very low friction
Emotional Resonance (8/10): Range feels slightly less precise than Play 2 (less impactful), but "eliminate" is strong word (solution-oriented)

DATA SOURCES: Same as Play 2 (menu scraping + Google Maps review velocity)
Confidence: 60% (same inference layers, but range format reduces false precision)
Disclosure: "likely" + range format signals estimation

Subject: Commission audit I compared your website vs. DoorDash pricing on 12 items—you're marking up 25-30% to cover their commission. Combined with your 40+ review/month velocity, you're likely paying $2,800-3,500/month that TripleseatDirect could eliminate. Want the item-by-item breakdown?

CALCULATION WORKSHEET:

CLAIM 1: "12 items...25-30% markup"

Same method as Play 2, but expressed as range

CLAIM 2: "40+ review/month velocity"

Same Google Maps API method as Play 2

CLAIM 3: "$2,800-3,500/month"

Calculation: - Same formula as Play 2, but expressed as range - Low end: 40 reviews × 3.5% rate × avg ticket $17 × 25% markup ÷ 1.25 = ~$2,800 - High end: 40 reviews × 2.5% rate × avg ticket $19 × 30% markup ÷ 1.30 = ~$3,500 Confidence: 60% (same inference, but range reduces false precision) Verification: "Compare to actual DoorDash statement"

Play 4: High-Volume Manual BurdenGood (7.8/10)

Segment: High-event-volume independent restaurants (single-location) without event management software

Trigger Event: Restaurant with 15+ event-related reviews in 90 days (extrapolates to ~60-80 events/quarter) managing bookings manually via email/phone, creating 5-10 hour/week administrative burden.

Why It Works:

Situation Recognition (8/10): "18 mentions in 90 days" is specific and verifiable
Data Credibility (9/10): Google reviews are publicly verifiable, can check immediately
Insight Value (7/10): "5-10 hour/week burden" IS new information (prospects haven't tracked time). "No system detected" confirms what they already know.
Effort to Reply (9/10): "Who handles this?" is VERY easy to answer (name or "me")
Emotional Resonance (6/10): Less urgent than other plays, more informational

DATA SOURCES:
1. Google Maps Places API - reviews[].text and reviews[].time fields
2. Website inspection or BuiltWith API - Tech stack detection
Confidence: 70% (review data HIGH, time burden calculation is estimated)

Subject: 18 private events detected Your restaurant shows 18 Google reviews mentioning private events in the past 90 days—but I don't see Tripleseat, SevenRooms, or any event booking system on your site. That volume manually likely means 5-10 hour/week admin burden just on event coordination. Who handles this currently?

CALCULATION WORKSHEET:

CLAIM 1: "18 reviews mentioning private events in past 90 days"

Data Source: Google Maps Places API Fields: reviews[].text, reviews[].time Calculation: - Filter reviews with time within last 90 days (7,776,000 seconds) - Regex match: /private (party|event)|birthday|rehearsal dinner|corporate (event|group)|booked the (room|space)/i - Count matches = 18 Confidence: 85% (API data, keyword matching may miss synonyms) Verification: "Check Google Business Profile reviews from last 90 days"

CLAIM 2: "don't see Tripleseat, SevenRooms, or any event booking system"

Method: Website inspection + BuiltWith API Fields: Software widgets/plugins Calculation: - Inspect HTML source for Tripleseat embed, SevenRooms widget, OpenTable module - Boolean check: Present/Absent - Result: Absent = no system detected Confidence: 80% (may miss custom solutions, major platforms detectable) Verification: "Check your website for online event booking"

CLAIM 3: "5-10 hour/week admin burden"

Data Source: Derived (time-per-event benchmark) Calculation: - 18 events in 90 days = ~6 events/month - 6 events × 45-60 min per event (email, BEO prep, confirmation) = 4.5-6 hours/month - Plus inquiry response time for non-converts = ~5-10 hours/week total Confidence: 50% (pure inference, no data basis) Disclosure: "likely" signals estimation Verification: "Track time spent on event coordination for one week"

This play may benefit from additional data refinement to strengthen the time burden calculation with industry benchmarks.

The Transformation

The difference between generic outreach and Blueprint GTM is simple: proof over promises.

Instead of asking prospects to trust that you understand their pain, you demonstrate it with data they can verify themselves. Instead of leading with features and asking for a meeting, you earn engagement by providing insights they don't have access to.

Key Principles:

Hyper-Specific: Use exact numbers, dates, record IDs, field values—not "recent," "many," or "some"
Factually Grounded: Every claim traces to a documented data source with a mechanical detection method
Non-Obvious Synthesis: Combine multiple data points to reveal insights the prospect doesn't already know
Curious, Not Confrontational: Questions should feel like helpful inquiry, not audits or accusations
Confidence Disclosure: When using hybrid approaches (competitive + velocity data), disclose estimation with "likely," "estimated," or range formats

This playbook contains 4 Strong PQS plays (scores 7.8-8.8/10) that identify pain with verifiable data and seek engagement. These plays don't provide complete solutions upfront—they earn replies by demonstrating research depth and genuine understanding.

The result? Outreach that cuts through inbox noise because it mirrors the prospect's exact situation with data they can verify right now.