AI Voice Agent for Real Estate Lead Qualification — A Case Study

TL;DR

We designed a proof-of-concept AI voice agent for a real estate developer that automatically dials newly created CRM leads, holds a natural Hindi/Hinglish qualification conversation, and hands back clean, structured data — budget, preferred location, configuration (BHK), and purchase timeline — straight into the client's existing CRM workflows. Built on LiveKit, Sarvam AI speech models, and Google Gemini, and wrapped in a compliance-first architecture aligned with India's TRAI/DLT and DPDP frameworks, the system proves that the first qualification call — traditionally handled by a telecalling team — can be automated end to end, without adding headcount and without compromising on consent or call-quality standards.

Problem Overview

Our client, a real estate developer, generates a high volume of inbound leads through property portals, website forms, and walk-ins across multiple ongoing projects. Like most real estate businesses, their bottleneck wasn't lead generation — it was lead qualification. Every new lead needs a first conversation to establish basic fit, and that conversation traditionally falls to a telecalling team that doesn't scale.

• Real estate leads go cold within hours, and manual telecalling queues introduce delay that directly costs conversions
• Leads expect to be spoken to in natural Hindi/Hinglish, not a rigid English script or an IVR menu
• Telecaller notes were inconsistent, while sales teams needed budget, location, BHK, and timeline as clean, filterable data
• Outbound calling in India carries real exposure under TRAI/DLT telecom rules and the DPDP data-protection framework
• Calls fail in messy ways — rejected rings, voicemail, no-answer, dropped legs — and each had to be classified correctly, not lumped together as "failed"
• The client's existing CRM automation already ran through Zoho/HubSpot via n8n, so any AI layer had to plug into that, not replace it

Role & Responsibilities

• Role: Voice AI architecture and full-stack engineering team
• Responsibilities:
  • Design and build the outbound voice agent platform end-to-end as a proof of concept
  • Architect a compliance gate — consent, suppression, and calling-window checks — ahead of every dial
  • Integrate LiveKit for real-time voice, Sarvam AI for Hindi/Hinglish speech, and Google Gemini for conversation reasoning
  • Build the dispatch service and integrate it with the client's existing n8n and CRM workflows
  • Design the call-outcome model so the CRM can react differently to connects, no-answers, voicemails, and failures

Project Context

• Client: Real estate developer (referred to generically to protect confidentiality)
• Industry: Real estate — outbound lead qualification and CRM automation
• Purpose: Qualify inbound leads within minutes of CRM entry, in natural Hindi/Hinglish, and feed clean structured data straight into the CRM — proving the architecture on a lean POC before a full production rollout
• Constraints: India's TRAI/DLT and DPDP compliance requirements, unreliable SIP call signalling, an existing CRM/n8n workflow that couldn't be replaced, and the need for a natural-sounding conversation rather than a rigid IVR script

My Approach

We designed the system around a simple separation of concerns: one service decides whether and when to call, and a separate worker owns the actual conversation once the call connects. This kept regulatory logic centralised and testable, and kept the conversational agent focused purely on talking to the lead.

• Discovery: Mapped the real constraints the system had to work within — speed-to-lead, language expectations, regulatory exposure, and call reliability
• Compliance-first design: Placed the compliance gate inside the dispatch service itself, not only inside the workflow tool, so a later workflow change couldn't accidentally bypass consent checks
• Hybrid scripting: Hardcoded only the opening greeting for compliance and brand consistency, then let an LLM-driven, tool-calling conversation handle everything after that
• Vendor abstraction: Built telephony and CRM providers as swappable configuration rather than hardcoded integrations, as a hedge against vendor lock-in
• Call-answer discipline: Held the agent back from speaking until the call was confirmed answered, so it never greeted a ringtone or voicemail
• Live data capture: Chose structured "tool calls" during the conversation over parsing the transcript afterward, so the agent could confirm details back to the lead in the moment

Research & Insights

Key Findings from Discovery

• Leads respond best in natural, conversational Hindi/Hinglish — not a scripted or robotic tone
• Sales teams needed structured, filterable data, not inconsistent manual notes
• Consent and do-not-call rules under TRAI/DLT and DPDP aren't optional in Indian outbound calling
• A slow platform with accurate data is as unusable as a fast one with wrong data — call classification had to be precise
• Surfacing raw call outcomes without structure frustrated adoption; every call needed a clean, actionable record

Alternatives Considered

• A single service handling both dial decisions and conversation was considered, but splitting the two made compliance easier to test and let each part scale independently
• Trusting the workflow tool as the sole compliance check was considered, but the gate needed to live in the dispatch service itself as a stronger safeguard
• A fully scripted, hardcoded qualification flow was considered, but it sounded robotic; a hybrid of a fixed greeting plus free-flowing LLM conversation worked better
• Parsing the transcript after the call was considered, but live structured capture during the conversation proved more reliable

User Persona

• Role: Telecalling / sales operations lead at a real estate developer
• Goals: Get every new lead qualified within minutes, free the telecalling team for sales-ready conversations, and stay compliant by default
• Pain Points: Expensive call-volume spikes, slipping response times, inconsistent notes, and compliance risk from manual outbound calling

Information Architecture

• Trigger Service — receives new-lead events, runs the compliance check, and dispatches the voice agent to dial
• Compliance Layer — checks consent, opt-out status, and permitted calling hours before any dial happens
• Voice Agent Worker — owns one call end to end: greets the lead, runs the conversation, records answers, and closes out the outcome
• Conversation Prompts — editable instructions defining the agent's tone, questions, and product knowledge, without needing a code change
• Speech Pipeline — real-time loop of listening, transcribing, reasoning, and speaking back, for the length of the call
• Integrations Layer — handles call recording, CRM webhook delivery, and suppression list storage
• Lead & Session Records — a Lead record tracks who's being called and why; a Session record captures what happened on the call, including the qualification details and final outcome

Visual Language

Since this build has no end-user screen, its "visual language" is architectural rather than graphical — the story is in how requests flow through the system, not how a page looks. A new lead in the CRM triggers the dispatch service, which checks compliance before asking LiveKit to dial the lead over SIP. Once connected, the voice agent takes over — drawing on the speech and reasoning pipeline to hold the conversation — while call recordings, structured results, and webhook updates flow back through the integrations layer to the CRM. Every request passes through the compliance checkpoint first, and every completed call closes the loop by updating the CRM automatically.

Wireframes & Early Ideas

Before implementation, the full lifecycle of one outbound call was mapped end to end, from CRM lead to CRM update, to make sure every hand-off was accounted for. A key early decision was to treat the moment of "call answered" as the real starting gun for the conversation — the agent stays silent through ringing and only greets the lead once a human has actually picked up. The flow was also designed so a completed call always produces a structured result — score, extracted details, and outcome — that's pushed straight back to the CRM, with no manual step in between.

Designing Solutions

Problem: Distinguishing a rejected ring from a genuine call-ended signal

• Certain telephony providers send a rejection-type signal while the phone is still ringing, which looks similar to a real hang-up but isn't
• Early builds treated every such signal as final, occasionally tearing down the session mid-ring and misclassifying answered calls as failures
• We kept the session alive through these transient signals and only finalised the outcome once the call was confirmed connected or genuinely disconnected

Problem: Duplicate or overlapping agent voices on a call

• The dispatch model could, if misconfigured, spin up more than one agent instance on the same call
• We standardised on a single named worker per call, with a guard to skip any request that arrives without a valid lead reference

Problem: Natural conversation vs. reliable structured data capture

• A fully scripted flow captured clean data but sounded robotic; a fully open-ended conversation sounded natural but risked missing required fields
• We built a hybrid model — a fixed, compliant opening line, followed by an LLM-driven conversation instructed to record and verbally confirm each qualification detail as it's heard

Problem: Staying provider-agnostic

• Real estate clients in India commonly work with more than one telephony or CRM vendor, and terms can shift
• Telephony and CRM providers were both built as swappable configuration rather than hardcoded integrations, so the same agent logic works across vendors

Tech & Implementation

• Voice infrastructure: LiveKit Cloud — real-time, low-latency voice AI without building WebRTC plumbing from scratch
• Speech-to-text & text-to-speech: Sarvam AI — best-in-class Hindi/Hinglish speech quality for a natural-sounding conversation
• Conversation reasoning: Google Gemini — handles open-ended dialogue and structured data capture mid-conversation
• Voice activity detection: Silero VAD — lightweight, accurate turn-taking so the agent knows when the lead has finished speaking
• Telephony: Exotel and Plivo — India-native SIP trunking providers, kept interchangeable rather than locked to one vendor
• Dispatch API: FastAPI — a lightweight, async-first framework suited to fast compliance checks and orchestration
• Workflow orchestration: n8n — the client's existing automation tool, extended rather than replaced
• CRM: Zoho and HubSpot — the client's existing systems, integrated at the workflow layer
• Storage: Local storage for the POC, with the architecture already supporting cloud object storage for a production rollout

Design principle: almost every external dependency — telephony, CRM, even the speech vendor — sits behind a thin adapter layer, so swapping one provider for another is a configuration change, not a rewrite.

Real-world Features & Highlights

• Automatic outbound dialing → the agent calls a lead within minutes of CRM entry, no telecaller queue involved
• Natural Hindi/Hinglish conversation → replaces a robotic, scripted IVR experience
• Structured, live data capture → budget, location, BHK, and timeline recorded and confirmed mid-call
• Compliance gate on every dial → consent, suppression, and calling-window checks enforced centrally
• Reliable call-outcome classification → connected, no-answer, voicemail, busy, and technical failure handled as distinct states
• Provider-agnostic design → telephony and CRM vendors are swappable configuration, not hardcoded integrations
• Editable conversation logic → the business team can adjust tone and questions without a code deployment

Results & Impact

Transparency note: this was delivered as a proof of concept. The points below are projected, design-target outcomes, not measured production metrics.

• Projected reduction in speed-to-first-contact from hours of queue-dependent manual dialing to minutes of automatic dispatch
• Guaranteed qualification consistency — every completed call yields the same structured fields, unlike variable manual notes
• Potential to free telecalling teams to focus on qualified, sales-ready conversations rather than first-touch screening
• Automatic coverage within permitted compliance hours, independent of telecaller shift availability
• Consent and suppression checks enforced on every dispatch attempt, before any dial — a built-in compliance guarantee

What we can state with confidence, independent of live metrics: the architecture proves an LLM-driven voice agent can hold a coherent, compliant, Hindi/Hinglish qualification conversation and deliver clean data straight into existing CRM workflows — closing the gap between "lead created" and "lead qualified" without adding headcount.

Challenges & Learnings

• Distinguishing a transient rejection signal from a genuine call-ended event was the hardest reliability problem — and the one with the biggest payoff once solved
• Isolating each call in its own worker process meant one slow or difficult conversation never blocked others running concurrently
• Async infrastructure throughout, plus retry logic on webhooks, meant a brief outage in a downstream system never silently lost a completed call's results
• Building compliance — consent, suppression, calling windows — into the dispatch layer rather than the conversation layer made the whole system easier to reason about and audit
• The hardest problems in voice AI aren't about holding a conversation — they're about correctly classifying rings, rejections, voicemails, and disconnects, which is where production systems actually break

Takeaways

• Compliance-first architecture pays off: building consent and calling-window enforcement into the dispatch layer made the system safer and easier to reason about
• Hybrid scripting beats either extreme: a fixed opening line plus an LLM-driven, tool-calling conversation combined reliable data capture with natural dialogue
• Vendor abstraction is cheap insurance: treating telephony and CRM as swappable configuration kept options open without adding real build complexity
• Edge cases, not the happy path, define voice AI reliability: correctly classifying rings, rejections, and disconnects was the hard part
• A well-scoped POC de-risks the production decision: proving the architecture end-to-end first means the client can move to a pilot with clear, testable success criteria

Next Steps

• A scoped, metered pilot against a live lead segment, tracking speed-to-contact, qualification rate, and telecaller time saved
• Centralised metrics and observability for the agent worker pool
• Autoscaling for the agent workers under peak load
• A managed queue in front of the dispatch service to absorb high-volume campaign bursts
• Finalising call-recording storage, retention, and encryption policy with the client's compliance and legal stakeholders

A Note on This Engagement

This case study documents a proof of concept, not a live production deployment. To protect client confidentiality, the client is referred to generically throughout, and no direct client testimonial is included. All figures in the Results & Impact section are projected estimates based on the POC's design targets, not measured production metrics. The recommended next step is a scoped, metered pilot to convert these projections into verified numbers.

Call to Action

Interested in exploring AI-driven voice automation for your lead pipeline, customer support, or outbound operations? Get in touch with Whiz Cloud to discuss a proof-of-concept scoped to your CRM, compliance requirements, and call volume.