Build a Voice AI Agent for Recruiting Follow-up

Recruiting teams often try voice-blasting services first. These systems play a pre-recorded message and ask candidates to press a number. They cannot handle a simple question like, "What are the working hours?" If a candidate asks anything, the call fails, and a human must listen to the recording later. This creates more work, not less.

The next step is often a visual IVR builder like Twilio Studio. These are more flexible but still rigid. A workflow can check for keywords, but if a candidate says, "Can I talk to someone?" instead of an expected phrase, the system hangs up. They also lack state management, so they cannot remember a candidate's name from the ATS to personalize the conversation.

Consider a regional logistics company hiring 50 warehouse staff using Lever as their ATS. They use a dialer to call 300 applicants with a "Press 1 to schedule" message. Only 15% respond. The other 85% ask a question the system cannot answer, creating a list of 255 voicemails for one recruiter to review. The process took longer than just calling them manually.

Syntora's approach would begin with a discovery phase to understand your existing ATS and workflow. The system would connect directly to your ATS API, whether it is Greenhouse, Lever, or another platform, using Python with the httpx library for asynchronous API calls. This initial integration would pull candidate contact information and job details, establishing a call queue in a Supabase database table for a specified period, such as the last 30 days of applicants for a role.

The core conversational agent would be a FastAPI application, deployable on platforms like AWS Lambda. Upon a new candidate entering the queue, a Lambda function would be triggered. This function would utilize the Claude 3 Sonnet API for dynamic conversational logic. Syntora would engineer the agent's prompt to incorporate job descriptions, company information, and a curated list of common questions and answers, enabling the agent to manage typical candidate inquiries and clarifications. We have experience building similar document processing pipelines using Claude API for financial documents, applying the same pattern to structured information for conversational agents.

After a call completes, the system would summarize the conversation and write a note back to the ATS via its API. If a candidate agrees to an interview, the agent would access the recruiter's Google Calendar to offer available time slots.

Structured logging with structlog would be implemented for all call events. Transcripts, call durations, and outcomes would be sent to AWS CloudWatch. An alert would be configured to notify relevant personnel, for example via Slack, if the percentage of failed calls, such as technical errors or hang-ups, exceeds a defined threshold within a specific timeframe, enabling proactive monitoring and intervention.

A typical engagement for a single-role conversational agent of this complexity might range from 8 to 12 weeks for initial deployment, followed by an optimization phase. Clients would need to provide API access to their ATS and recruiter calendars, along with detailed job descriptions and FAQs. Deliverables would include the deployed, tested voice agent, source code, and comprehensive documentation for ongoing management.