From spreadsheets to a single source of truth

Novatr teaches AEC professionals through three flagship courses, and sells almost all of them through a floor of BDRs. Before OMS, nobody could get a straight answer about that floor. Asking how it was tracking against target meant somebody assembling the answer by hand. That took hours, and on bad days it took days.

Sending an application form or rolling out an offer touched the CRM and two other teams, so every one of those added delay. And there was no way to see where leads were actually getting stuck.

OMS v1 was meant to fix all of that. It was built by the engineering team on its own, with no product or design input. It handled the handful of scenarios it had been specified for and broke outside them, so every new scenario turned into an engineering ticket. New BDRs needed retraining whenever the floor changed shape, and getting one thing done meant bouncing between HubSpot, OMS and WhatsApp.

Three arguments, running at the same time, and none of them was "the tool is bad."

I made the cost of slowness visible. Not a critique of the interface. How many hours it took to answer a question as basic as how the floor was tracking against target, and what that delay cost in planning that never happened. It was a number leadership already cared about, attached to a cause they hadn't connected it to.

I let the pain come from the users. The Sales Head was the loudest voice on this and by far the most credible one. My job was getting that frustration into the room where budget gets decided, instead of letting it become a design team complaining about a design team problem.

I argued it into the roadmap. I sat in the product roadmap planning sessions, so the rebuild competed openly against other bets and won on merit. Internal tools usually get funded by being slipped through as maintenance, which is also why they usually stay half built.

Where the argument came from

None of that works without evidence, and the evidence is the part I'd defend as mine. Ved and Nikhil ran most of the sessions. What I did was design the enquiry: deciding which levels get asked what, and refusing to let the observation stop at the part of the funnel that's interesting to watch.

The floor had five tiers: BDR, Associate Team Lead, Team Lead, Team Manager, and the Sales Head who saw everything. The obvious brief was five dashboards, and that brief would have killed us.

The brief from the Sales Head, restated in his own words months after launch, was that he wanted to look at this page once and know the health of the floor, where the pipeline actually was, where deals were stuck, and what payment was coming in.

Three more cards answer the parts the flow diagram can't.

Team performance, named per manager

Below the floor-wide numbers, every Team Manager gets a card that answers the same questions about their own team: a heatmap of every deal's health, colour by colour, gray when the card is collapsed and lit up the moment you expand it; a pending-actions count split by Applications, Offers and Payment; a unit sales attainment figure against target; and Booked, Realised and Average Ticket Size for that manager alone, each with its own change badge.

The Applications and Payments lists work the same way: same columns, same filters, different scope. Every altitude also carries the same Overview and Performance toggle. Overview shows the funnel breakdown, Performance swaps in four KPI tiles including Average Ticket Size. One toggle, learned once, meaning the same thing everywhere.

The drill-down is the piece I'd demo live. Clicking a Team Manager filters the Team Leads column to their reports. Clicking a Team Lead filters the BDRs column. Selecting a BDR populates a detail panel with that person's own funnel view, which is the same component again. A Sales Head goes from an org-wide revenue dip to the one person responsible in three clicks, without leaving the page or exporting anything.

Amber · timed out. Green · moving. Red badge · waiting on you. Grey · global status.

Building an offer is the one moment in this product where a mistake is expensive, customer facing and effectively irreversible. Almost every decision in the two-step wizard is a refusal to let an error escape.

Step one is the payment plan. The BDR picks a payment type, upfront, part payment, or EMI through a third party, then picks discounts from a fixed menu: Early Bird, Merit, Super Merit (locked behind Sales Ops approval), or a custom amount capped to that deal's fee. Nothing is typed free-hand. Course Fee minus Total Discount resolves to one number, Net Payable Fee, and the system builds the instalments itself: a fixed downpayment, then the remainder split evenly across the tenure the BDR picked, with the last instalment quietly absorbing whatever rupee the division left over. There is nothing for the BDR to total, because there is no longer a manual total to get wrong.

An earlier version of this screen worked the other way around: the BDR typed each instalment by hand against a live Amount Left counter and couldn't proceed until it hit zero. It shipped, and it worked, but it was still asking a person to check arithmetic a computer should own. Once the discount tiers existed as rules rather than free text, generating the instalments automatically was the smaller change, and the counter came out.

Step two is the letter. Three named templates, an acceptance deadline, and a live preview of the actual email with the scholarship amount rendering through its merge tag as the BDR types. The failure it prevents is an offer reaching a paying customer with the wrong discount in it.

Enrolment, the fourth and final milestone, is a real screen, not just a label at the end of the flow diagram. It stays locked until the first payment clears, then opens to the specifics that actually matter at handover: the applicant's name, who their admission counsellor is, their application and LMS IDs, and their first session date. Small screen, but it's the one that answers "is this actually a student yet", and it didn't exist as its own thing before this rebuild.

On this project the line between product management and design leadership was blurry, and I made most of the product calls myself: sequencing, scope, and the definitions in section 03. That's the honest version of my role, and it's why those decisions are mine to defend rather than ours to share.

On a team of three that was survivable, and probably faster than splitting the roles would have been. At ten people it's the failure mode. Knowing which of those two situations I'm in is most of what I'd do differently at the next scale.

On delegation. I was hands-on early, doing the information architecture, the structure and the first wireframes, and then handed the execution surface to Ved entirely. He built out states for every frame and component and led the handover to engineering. After that point my review was deliberately narrow. I reviewed against the flows and the IA, not against my own taste.

The team also recorded 100% adoption, and cited roughly 30% more revenue in a quarter as indirect impact. I don't put those on a page as results. Adoption of a tool the job requires you to use measures the mandate. Daily actives on a tool people live in tracks headcount and rollout. And I'm not going to claim a design tripled revenue, because the courses, the pricing and the market did that. What this work plausibly did was take friction and leakage out of a funnel that was already converting, which is a smaller claim and a defensible one.

The more useful answer is what I'd instrument if I ran it again, because that's the part I got wrong. We built a measurement product for a sales floor and shipped no measurement of ourselves. Every row below names the decision it tests. If no decision moves a number, the number is decoration.

Sequencing ran on two axes, and I'd keep one of them.

The one I'd keep. Anything that took days by hand got built first. Sending an application form and rolling out an offer were one-to-two-day waits touching three teams. Ordering by turnaround-time pain is clean, it's defensible, and it produced the sub-hour result above.

The one I'd argue with myself about. Dashboards shipped ahead of workflow depth, because leadership's pain was the loudest. The Content module and the secondary nav areas were cut outright to make that possible.

It was right for keeping the project alive. Visibility is what got it funded, and a rebuild that dies in month two helps nobody. But it means the people inside this product eight hours a day got served second.

If I ran it again I'd interleave instead of stacking. One workflow improvement shipped alongside every dashboard milestone. Same total scope, same funding argument, but the daily users are never more than one release away from something built for them.

And if I built it in 2026

The nine-field filter modal becomes a sentence. The deals list is a query and we built a form for it, then shipped a bug where the counts didn't follow. Today I'd put natural language over the same query, something like "every deal where the offer expired and nobody has called since", and let the filter chips be the result of the sentence rather than the way you compose it.

The drill-down gets prototyped in code on day one. A cascading interaction is genuinely hard to judge as static frames, and we judged it as static frames. A working prototype in a day would have surfaced the ATL gap immediately, because you can't click a tier that isn't there. Building this prototype years later is the same instinct. I wanted to click through the direction before writing about it, and where it didn't hold up I'd rather find that out here than after an engineering team had built it.