How I built a CRM my whole team actually uses

Northwind had tried two proper CRMs before this one. Both were abandoned within a month — not because they were bad, but because nobody kept them up to date.

The pattern was identical both times. Setup was a project in itself — fields, stages, permissions. Adding a deal meant a long intake form nobody wanted to fill in. And within weeks the CRM and reality had quietly diverged. A CRM that disagrees with reality is worse than no CRM: you stop trusting it, then you stop opening it. The problem was never the features. It was friction.

A CRM is only as good as the data in it, and the data only stays good if updating it is effortless. So instead of buying a third tool, I built the smallest possible one in Sheets, designed entirely around removing friction. This is the one that stuck.

How it works

I wrote down two rules and refused to break them: adding a row should take 5 seconds — no 12-field intake form — and updating status should take 1 click — a status dropdown, nothing more. Every decision after that was just a test: does this make adding or updating slower? If yes, it did not get built.

In practice the whole thing works like this:

1. A new lead is one new row — name, company, a status dropdown.
2. Moving a deal forward means picking a new value from the dropdown.
3. A lastTouched timestamp updates whenever a row changes.
4. A single roll-up cell weights open deals to give a rough forecast.
5. The sidebar shows the full history for whichever row is selected.

There is no training. It is a Sheet, and everyone already knows how to use a Sheet. The one piece of actual “software” is that sidebar — a row-detail inspector I built and describe in Build a row-detail inspector sidebar. Click a row, get the full client history: a five-second cost for a ten-minute payoff. It earned its place precisely because it adds value without adding a single field anyone has to type into.

What I left out, and why

Plenty of things did not get built. There is no email tracking — the team uses Gmail; it has a thread. There is no activity timeline — the lastTouched timestamp is enough. Forecasting is just that weight column and one roll-up cell rather than a proper module. Each of those is a real feature in a real CRM, and each of them also adds fields to fill in. Every field is a small reason not to bother, and cheap-and-used beats complete-and-ignored.

The payoff is that the whole team actually keeps it current, because keeping it current is free. The pipeline reflects reality, so the roll-up forecast can be trusted, and it cost a few hours to build and nothing per month to run. It stuck because it looked like a Sheet, not “a CRM” — the team already knew how to use it. The lesson I took away is that adoption is a design constraint, not an afterthought. A tool nobody updates has no features at all, so make the boring path the easy one, and the rest takes care of itself.