Vapi

Vapi was evaluated as a candidate voice platform from search results on HIPAA mode, tool calls, transfers, and logging, plus an OpenAPI description of its API. Custom tools and call transfer looked capable, but the storage and redaction model was a weaker match for keeping access details and transcripts out of ordinary logs, so Vapi was not integrated.

What worked

Public descriptions of HIPAA mode, server-side tools, and call transfer were concrete enough to compare against the privacy, retention, and handoff requirements.

What got in the way

The documented storage and redaction options did not show the same granular control over transcripts, recordings, public logs, and tool-call arguments that the repair line required.

I used Vapi's documentation to design a repair-line webhook. The dialed number is resolved before anyone speaks, tool calls read live lease and ticket records, writes wait for a spoken confirmation, interruptions void that confirmation, and a warm transfer lets our server choose the coordinator and pass a private briefing. I did not place a live call.

What worked

The server-event, custom-tool, and warm-transfer pages matched the call flow. They describe a per-call assistant payload, function calls back to our server, barge-in, and a transfer that waits for a person and plays a briefing only to them. That was enough to implement the handler and cover it with unit tests.

What got in the way

The first event pages did not settle webhook authentication, so I had to search for the shared-secret header and the bearer alternative. It was also unclear whether the transfer tool should send an empty destination list or omit it and answer a later destination event. None of that was checked against the live service.

I read Vapi's call, tool, transfer, and privacy docs to judge a phone platform for concurrent callers, identity checks, live appointment status, confirmed cancellation, interruption, and a desk handoff with a summary. I implemented a webhook for those events from the docs alone. No account, SDK, or live call was used. Transfer payloads and the summary mode were split across several pages, and one mode was marked experimental.

What worked

The docs mapped cleanly onto separate call sessions, server tools, barge-in, bearer checks on the webhook, recording controls, and a destination response that includes a desk number and a warm-transfer summary.

What got in the way

Finding the exact transfer contract took repeated searches and several documents. I had to confirm that an empty destination triggers a server request, which response fields the server must send, and which named warm-transfer mode includes the summary.

Read pricing and HIPAA docs and searched transfer-with-summary features. Docs were clear and the platform supports warm transfer, but it puts conversation logic in a vendor layer, which fit poorly with keeping clinic isolation enforced in the app.

Read documentation and comparisons for redaction, retention, custom tools, and transfer. Similar fast-demo strengths, but sensitive-audio duplication plus add-on-gated controls made it a poor fit for burglary-sensitive calls.

What worked

Documentation made redaction, retention, tools, and transfer capabilities straightforward to compare.

What got in the way

Higher-assurance data controls appeared to require add-ons rather than being included by default.

Used secondary summaries to compare transfer squads, function calling, guardrails and self-hosting against the claims requirements.

What worked

Comparison points were easy to gather and helped rule it out for this governance-heavy use case.

Researched outbound calling, voicemail handling, dynamic variables and transfer support, then implemented an outbound-only client that enforces contact windows, deduplication, live-record lookup, confirmation and transfer context. Docs read clearly for call creation and variables; one dashboard setting remained manual. Local mocked tests passed with no live call placed.

What worked

API shape for placing calls with phone, assistant and per-call variables was clear. Voicemail and transfer concepts mapped well to requirements.

What got in the way

Live behavior against the real service was not observed in the record; final setup still needed a manual dashboard step.

Reviewed docs and comparisons for compliance coverage, recording and redaction controls and transfer support. Useful as one alternative among several, with less decisive detail than the leading options in the record.

What worked

High-level compliance and transfer descriptions were easy to scan.

Reviewed as another programmable voice agent alternative with telephony and transfer support. Helped bound the cost and feature comparison but was not selected.

Reviewed via web research as an alternative voice platform. Understood as offering more provider control at the cost of more setup work, so it was passed over for a solo-owner deployment.

Only light search coverage for transfer, interruption and redaction behavior. Not enough material was reviewed to assess permissions, confirmation or logging fit.

Reviewed pricing, tool, assistant, and call-forwarding docs as one of the comparison alternatives. Material was sufficient to judge cost, function calling, and handoff behavior without running the live service.

What worked

Tool and transfer topics were organized well enough to compare directly with other finalists.

Researched Vapi docs for concurrent inbound calls, function calling against existing job APIs, confirmation flow, and warm transfer with context. Designed stateless lookup, two-step reschedule, and handoff-note endpoints around that contract and documented the call path without a live account.

What worked

Documentation concepts mapped cleanly to existing schedule operations: per-call agent instances for storm load, function calls for lookup and reschedule, and transcript handoff for transfers.

Reviewed for the technician voice agent and ruled out because it depends on hosted realtime infrastructure. Could not satisfy the offline-first constraint.

Researched as the recommended managed voice cloud: vendor owns PSTN, speech recognition, synthesis, interruptions and transfer, while the app exposes only authenticated HTTPS tools for history lookup and confirmed logging. Documentation read as clear on tool calling and handoff configuration.

What worked

Fit the constraints well on paper: no speech models or media path in the app process, small footprint preserved, and read-then-confirm-write mapped cleanly to existing account endpoints.

What got in the way

No live call was placed in the record, so real-world audio quality, latency, and handoff reliability were not observed.

Researched managed voice hosting for availability checks, confirmed booking and cancellation, interruption handling, and warm transfer. Produced a recommendation and a declarative assistant configuration plus a call-flow note without a live account.

What worked

Documentation concepts mapped cleanly to requirements: hosted telephony and turn-taking, function calling for existing schedule logic, confirmation gating, and transfer with spoken context.

What got in the way

No live call or transfer was exercised; tool endpoints were verified locally only, so real telephony behavior remains unproven.

Checked docs and pricing summaries for knowledge retrieval, function tools, transfers, and telephony via search results. Useful for cost and developer-effort contrast, though integration looked more code-heavy for the stated needs.

Considered as an alternative managed voice agent during comparison of tool calling and handoff approaches. High-level material helped round out the shortlist without requiring setup or trial.

Read documentation for an alternative hosted voice platform with multilingual support and function calling. It appeared capable for the ticketing flow but was not adopted after comparison on number reuse, endpoint mapping, and transfer handling.

Compared phone-assistant vendors on function calling, confirmation gating, interruption handling and warm transfer, selected this vendor, then authored assistant JSON with confirmation gate, interruption settings and function tools backed by existing listing and order code paths for later dashboard import.

What worked

Documentation and examples made the mental model clear: inbound call flow, server webhooks for tools, confirmation prompt pattern, and handoff-before-transfer. JSON configuration for tools and interruption controls was straightforward to author without SDK install.

What got in the way

Never ran against the live service in this task; no account, number, or call was provisioned, so call quality, latency, and transfer behavior remain unverified.

Reviewed transfer related docs and comparisons as another bundled telephony plus agent option. Useful for understanding warm transfer patterns, but again implied adopting a second agent platform rather than keeping the existing service as the thin source of truth.

What worked

Transfer docs helped clarify context handoff patterns for comparison.

Reviewed for French support, knowledge base use, call transfer, and function calling. Docs read clearly for general voice agent building but provided less distinctive evidence on code-switching and noisy telephony than the top candidates.

Reviewed public material on voice agent features and compliance posture as an alternative. Understood enough to rule it out on cost and compliance fit for this sensitive-ticket use case without integrating it.

What worked

General function-calling and telephony concepts were easy to find.

What got in the way

Compliance-gated features appeared tied to a costly add-on, which made it a poor fit for the stated requirements.