How to build a CRM you'll actually use
Most CRMs fail because they ask for more data than they give back. Here is a five-table model that stays useful, and the fields that earn their place.
Most CRM implementations fail the same way. The tool asks each salesperson for twenty fields per deal and gives back a dashboard the salesperson never looks at. Data entry feels like tax. Within three months the CRM is out of date, and everyone is quietly back in a spreadsheet.
The fix is not discipline. It is designing so that the CRM gives back more than it takes.
The model
Five tables. Resist adding more until these hurt.
1. Companies — the organisations. Name, website, industry, size, owner, region.
2. People — the humans. Name, email, phone, job title, and a relation to Companies.
Keep these separate. People change jobs. If a contact is just fields on a company record, you lose the person when they move — and losing a relationship you spent two years building is the expensive kind of data loss.
3. Deals — the opportunities. Name, value, stage, expected close date, relation to Companies, relation to an owner.
4. Activities — every meaningful touch. Type (call, email, meeting, demo), date, notes, and relations to a person, a company and optionally a deal.
This is the table that makes the whole thing work, and the one people skip.
5. Products or Line items — only if deals have composition worth tracking. If every deal is one number, skip it. If deals are made of things with quantities, you want line items.
Why Activities is the important table
A CRM without activity history is a list of hopes. Deal value and stage tell you what someone believes. Activities tell you what actually happened.
Once activities exist and link to companies, people and deals, you get for free:
- Last contact date — a max rollup on the company. The single most useful field in any CRM. Sort by it ascending and you have your neglected-accounts list, permanently, with no maintenance.
- Touches before close — count of activities on won deals. Tells you what good actually looks like.
- Silent deals — deals with no activity in 21 days but a close date inside 30. This is your weekly review list, and it finds slippage before the forecast does.
- Real history on a person — every conversation, across every company they have worked at.
That last point is why People is its own table. When your champion moves to a new company, their entire history follows them, and you have a warm introduction instead of a cold one.
The fields that earn their place
The discipline is to add a field only when you can name the decision it changes.
On a Deal:
| Field | Type | Earns its place because |
|---|---|---|
| Value | Currency | Everything weighs by it |
| Stage | Single select | Drives the board and the forecast |
| Expected close | Date | Makes the pipeline time-aware |
| Owner | Relation → People/Users | Accountability and filtering |
| Company | Relation → Companies | The spine of the model |
| Next step | Text | The most valuable field in a CRM |
| Last activity | Max rollup | Free, and catches stalls |
| Age in stage | Formula | Finds stuck deals |
Next step deserves a note. One short sentence — "send revised quote by Thursday". It is the only field that makes the CRM useful to the person filling it in, because it answers "what was I doing with this?" on Monday morning. A CRM where every open deal has a next step is a CRM people use.
Do not add, until someone asks twice: probability percentage (people guess), competitor (rarely acted on), lead source sub-category (the parent is enough), and any field whose only consumer is a quarterly report.
Stages, and the one rule
Five to seven stages. Each must be defined by an observable event, not a feeling.
Bad: Qualified → Interested → Very interested → Negotiating.
Good:
- New — created, not yet worked.
- Contacted — we have reached a human.
- Discovery done — we know their problem and their budget.
- Proposal sent — a document exists.
- Verbal agreement — they have said yes, paperwork pending.
- Won / Lost.
The test: two people looking at the same deal should agree on its stage without discussing it. "Proposal sent" is verifiable. "Interested" is not, which is why forecasts built on it are fiction.
Record a lost reason as a single select. Six months of lost reasons is the most useful product research you will ever get for free.
The views that make it usable
Same records, different lenses:
- My pipeline — board grouped by stage, filtered to owner = me. The daily working view.
- This month's forecast — grid filtered to close date in month, sorted by value, with a summed total.
- Neglected — companies sorted by last-activity ascending. Reviewed weekly.
- At risk — deals where close date is within 30 days and last activity is over 21 days ago.
- Won this quarter — for morale and for pattern-finding.
If your tool supports it, put the first four on one dashboard and make it the team's Monday view.
Automations worth having
Three, and no more to start:
- Stage change → stamp the date. Gives you time-in-stage without anyone typing anything, and therefore a real sales-cycle metric.
- Deal marked Won → create the onboarding record. The handoff that otherwise happens in a chat message and gets lost.
- No activity in 14 days on an open deal → notify the owner. Not a report. A nudge, to the person who can act.
Resist automating things that email the customer without a human looking. That is where CRMs start damaging relationships.
The mistakes
Modelling contacts as fields on a company. Loses the person when they move.
One "Notes" field instead of Activities. You get a wall of text with no dates, so no last-contact, no cadence analysis, no history.
Too many required fields. Every required field is a tax on the person least likely to tolerate one. Require three: company, value, next step.
Stages that describe feelings. Unverifiable stages produce unusable forecasts.
Building reports before anyone has used it for a month. You do not know which numbers matter yet.
Start smaller than this
Genuinely: Companies, People, Deals, Activities. Four tables, about twenty fields, an afternoon.
Use it for two weeks. The fields you find yourself wanting are the ones to add. The fields you added because a template had them will still be empty, and you should delete them.
A CRM that models 80% of your process and is current beats one that models 100% and is three months stale. That is the whole trade, and most implementations get it backwards.
Before building, it is worth checking whether you should: the best CRM options for small teams sets out when buying a packaged product beats assembling your own, and when it does not.