An event planner has three questions before they contact a venue: Is my date open? Can the space fit my guests? What will it cost?
Those answers often live in different places. A website has the room details, a spreadsheet has availability, and a sales rep has the context from the last email. The Venue Sales Concierge example brings them into one application running on Telnyx Edge Compute.
This is a TypeScript sample you can inspect and adapt. It serves a venue microsite, handles planner conversations over SMS and voice, records inquiries, and gives the sales team a bookings dashboard.
Start with one source of venue facts
The microsite shows galleries, room capacities, menus, AV details, pricing, and FAQs. Those facts come from Telnyx KV. When the concierge answers a question, it receives the same venue facts as context instead of inventing details that differ from the site.
Availability is separate: the application queries Telnyx SQL Database for dates. SQLDB also stores inquiries and site visits, which feed the /ops sales dashboard. The dashboard displays an inquiries-to-bookings funnel and recent activity.
GET / Venue microsite
GET /api/availability Live dates from SQLDB
GET /ops Sales dashboard
POST /api/site-visit Book a site visit
Give each planner a continuing conversation
An inbound SMS reaches /webhooks/sms. The function verifies the Telnyx webhook signature and routes the message to a ConciergeAgent actor associated with that planner's phone number.
The actor keeps conversation history and planner details such as event type, guest count, budget, and preferred dates. It generates a reply through the Telnyx AI Inference binding, grounded in KV venue facts and a current availability summary from SQLDB. The function records the resulting inquiry in SQLDB, where the venue team can see it.
That separation matters: the actor owns the planner's conversation state; the function owns the shared venue data and sales records.
When a planner provides an email and meets the example's qualification criteria, the application can email a brochure to the planner and send a lead alert to the venue team.
Add voice without a second application
The sample also serves /voice, a browser voice page connected to a Telnyx AI Assistant through WebRTC. Its lookup_venue_info webhook tool calls back into the same Edge function for live date availability.
Phone calls use Call Control webhooks. A planner who has gone quiet can receive a scheduled follow-up call after one week, and the call can offer a keypad option to book a site visit. Those live outbound actions require the relevant Telnyx number, connection, and configuration.
The important point is not that every channel has identical mechanics. It is that they share venue facts and booking data, while the application can carry planner context across touchpoints.
Try the example
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
Configure the KV namespace, SQLDB instance, Telnyx secrets, phone number, and Call Control connection as described in the README, then deploy with telnyx-edge ship.
One useful safety detail: DEMO_MODE=true is the default. In that mode, outbound SMS, email, and calls are simulated, while inference, KV, and SQLDB still run for real. Switch to live sends only after configuring your own destinations and reviewing the flow.
What I would change before production
The sample is a starting point, not a finished venue CRM. Before exposing it to real planners, I would lock down the setup and ops routes, review lead-data retention and access, test failure paths for external sends, and confirm the qualification rules with the sales team.
For a venue, the useful architectural idea is simple: the website, assistant, and sales dashboard should answer from the same facts. Otherwise, the first conversation starts with a correction.
Resources
Top comments (0)