Case Study
The CRM layer that books, routes and follows up
Groww — W by Groww · Aug 2025 — Present · Full Stack Developer
One in-house CRM layer for the wealth org: meeting scheduling that retired Cal.com, real-time AUM-based lead routing, and Gemini-powered post-meeting processing feeding automated engagement.
100+
client meetings automated per day
50,000+
leads processed through the pipeline
3x
faster lead availability latency
-80%
assignment turnaround time
Overview
Two workflows ran outside our systems: 100+ HNI client meetings a day coordinated on Cal.com across 400+ wealth partners, and leads arriving from two ecosystems waiting on manual handling and CRM defaults before anyone acted on them.
I owned the replacement end to end — scheduling APIs and the Google Calendar/Meet integrations, the ingestion and assignment engine, the AI layer on top, the partner- and ops-facing UIs, the rollout, and the maintenance since.
Problem
Client meetings cannot pause for a migration, and partners had years of habit built into Cal.com links and flows — while every minute between a lead arriving and being assigned was a conversion loss nobody could explain with data.
Constraints
- —Zero downtime: live meetings kept running through the entire switch
- —OAuth tokens across hundreds of partner Google accounts, with refreshes and revocations
- —No lead loss: every event from both ecosystems must land exactly once
- —Routing rules change often and had to stay configurable, not hardcoded
- —AI-generated content touches client-facing workflows, so wrong output is a reputation problem
Approach — what I considered
Big-bang cutover
- + One deadline
- + No dual-system operational cost
- − One bad day burns trust with 400 partners
- − No rollback story
Parallel run with batched migrationChosen
- + Both systems live for weeks; failures contained to batches
- + Logs from the overlap told us exactly what to fix
- − Higher short-term operational cost
Poll the CRM for new leads
- + Simplest to build
- − Latency bounded by poll interval
- − Wasted load on quiet periods
Event-driven ingestion over Redis Pub/SubChosen
- + Assignment reacts in real time
- + Backpressure visible and manageable
- − Needs consumer supervision and replay tooling
Gemini summaries as raw transcript dumps
- + Fastest to ship
- − Unstructured output needed editing anyway
- − No way to measure correctness
Structured action items with a human review loopChosen
- + Output is checkable and editable before it goes downstream
- + Gave us the failure cases that shaped our checks
- − One extra step for ops
What I Built
- —REST APIs for scheduling, availability and partner preferences, with the ops admin and partner-facing UI in React
- —Google Calendar and Meet integration layer: token lifecycle, recurring-event handling, timezone normalisation
- —Idempotent sync jobs behind a retry queue so partial failures heal themselves
- —Ingestion consumers for both ecosystems with exactly-once landing into Frappe CRM, AUM-based assignment with configurable routing
- —Gemini post-meeting processing: summaries and action items into unified client records, behind a human review loop
- —Automated downstream engagement (WhatsApp/NPS) and failure dashboards used during rollout weeks
Results
- —Cal.com fully retired; scheduling data now owned by us, with Meet links generated automatically
- —100+ meetings a day and 50,000+ leads flow through one pipeline
- —Lead availability latency improved 3x; assignment turnaround down 80%
- —Manual documentation effort down 70% with summaries feeding client records
- —Routing and sync decisions are now explainable from pipeline data
Retrospective
- 1.Parallel migration bought trust we could not have bought any other way
- 2.Events made latency visible — you cannot fix what the poll interval hides
- 3.Idempotency is a feature, not a detail — it is what let us sleep during rollout
- 4.AI output needs evals before trust; the review loop was where our checks came from