PDO CRM - Retention CRM

Goal

A phonics programme with 517 partner schools tracked renewals, upsell pitches and quality visits in monthly spreadsheets, so schools at risk surfaced too late. I designed and built a role-based CRM where a field trainer logs a school visit in about a minute and rates its renewal risk, and the revenue at risk updates for the trainer, the region and head office. It covers retention, a demo-to-conversion sales pipeline, reading-test reports and a visit calendar that marks a plan done when the service is logged, across three portals on one back end: 517 schools, six regions, about Rs 20 crore of business value.

Customer discovery

The users are the programme delivery officers, the trainers who visit partner schools. Sitting with them showed three problems. A school's renewal status lived in a monthly Excel that each trainer filled from memory, so a school slipping away showed up only at renewal time. Nobody could see revenue at risk by region. And a visit planned in one sheet was never reconciled with the service logged in another.

Nobody asked for a CRM. The ask was to log a visit in a minute from the school gate and never type it again.

Competitive analysis

Vendors selling English and phonics programmes into schools compete on content and teacher training at the point of sale. Post-sale service, the quality visits and the renewal follow-up, mostly runs on spreadsheets and chat groups. Generic CRMs model leads and deals, not a trainer's school visit or a renewal-risk rating per school.

A tool built around the visit, with risk rolled up to the region and head office, was the gap.

Product design and UX

Nothing was adopted off the shelf; the product was designed from the trainer's day. One form logs the visit: the school, what was done, the renewal risk, the next step. Risk and revenue at risk roll up live for the trainer, the region and head office.

Three portals share one back end, scoped by role so a trainer sees only their own schools. The calendar marks a planned visit done when the service is logged, so there is one record instead of two.

Product and tech execution

Shipped and in use. One Python server with SQLite behind HTTPS, nothing to license. 517 schools, six regions and 19 accounts load at first run, with the demo-to-conversion pipeline, reading-test reports, the visit calendar and a full audit trail.

Every API call is checked against the user's role and scope, passwords are hashed, accounts lock after failed attempts, backups run nightly, and 69 smoke checks run against a throw-away database before a release.

Product-market validation

An internal tool, so validation is usage rather than revenue: it carries about Rs 20 crore of business value across 517 schools and six regions.

The wider case is large. UDISE+ 2023-24 counts about 3.3 lakh private unaided schools in India. Industry estimates put India's edtech and smart-classroom market near USD 8.9 billion in 2025 (MarketsandMarkets) and the global education CRM market near USD 2.8 billion (MarketIntelo). Every vendor selling a programme into those schools carries the same renewal and service-visit problem.

Overview
RoleProduct Manager
Admin dashboard, all regions
Admin dashboard, all regions
Visit calendar
Visit calendar
School timeline
School timeline
Risk by region
Risk by region