VenueVox AI
A performer can ask which slots are open, and request one, over the phone.
Proof
- 2 tools
- The agent can query open slots or request a booking
- Pending
- A phone request is stored until the venue approves it
- Fallback
- If Gemini fails, the webhook speaks up to three slots from the database
The problem
Venues and performers trade availability over calls and email. The caller cannot see the calendar, and the venue cannot tell which request belongs to a real slot.
What I built
I built the marketplace and the phone path alone. Venues publish calendar slots. Performers discover them and send a request. Each organization can provision a Vapi receptionist whose tools read and write that venue's rows in PostgreSQL.
How it helps businesses and services
- A venue can take a performer call when nobody is free to answer. The receptionist only talks about slots that are still open.
- The call becomes a pending booking on that venue's calendar, so staff approve a real slot instead of reconstructing the request from notes.
- Performers request a published time instead of emailing back and forth before a date is even possible.
- One organization can run this across its venues, each with its own calendar and receptionist.
How it works
- 1
Call
A performer phones the organization's Vapi receptionist.
- 2
Normalize
The phone service sometimes hides the tool name inside a nested object, and sometimes sends the arguments as text. The server reads both shapes. Without that, it did not know which action to run.
- 3
Query
The lookup loads slots that are still open, dated in the future, and limited to that organization.
- 4
Speak
Gemini writes the spoken answer and is told never to say a slot id. If that call fails, a local fallback describes up to three slots with the weekday, date, and 12-hour times.
- 5
Book
The booking step writes a pending request. The same result includes the slot ids, so the receptionist can book without saying them. The venue approves or rejects from the calendar.
The hard part
The tool name never reached the handler
The phone service sometimes wraps the tool name inside a nested object, and sends the arguments as text. The server was reading the usual fields, found nothing, and replied that the action was unsupported. It now accepts both shapes before it looks up open slots or writes a booking. The spoken answer and the slot ids travel together: the reply is not allowed to say the ids, and the booking step uses them.
Stack
Backend
API
Data
Voice
Delivery
Frontend
App
State
Interface
What I owned
- Venue and performer dashboards, with calendar slots and an approve or reject path
- Checks that reject overlapping slot times
- A voice receptionist per organization, with provision and deprovision
- Call logs stored against that assistant
- Messages between a venue and a performer on a request
- Prisma models, a Swagger spec, and Docker Compose for Postgres, the API, and the web app