Why the CRM had to look like a spreadsheet

At Edmissions World, a sales manager imports leads, a telecaller works a queue, a counselor takes the qualified student through documents, reception records walk-ins, and overnight the no-contact names have to come back. None of that is a 'user journey'. It is a floor.

When I sat with them, telecallers were in sheets. Counselors were in WhatsApp. Reception had a notebook. Managers could not answer who owns this lead, or which follow-ups were missed this week, without someone spending an afternoon on it. That is not a feature gap. That is a missing record.

I co-founded Klinn AI to build software for operations that cannot afford theatre. This was the first production system that had to survive a Tuesday in Hyderabad rather than a demo.

Most CRMs sell a pipeline as cards on a board. Cards feel like progress. The floor does not think in cards. They think in rows: name, owner, status, next date, notes. Density matters. A telecaller with a daily cap needs forty names on one screen, not eight pretty tiles.

So the unit of work is the lead, and the lead looks like a row. Owner, team, source, follow-up date, counselor handoff, application progress — one object, so 'where is this student' has one answer. Statuses are a machine, not labels: new, in progress, no-contact, three follow-up stages, qualified, counselor-assigned.

That is why the interface had to stay close to a sheet. Not because we failed to design. Because the people who would live in it already knew how to scan a grid, jump a cell, and argue about a column. Changing the data model without changing the posture would have been cruelty.

Five live roles share that row and see different columns of it. Admin and sales managers import CSV, assign with round-robin, capacity or performance, and hold daily caps. Telecallers call, note, schedule follow-ups, mark DNP, and qualify onto a named counselor. Counselors work documents and application status on the same record. Reception creates walk-ins. Path-level RBAC keeps a leftover student dashboard in the repo and out of production.

The babysitting is automated. A Cloud Function at 00:05 Asia/Kolkata moves yesterday's NoContact leads back into Follow-up 1, so DNP does not silently die. WhatsApp templates cover the messages the floor already sent by hand: documents, fees, visa, confirmation.

I wrote this up as the Edmissions World CRM case study because the interesting part is not Firebase or Next.js 15. It is that the product had to look like the tool it replaced, or the floor would keep the tool it replaced. The CRM is live at crm.edmissionsworld.com.

Application progress still mutates the lead rather than sitting in a first-class collection. Leave is still two stacks. I would have split applications earlier. Retrofitting both later costs more than building them would have.

The lesson I keep: if the work already lives in a grid, do not invent a metaphor. Give them the grid with an owner, a status machine, and a job that runs at midnight. Software for operations is allowed to be dense. It is not allowed to be cute.

The public site that feeds this pipeline is a different job — client SEO landings that turn an enquiry into a row. The CRM is what happens after the row exists.