The problem: missed calls and phone intake
When a team cannot answer a call, an enquiry can arrive without the details or next step needed to follow it up. Answering the phone is only part of the workflow: someone still needs to capture the request, route it, and review what happened.
VocalDesk explores that workflow through a platform for building and testing AI phone agents. This is our own product engineering, not a client deployment with measured results. We do not claim that it reduced missed calls or improved conversion.
What VocalDesk does
The public repository contains a web application for configuring phone agents and reviewing calls. The README says only “Build and Test AI Phone Agents”; the feature descriptions here come from the code and repository structure.
- Configure a phone agent's prompt, voice, language, and transfer number.
- Manage inbound agent settings and initiate outbound calls, including batch-call workflows.
- Add agent information through a knowledge-base interface with manual input, website crawling, and file-upload paths.
- Review call logs and transcripts, with code for retrieving call recordings from the voice provider.
- Configure live-transfer destinations by department.
- Send call summaries and caller details through configured email, SMS, and webhook notification paths.
- Connect tools through API-request configuration; the repository also contains calendar-related interfaces and routes.
These are features and implementation paths visible in source, not proof that every integration works in a current deployment.
Uncertainty and handoff to people
The code shows configurable human handoff: a transfer number in the phone-agent form and a live-transfer list mapping departments to phone numbers. The call-completion handler includes the transferred-to destination in its notification data, alongside the summary and transcript. This gives a person context to review after a call.
Those mechanisms show transfer and review paths. The inspected source does not establish a tested rule that automatically detects low confidence and transfers every uncertain call. The completion handler substitutes “Not enough information to generate summary.” when a summary is missing; that is a missing-summary fallback, not a confidence-based escalation policy.
The architecture in plain words
VocalDesk is the application layer around a third-party voice service.
- A browser workspace: Next.js, React, and TypeScript provide the pages for agent configuration, prompts, integrations, and call review. Tailwind and reusable interface components support the screens.
- Accounts and stored settings: Supabase provides authentication and database access. The repository includes database definitions and migrations for the application's stored records and settings.
- The phone-agent connection: Server-side utilities call Bland's API to manage inbound agents, initiate calls, manage tools, and retrieve call information and recordings. The app configures the service rather than implementing its own speech engine.
- Business-tool connections: API routes connect external tools and calendar services. These are the paths by which a configured agent can reach beyond the conversation.
- Call follow-through: A call-completion webhook receives provider results and prepares a summary, transcript, caller fields, and transfer information. Configured notification providers send information by email or SMS, and a configured webhook can forward it to another system. Twilio appears in the SMS notification provider; its presence alone does not prove a particular telephony deployment setup.
The public code can be inspected and adapted. Running it still depends on external services, credentials, configuration, and verification.
What it shows a buyer
A voice agent needs more than a prompt. It needs configuration, tool connections, a way to reach a person, and a record that an operator can review. VocalDesk makes that surrounding engineering inspectable.
It is evidence of V12 Labs' own phone-agent product work. It does not establish measured client savings, call accuracy, successful live transfers, or production reliability. A buyer should ask to see their own intake examples, exceptions, and handoff behavior tested before relying on a similar workflow.
Sources and verification scope
Read on 9 October 2026: the repository, its README, and the recursive repository tree. The following files substantiate the descriptions:
- Package manifest: application stack.
- Phone-agent form: configuration and transfer number.
- Live-transfer settings: department-to-number transfer list.
- Agent utilities: Bland API calls and recording retrieval.
- Call-completion webhook: caller data, transcript, summaries, transfer destination, and notification paths.
- Knowledge-base interface: manual input, website crawl, and upload paths.
The engineering article was also read for context; the feature and handoff claims here stay within the inspected repository evidence. This was a source review, not a runtime test or deployment audit.