What if anyone could just ask the data — and it answered in plain English?
Two internal AI products, one name, one philosophy — make Emversity's data work for the people who need it, no SQL or statistics required. One lets the ops team query the database in English. The other diagnoses why leads convert, clustering thousands of sales calls to find the patterns nobody could see.
Ops teams waited days for analysts to answer simple metrics, and sales leaders had only gut feelings about lead conversion.
I built two internal AI products end to end — a natural-language-to-SQL tool and a call-diagnostics engine using clustering.
Post-Sales Socrates answers questions across 7 approved views instantly, always showing its generated SQL for full auditability.
A natural-language interface over 7 approved database views. The generated SQL is always shown alongside results — auditable, never a black box.
A diagnostic engine over thousands of sales calls — PCA clustering, stratified sampling, and plain-English insights that explain conversion behaviour.
Emversity's post-sales team — managing tutors, attendance, feedback, engagement — sat on a rich database they couldn't touch without an analyst. Every metric meant waiting days for someone to write, run, and format a SQL query. Decisions were being made on stale data.
Socrates never guesses. If the answer isn't in the seven approved views, it says so — out loud.
Post-Sales Socrates sits on top of the 7 active view tables — attendance, centres, tutors, students, feedback, video feedback, schedules — and turns a plain-English question into an executed, audited query.
Thousands of calls per month. Every call had a transcript, scores across intro / pitch / objection handling / follow-up, and a known conversion outcome. Managers had intuitions — "Indiranagar has a fee objection problem" — but no systematic way to look across all of it and find the actual patterns.
Rather than building across every centre at once, I scoped the pilot to Bangalore–Indiranagar — clean dataset, manageable size, known-interesting conversion patterns. The master query joins call_summary ↔ leads, applies quality filters (transcript present, duration > 1 min), and outputs call fields + aggregated 4-cut scores + lead context + a derived converted_flag.
Simple random sampling would hand the LLM a dataset dominated by short, failed calls — and the insight summary would be useless.
So sampling is stratified across four dimensions — outcome, program category, lead-age bucket, and call pattern from the 4-cut scores. Each stratum contributes proportionally, so the sample OpenAI sees is representative of the real distribution, not the most common failure mode.
The system generates SQL dynamically — without a test set of known question → correct-SQL pairs, there's no way to know when a schema change silently breaks query generation. I'd build 50 gold-standard pairs before any user testing.
When the intent layer can't match a question to a valid metric, it asks a clarifying question — but I wasn't logging how often, or which questions triggered it. Every failed query is a training signal for refining the semantic layer, wasted if you don't capture it.
The next step for Pre-Sales is a RAG layer surfacing relevant past calls and playbooks. But RAG is only as good as its documents — without the manually annotated, quality-flagged call sample as the foundation, it retrieves noise.