Build a Custom Voice AI for Legal Intake and Scheduling

Most firms try to solve intake with virtual receptionists or basic phone tracking software. Services like Smith.ai use human agents, which creates a bottleneck and introduces high variable costs. A receptionist can only handle one call at a time and per-minute fees for a firm handling 300 calls a month can exceed $1,000.

A personal injury firm we worked with saw this failure firsthand. After a TV ad ran, their call volume surged from 10 to 40 calls per hour. Their receptionist service was overwhelmed, callers were put on hold, and 15 potential high-value cases were lost to voicemail in a single evening. Human-gated systems cannot handle spikes in demand.

Other tools like CallRail are designed for marketing attribution, not interactive intake. They can record calls and provide transcripts, but they cannot ask follow-up questions, check a lawyer's calendar availability via API, or create a new matter in your CMS. This leaves your staff with hours of manual work listening to voicemails and transcribing details, a process that takes 6-8 minutes per potential client.

Syntora would approach the problem by first mapping your firm's exact intake script and scheduling logic into a state machine. We would use Twilio's Programmable Voice API to receive all incoming calls. The system would be deployed as a series of AWS Lambda functions connected by an API Gateway. This architecture is designed for cost efficiency, with typical infrastructure costs remaining low, even for high call volumes.

For the conversational component, the system would pipe the audio stream to AWS Transcribe for real-time speech-to-text. The transcription would then be sent to the Claude 3 Sonnet API. Syntora has experience building document processing pipelines using Claude API for extracting information from financial documents, and the same pattern applies to processing voice transcripts for legal intake. A carefully engineered prompt would guide the model to ask specific qualifying questions, extract key entities like name and case type, and summarize the caller's issue. This design targets a low round-trip latency from when a caller finishes speaking to when the AI responds, aiming for a natural conversational flow.

Once the required information is collected, the system would take action. We would write a Python service using httpx for asynchronous API calls to your case management software, whether it is Clio, MyCase, or a custom internal tool. This would create a new contact and matter, preventing duplicate data entry. For scheduling, the system would connect directly to Google Calendar or Microsoft 365 APIs to find and book an available slot on the correct attorney's calendar. This process would integrate with your existing systems to streamline the intake and scheduling workflow.

After every call, a complete transcript and structured summary would be posted to a dedicated Slack channel and logged in a Supabase database. Syntora would implement structlog for detailed logging of every function execution and API call. If the AI fails to understand a caller after two attempts, the call would be automatically forwarded to your office line with the conversation context. This fallback mechanism is designed to minimize dropped leads and ensure continuity in the intake process.