Build a Venue Sales Concierge That Remembers Every Planner

Event venues rarely lose leads because the ballroom is too small or the menu is wrong. They lose them in the gaps between systems.

A planner checks the website, then emails a question about capacity. Someone replies from a different spreadsheet. A week later, another salesperson calls without knowing which dates or budget the planner discussed. Even when every individual tool works, the experience feels disconnected.

I wanted to see what this workflow would look like if the website, concierge, availability database, and sales dashboard all worked from the same facts.

The result is Venue Sales Concierge, a TypeScript example deployed as one Telnyx Edge Function. It combines a venue microsite, SMS and voice conversations, live availability, per-planner context, lead qualification, and scheduled follow-up calls.

Start with the planner's journey

The application begins as a venue website. A planner can browse galleries, compare room capacities, review catering and AV options, see pricing, check dates, and request a site visit.

That public experience is connected to two conversational entry points:

• an SMS concierge reached through the venue's Telnyx number
• an in-browser voice concierge powered by a Telnyx AI Assistant over WebRTC

Both channels work from the same venue information shown on the website. The planner does not have to explain that they already saw the rooftop package or repeat the date they asked about in an earlier message.

Behind the public experience, the venue team gets an operations dashboard with inquiries, qualified opportunities, booked visits, live availability, and conversion rates.

Planner browser
  ├── GET /              venue microsite
  ├── GET /voice         browser voice concierge
  └── POST /api/site-visit

Planner phone
  ├── POST /webhooks/sms
  └── POST /webhooks/voice

Edge function
  ├── KV                 venue facts
  ├── SQLDB              dates, inquiries, and bookings
  ├── ConciergeAgent     planner context
  ├── AI Inference       replies and detail extraction
  ├── Messaging          SMS responses
  ├── Email              brochures and lead alerts
  └── Call Control       live and scheduled calls

One set of facts for every channel

The venue content lives in Telnyx KV. Galleries, spaces, menus, AV details, pricing, and FAQs are read by the microsite and also supplied to the AI concierge.

That gives the application a simple rule: if the venue updates a package or capacity, the website and the concierge should not drift apart.

Date availability is different. It changes frequently and needs to be queried, filtered, and reported, so the sample stores it in Telnyx SQL Database. SQLDB also records inquiries and site visits for the /ops sales dashboard.

The browser voice assistant receives static venue facts in its instructions. When a planner asks about specific dates, its signed lookup_venue_info webhook tool returns live availability from SQLDB. The assistant does not need to invoke a tool for every basic question, but it can reach the current booking data when freshness matters.

Give each planner a durable concierge

Every planner is routed to a ConciergeAgent actor keyed by phone number. The actor owns that planner's conversational state: message history, name, email, event type, guest count, budget, preferred dates, qualification status, and whether a site visit has been booked.

The shared business data stays outside the actor. The Edge function reads venue facts from KV and availability from SQLDB, then passes that context into the actor. After a conversation turn, the actor reports the extracted lead details back to the function, which writes the shared sales record and sends any required email.

That boundary is useful:

• the actor remembers one planner
• KV describes the venue
• SQLDB represents the venue's shared sales and booking state
• the Edge function coordinates the systems

For each turn, Telnyx AI Inference generates a grounded reply and extracts structured planner details. The application uses the Edge binding rather than placing an inference credential inside the source:

this.env.TELNYX.ai.openai.chat.createCompletion({
  model,
  messages,
  max_tokens: 600,
  temperature: 0.3,
});

The sample includes an inference fallback chain as well, so a model failure does not automatically end the planner's conversation.

Qualification should trigger action

A conversation becomes operationally useful when it changes what the sales team does next.

The concierge extracts the planner's event type, guest count, budget, dates, and contact details. When the example's qualification criteria are met, the function can email a brochure to the planner and send a lead alert to the venue sales inbox.

Site-visit requests write directly to SQLDB. The planner receives a confirmation over email and SMS, and the dashboard can show the conversion without waiting for someone to reconcile another spreadsheet.

Follow up without losing context

If an interested planner goes quiet without booking, the actor schedules a named follow-up task for one week later. A new planner message re-arms that timer, so the follow-up window reflects the latest interaction.

When the task runs, Call Control can place a personalized outbound call. The concierge already knows the planner's name and inquiry details. It can offer a keypad option to confirm a site visit, record that booking, send the confirmation, and close the loop in the same application.

Inbound calls use the same Call Control webhook path. The actor answers, gathers speech, sends the conversation through AI Inference, speaks the response, and continues gathering until the call is complete.

All Telnyx SMS and Call Control webhooks are verified with Ed25519 signatures before they affect the application.

Run it safely before enabling live sends

The example defaults to DEMO_MODE=true. Inference, KV, and SQLDB still run, but outbound SMS, email, and phone calls are logged instead of sent. That makes it possible to test the workflow without contacting real recipients.

git clone https://github.com/team-telnyx/telnyx-code-examples.git
cd telnyx-code-examples/venue-sales-concierge
npm install
cp .env.example .env
npm run typecheck
npm test
telnyx-edge ship

Before enabling live communications, configure your Telnyx number, messaging profile, Call Control connection, webhook public key, email destinations, KV namespace, and SQLDB instance. Provision the browser assistant after deployment with POST /api/setup-assistant.

The sample README covers the complete setup and API surface.

What this pattern changes

This example is not a replacement for a production CRM. Real deployments still need authentication on administrative routes, deliberate retention and access rules for lead data, monitoring, consent and compliance review, and tested failure handling.

The reusable idea is smaller and more important: a conversational sales agent becomes much more useful when it does not live beside the application as a separate chatbot.

Here, the website, SMS concierge, voice assistant, booking data, and sales dashboard share one operational context. A planner can move between touchpoints without forcing the venue team to reconstruct the conversation each time.

That is the difference between adding an AI chat box and building an actual sales workflow.