Engineering11 min7/13/2026

How We Built a Hindi/Hinglish Real Estate WhatsApp AI (Case Study)

#Rian Infotech#WhatsApp AI#Hinglish chatbot#real estate AI India#code-mixed NLP#Sarvam AI#WhatsApp Business API#lead qualification#RAG architecture#case study#AI automation India#conversational AI

A behind-the-scenes engineering case study: how Rian Infotech built a Hindi/Hinglish WhatsApp AI for a real estate developer that cut unqualified leads by ~60% and shipped in three weeks. Architecture, tech stack, failures and all.

Rishav Shankar

Rishav Shankar

Share this article

How We Built a Hindi/Hinglish Real Estate WhatsApp AI (Case Study)

The client's sales team was ignoring 70% of their own leads — and they were right to.

That was the uncomfortable finding we walked into. A mid-sized residential developer in North India was spending roughly ₹8–10 lakh a month on Meta and Google lead-gen ads. The leads landed in a spreadsheet. A four-person tele-calling team worked the list top-down. By the time they reached lead #40 on any given day, the lead was six hours cold and had already spoken to two competitors.

The team's coping mechanism was to cherry-pick — call the leads that "looked serious," skip the rest. Nobody could explain what "looked serious" meant. It was vibes. And vibes, it turned out, were throwing away real buyers while burning hours on people who had clicked an ad by accident.

This is the engineering story of what we built to fix that: a WhatsApp AI that talks to every lead within seconds, in whatever mix of Hindi and English they happen to type, qualifies them against real criteria, and books site visits into the sales team's calendar. It shipped in three weeks. Here's how, including the parts that didn't work the first time.

Why This Problem Is Harder Than It Looks

Every founder who hears "WhatsApp chatbot for real estate" assumes it's a solved problem. Pick a BSP, drag some blocks in a flow builder, done. And for a pizza-ordering bot, that's roughly true.

Real estate breaks that assumption in three specific ways.

First, the speed math is brutal. Real estate lead response data consistently shows that response time is the single biggest lever on conversion — leads contacted within minutes convert at multiples of those contacted hours later. Meanwhile WhatsApp business messages see roughly 98% open rates against email's ~22%, with response rates in the 45–60% band versus 6–8% for email. The channel is right there, wildly more effective, and almost nobody is answering on it fast enough.

Second, nobody types in one language. Real buyers write things like "bhai 2bhk ka rate kya hai, loan bhi milega kya?" or "Sector 82 wala project ready possession hai ya under construction?" That's not Hindi. It's not English. It's romanized code-mixed Hinglish, and a decision-tree flow builder with keyword matching falls apart on the first message.

Third, "qualified" is a multi-dimensional thing. Budget, possession timeline, loan pre-approval status, whether they're an end-user or an investor, whether they can even physically reach the site. A flow builder can ask those questions. It cannot handle a lead who answers three of them in a single unstructured sentence and then asks a question back.

Isometric diagram of the layered architecture: messaging channel, language understanding, retrieval database, and CRM sync

The Architecture We Landed On

We deliberately kept this boring. Four layers, each replaceable.

Layer 1 — Channel (WhatsApp Business API)

We went through a BSP rather than wiring Meta's Cloud API directly. The client needed a green tick, template approval handling, and someone to call when message delivery got weird at 11pm. That's worth the per-conversation markup at this scale. If you're weighing this decision yourself, we broke down the economics in Wati vs AiSensy vs Custom WhatsApp AI — the short version is that the BSP is rarely the expensive part; the conversation volume is.

Critical detail people miss: Meta's 24-hour customer service window governs your entire architecture. Outside it, you can only send pre-approved templates. So every re-engagement path — the "you didn't confirm your site visit" nudge, the "still looking?" follow-up — has to be designed as an approved template with variables, not as free-form bot chatter. We drafted and got 11 templates approved before writing a line of bot logic.

Layer 2 — Language Understanding

This is where the interesting work was. Our first attempt used a single frontier model with a long system prompt telling it to "handle Hindi, English, and Hinglish." It worked in demos and got mediocre in production — it would sometimes reply in formal Devanagari Hindi to someone who'd typed romanized Hinglish, which reads as stiff and slightly patronizing to an Indian buyer.

What actually worked was splitting the problem:

  • A cheap, fast classifier on every inbound message to detect script and register — Devanagari, romanized Hindi, English, or code-mixed — and pin the reply style to match the user's own register. Mirror them; don't correct them.

  • Indic-tuned models for the code-mixed path. Models trained explicitly on romanized and code-mixed Indian-language input handle Hinglish far more naturally than general-purpose global models, which tend to treat it as corrupted English. Sarvam's Indic models are the obvious candidates here and have been benchmarked strongly on exactly this code-switching problem.

  • A general frontier model for the English path, where it's simply stronger.

This is model routing applied to language rather than task complexity — the same principle we've written about in our LLM routing guide. It cut per-conversation inference cost meaningfully and, more importantly, made the bot sound like a person from the same city as the buyer.

Layer 3 — Retrieval (RAG over the inventory)

The bot needs to answer "what's the rate for a 3BHK in Tower C" without hallucinating a number. Hallucinating a price in real estate isn't an embarrassing quirk — it's a commercial liability.

So: no pricing from the model's weights, ever. Every factual claim about inventory, pricing, possession date, amenities, or approval status is retrieved from a structured inventory table and injected into context. The model's job is to phrase it, not to know it. If retrieval returns nothing, the bot says it will connect them to a sales manager — it does not improvise.

Layer 4 — Qualification & Handoff

The bot maintains a running structured profile of the lead — budget band, timeline, loan status, end-user vs investor, preferred configuration, locality — filled in opportunistically from whatever the buyer volunteers, in any order, across any number of messages. When enough of the profile is populated and the thresholds clear, it offers site-visit slots pulled live from the sales team's calendar and writes the booking straight into the CRM.

Isometric funnel diagram showing leads filtered through qualification layers into booked site visits

The Qualification Rubric

We refused to build this until the client's sales head sat down and defined "qualified" in writing. This took two workshops and was the highest-leverage part of the project — more than any model choice.

Signal

Hot

Warm

Cold / Disqualify

Budget vs. inventory

Within range

Within 15% of range

>25% below entry price

Possession timeline

0–6 months

6–18 months

"Just exploring"

Loan status

Pre-approved / cash

Applied / eligible

Not started, budget depends on it

Geography

Can visit this week

Can visit this month

Different city, no relocation plan

Intent

Asks about specific units

Asks about the project

Asks only about price, then vanishes

Hot leads get a site-visit slot offered immediately and a human notified in real time. Warm leads go into a nurture sequence built from approved templates. Cold leads get a polite, genuinely useful reply and are parked — not deleted, parked. Some of them come back in six months, and the conversation history is still there.

Three Things That Broke

Case studies that only describe the happy path are marketing, not engineering. Here's what went wrong.

1. The bot was too good at being a bot. Early version answered every question with impressive completeness, and site-visit bookings were flat. Buyers were getting fully satisfied over chat and never feeling the need to visit. We rewrote the prompting so the bot answers well but consistently pivots toward the visit — treating the conversation as a means to an appointment, not an end in itself. Bookings moved immediately.

2. Voice notes. We did not plan for them. A meaningful slice of buyers replied with 20-second Hindi voice notes. The first build silently ignored them, which reads as rudeness. We added speech-to-text on the Indic path within a week of launch. If you are building for the Indian market, plan for voice from day one — it is not an edge case.

3. The 24-hour window ate our follow-ups. Our first nurture design assumed the bot could just message people later. It cannot. Rebuilt around approved templates, with the template variables populated from the lead profile so the follow-up references their actual configuration and budget rather than being generic.

Isometric analytics dashboard illustration showing growth metrics and KPI cards

Results

Numbers below are from the client's own CRM, comparing the two months after launch against the two months before. As with any single-client engagement, treat these as directional rather than universal.

  • ~60% reduction in unqualified leads reaching the tele-calling team. The team went from working a list of 200 mixed-quality leads to working ~80 pre-qualified ones.

  • First-response time fell from hours to under 10 seconds — for every lead, at 2am, on Diwali.

  • Site-visit bookings rose materially, driven less by the AI's cleverness and more by the fact that someone was finally answering everyone.

  • Deployed in 3 weeks from kickoff to live traffic, including the two-week-ish lag on WhatsApp template approvals, which ran in parallel with the build.

  • The tele-calling team was not reduced. They were redeployed onto the qualified leads, which is where humans are actually better than models.

That last point matters more than the percentages. The goal was never headcount reduction. It was to stop asking four people to do a triage job that a machine does better, so they could do the closing job that a machine does worse.

Quick-Win Action Steps

  1. Write down your qualification rubric before you buy any software. If your sales head cannot define "qualified" in a table, no AI can either. This is the whole game.

  2. Instrument your current first-response time. Measure it honestly, including nights and weekends. The number is usually worse than anyone believes, and it's the cheapest thing to fix.

  3. Get WhatsApp templates approved early. Approval latency, not engineering, is the usual critical path. Start it on day one.

  4. Never let the model state a price. Retrieve every factual claim from a structured source. In real estate, a hallucinated number is a legal problem, not a bug.

  5. Mirror the buyer's language register. If they type Hinglish, reply in Hinglish. Formal Devanagari at a romanized-Hinglish buyer feels like being corrected by a schoolteacher.

  6. Design the handoff, not just the bot. The moment a hot lead appears, a human should know within seconds. The AI's job is to create that moment, not to replace it.

Conclusion

The interesting part of this project was never the model. Indic language models are good now and getting better fast; that's a commodity trending toward zero. The hard, valuable work was the unglamorous stuff: forcing a definition of "qualified," designing around Meta's messaging window, refusing to let the model invent prices, and building a handoff that a busy sales team would actually trust.

Most WhatsApp AI projects fail not because the AI is bad but because nobody did that work first. If you're a developer or broker sitting on a lead list you know you're not working properly, the bottleneck is almost certainly not your technology budget. It's the twenty minutes nobody has spent defining what a good lead looks like.

Ready to implement this for your business? Talk to the Rian Infotech team →

Client details are anonymized at the customer's request. Metrics are drawn from the client's CRM over a two-month post-launch window and reflect a single engagement; results vary by market, inventory, and sales-team maturity.

Rishav Shankar
About the Author

Rishav Shankar

Rishav Shankar is a calm-tech architect who blends AI, engineering, and psychology to design systems that think before they act. He builds products that turn complex human problems into intuitive digital experiences, redefining how founders and teams operate. At the intersection of automation, strategy, and imagination, Rishav is creating the future one intelligent workflow at a time.

Comments

Loading...

Leave a Comment

Minimum 10 characters required

0 / 2000