CRM Conversational AI: Building an Intelligent Sales Assistant That Handles 73% of Queries Autonomously

The Problem: CRM Navigation Tax

In a large real estate and automotive CRM environment with hundreds of thousands of leads, multiple active projects, dozens of campaigns, and 30+ sales agents — the most common questions people asked every day were entirely data-driven:

• "Show me all leads from this week for Project X who haven't been contacted yet"
• "How many site visits happened today?"
• "Which agents have follow-up tasks overdue by more than 3 days?"
• "Pull all leads interested in 3BHK under ₹80 lakhs who visited the site in the last 30 days"
• "What is the conversion rate from site visit to booking for last quarter?"
• "Where is the WhatsApp template for the Diwali offer campaign?"

Every one of these required navigating to a specific screen, applying multiple filters, waiting for a report to load, and sometimes exporting to Excel for a calculation. For a question that takes 8 seconds to say out loud, the answer was taking 4–7 minutes.

Across 30 agents asking 10–15 such questions per day, this is approximately 1,500–2,000 minutes of CRM navigation per day that creates no sales value.

Previous company engagement. Client details are anonymised.

What We Built

A conversational AI interface embedded directly into the CRM — a persistent chat panel accessible on every page via keyboard shortcut, accepting natural language questions and returning answers from live CRM data.

Security and Guardrails — Non-Negotiable

This was designed before anything else. A conversational AI with direct database access that lacks structural safety controls is not a product — it is a liability.

Read-only database connection. The AI assistant uses a dedicated read-only SQL database user. It is structurally impossible — not policy-prevented, but architecturally impossible — for it to write, update, or delete data through this interface.

Table and column whitelist. Generated SQL is parsed and validated against a whitelist of permitted tables and columns before execution. Any query referencing system tables, user credentials, or billing data is rejected at the validation layer before reaching the database. The rejection is logged.

Tenant ID appended structurally. Regardless of what the LLM generates, the validation layer appends a tenant_id = :current_tenant predicate to every query before execution. An agent cannot accidentally query data belonging to another tenant through this interface.

SQL injection prevention. Even though the query is LLM-generated (not user-typed SQL), the validation layer checks generated SQL against a safe-list of allowed SQL patterns: no EXEC, no xp_cmdshell, no dynamic SQL construction, no references to tables outside the whitelist.

Row limit enforcement. All queries are wrapped in a TOP 500 / LIMIT 500 clause by the validation layer. The AI cannot execute a query that dumps the entire database.

Audit log. Every interaction — natural language input, generated SQL, execution result, formatted response — is logged with the user ID, session ID, and timestamp. Full traceability for every query ever issued through the interface.

Text-to-SQL: Making It Actually Work

Generic text-to-SQL on a complex CRM schema fails. The LLM needs domain context to generate correct queries — and "domain context" is engineering work, not prompt engineering magic.

Schema description in the system prompt covers every queryable table with:

• Table purpose (one sentence)
• Key columns with data type and description
• Important relationships and join patterns
• Values for enumerated columns (status can be 'new', 'contacted', 'site_visit_scheduled', 'site_visited', 'negotiation', 'booked')

Few-shot examples cover the 20 most common query types in the CRM, including multi-table joins, date range calculations, aggregations, and NULL handling patterns specific to this schema.

Query classification happens before SQL generation: a lightweight classifier routes the question to the Text-to-SQL path (for data questions) or the RAG path (for document questions). This prevents the LLM from attempting to SQL-query for "what does the Diwali offer template say."

Multi-Turn Conversation Support

The interface supports multi-turn conversations, allowing agents to refine and filter progressively:

"Show me leads from this week who haven't been contacted" (AI returns a list of 47 leads)

"Of those, which ones came from Facebook?" (AI understands "those" refers to the previous result and adds the source filter — returns 12)

"Schedule a follow-up task for all of them" (AI: "I can show you the 12 leads here, but creating tasks requires doing that in the lead view directly — here are the leads sorted by engagement score.")

The last exchange is deliberate: the AI gracefully redirects write operations to the UI rather than refusing coldly. Conversation context is maintained using a sliding window of the last 6 exchanges passed as part of the LLM prompt.

The RAG Component

Beyond data queries, agents frequently needed internal documents: WhatsApp campaign templates, project-specific FAQs, pricing policy documents, escalation SOPs, and product spec sheets.

These documents were indexed using LlamaIndex into a pgvector-backed vector store in PostgreSQL. For questions classified as document queries, the system retrieves the top-3 relevant document chunks by cosine similarity and asks the LLM to answer from them directly, with a source citation in the response.

Agents stopped emailing admins to find the Diwali template. They asked the assistant.

Results

Measured over a 90-day post-launch observation period (n = 34 agents):

Metric	Value
Daily CRM queries handled by AI	73%
Average query resolution time	12 seconds
Equivalent manual navigation time	4.7 minutes average
Agent-reported daily time saving	55 minutes (surveyed)
Data security incidents	Zero in 90 days
Top query type (% of volume)	Lead status / filter (38%)

Query breakdown by type:

• Lead status and filter queries: 38%
• Aggregation / reporting queries: 31%
• Document and template lookups: 19%
• Other: 12%

What This Demonstrates

This case study demonstrates three things simultaneously:

1. Agentic AI design with real production guardrails. Not a demo that skips the security conversation, but a system where the guardrails are structural — a read-only database connection, a whitelist-enforced validation layer, a tenant ID appended before every query hits the database. These are not configuration switches; they are architectural constraints.

2. Text-to-SQL in a domain-specific schema. LLM SQL generation works reliably when the schema is thoroughly described in the system prompt and few-shot examples are domain-specific. Generic text-to-SQL fails on real-world CRM schemas without this engineering investment.

3. Hybrid retrieval in a single conversational interface. Combining structured query (Text-to-SQL for data) with unstructured retrieval (RAG for documents) behind a query classifier — so the agent asks one question and gets one answer, regardless of whether the answer lives in the database or a policy document.