Hotel Outreach Automation

The problem: sales outreach that does not scale

Booking a meeting with a hotel general manager is not a cold-spam game. You need to know what booking engine they run, who their parent group is, what specific friction their reservations team has, and what makes their property different from the property four blocks away. That research takes about an hour per property when a human does it well.

When the target list is hundreds of hotels, that hour-per-property cost becomes an entire role. The sales team either skips the personalization (and tanks reply rates) or never gets through the list (and the pipeline dries up). In modern outbound, that personalization step is the single biggest time sink, and the one most worth automating.

The system: five stages, fully automated

The pipeline is intentionally generic. Each stage is a discrete n8n workflow that hands its output to the next, with retries and dead-letter handling at every step. Adding a new vertical (real estate, agencies, etc.) means swapping the discovery and prompt stages, not rebuilding.

Stage 1: Discovery

A custom Playwright collector crawls public hotel directories and search endpoints, gathering candidate properties that match a target profile (size, location, segment). Output: a deduplicated list of property names, URLs, and basic firmographic data.

Stage 2: Enrichment

For each property, the system pulls structured data the AI will need to personalize: booking engine detected (via a separate Go service that runs a three-stage cascade: HTML signature, link follow, then headless browser), parent group, contact email patterns (enriched with our own platform, enrichabl), recent reviews, and a one-paragraph property summary collected from the hotel's own About page.

Stage 3: Personalization

The enriched record is handed to the Claude API with a structured prompt that includes the property summary, the detected booking-engine pain points, and our offer template. The model produces a 60-90 word email that references something specific about the property, ties it to a measurable friction, and ends with a single low-commitment ask. We use the Anthropic prompt-engineering patterns (clear role, structured examples, explicit do-not-do list) so the output is consistent across hundreds of generations.

Stage 4: Sending

Approved messages go through Smartlead with per-domain warmup, sending windows tuned to the target's time zone, and A/B variants on subject line. Send pace is throttled to keep deliverability healthy across many properties per day.

Stage 5: Reply handling

Inbound replies hit a classifier that buckets them as positive, objection, OOO, or unsubscribe. Positives auto-book into a calendar slot and notify the founder in Slack; objections get a one-shot context-aware follow-up drafted by Claude and queued for human approval.

The tech stack

• Orchestration: n8n, self-hosted on Hetzner. Picked over Zapier and Make because the pipeline has loops, branching, and custom code nodes that the hosted no-code tools either cannot do or charge per-execution prohibitively for.
• AI: Claude API (Sonnet for personalization, Haiku for the reply classifier). The quality/cost tradeoff lands cleanly on Anthropic models for this workload.
• Discovery: Playwright (Python) for the collector, with a Go service running the booking-engine detection cascade.
• Sending: Smartlead with multi-inbox rotation. Replies route back into the n8n pipeline via webhook.
• Storage: Postgres (Supabase) for property + send + reply records, batched writes from the n8n flow.

The results

Specific per-campaign reply and meeting numbers are kept confidential. What we can report honestly is the time the system takes off the manual workflow:

We report time saved per task rather than precise per-campaign figures, to protect client confidentiality. Exact results vary by list size, offer, and target market.

How a build like this rolls out (5 phases)

1. Discovery (week 1): map the target list, the existing sales motion, and where the hour-per-property cost lives. Decide what to keep human and what to automate.
2. Architecture (week 1-2): pick the orchestration tool, the model, the sending stack, and the data model. Write a one-page diagram so the entire system fits on one screen.
3. Build the unsexy parts first (week 2-3): data collectors, enrichment, dedupe, write-backs. The AI step is the easy part if the data going into it is clean.
4. Tune the AI step (week 3): run the personalization stage against a sample of 20 properties, eyeball every output, iterate the prompt until 18 of 20 are send-worthy without edits.
5. Ship, monitor, iterate (week 4+): send live, watch deliverability and reply quality dashboards, adjust cadence and prompts from real signal.

Why this pattern generalizes

The architecture (discover → enrich → personalize → send → handle replies) applies to any outbound motion where personalization is the bottleneck. Real estate brokers, professional services, recruiters, agencies. The same five stages. The model behind the personalization step and the discovery query are what change.

In every one of these motions, the hard part is not the AI. It is the plumbing that gets clean data in and clean, approved actions out. That is what this build solves.

We package this pattern as GTM engineering, and run an operational variant for hotels and hospitality groups. Same plumbing, a different front door.

Frequently asked questions