Context
A wine bar in São Paulo, part of a multi-venue hospitality group. Inbound traffic — reservation requests, modifications, table inquiries — was landing directly in the founder’s WhatsApp, where it competed with everything else a founder running a multi-venue operation needs to do.
The bar team had partial visibility, but the structured path (lead → confirmation → seated) wasn’t running through any system. Conversations lived in WhatsApp scrollback. The founder was the bottleneck on a $-generating channel.
What I built
A WhatsApp AI agent fronting all inbound guest conversation, with the bar team’s operational surface kept in Airtable (where the team already lived) rather than a CRM they’d never adopt.
- Conversational AI agent on WhatsApp (Z-API) handling guest inquiries, reservation requests, modifications, and confirmations.
- OpenAI-powered conversational layer with structured flows for booking intake — party size, date, time, dietary preferences, special-occasion flags.
- Redis for short-term session state — conversation memory across multi-message exchanges, debouncing of inbound bursts when a guest fires off three messages in 30 seconds.
- Supabase as the durable state layer — guest history (returning guests recognized across visits), conversation logs, reservation status.
- Airtable as the bar team’s operational surface — day-of view, guest notes, table assignments. The team never touches the AI stack; they work in Airtable.
- n8n orchestrating Z-API ↔ OpenAI ↔ Redis ↔ Supabase ↔ Airtable.
Outcome
- Founder removed from the inbound conversation loop. Reservation traffic no longer landed in the founder’s personal WhatsApp.
- 24/7 first-touch coverage with consistent tone — guests no longer hit dead air at off-hours.
- Zero missed messages. Every inbound got an immediate response, even at 2am, with structured handoff to staff for anything outside the AI’s confidence threshold.
- Operational visibility for the bar team in Airtable — they could see the day’s reservations without learning n8n, Redis, or any of the plumbing.
Why this engagement matters
This is the same AI SDR architecture used in B2B SaaS (WhatsApp + LLM + Redis + Supabase + n8n), transposed to hospitality. The contract is different — “lead to enrollment” becomes “guest to reservation” — but the building blocks are identical.
Demonstrates pattern portability across verticals. The same shape works for any conversational close-the-loop flow with state: support intake, mentoring enrollment, appointment booking, demo scheduling, returning-customer outreach. The work isn’t rebuilding the stack per industry — it’s writing the right domain contract on top of a proven architecture.