Why three person companies abandon their CRM

There is a very consistent story in companies of two to five people. Somebody signs up for a CRM. They spend a Saturday importing contacts from a spreadsheet and a phone. For about three weeks it is used properly. Then one deal gets closed over the phone and never logged, then a fortnight goes by, and now the CRM disagrees with reality. Nobody trusts it, so nobody updates it, so it gets further out of date. Eight months later somebody cancels the subscription and everyone quietly goes back to the shared inbox and a spreadsheet with colour coding.

The usual explanation is that the software was too complicated. That is part of it, but it is not the mechanism. The mechanism is arithmetic.

The ratio that decides everything

A CRM is only worth reading if it is true, and it is only true if somebody keeps it true. So the question for any team is whether the effort of keeping it current is smaller than the value of the answers it gives back.

At thirty salespeople the answer is obviously yes. The manager cannot hold thirty pipelines in their head, handovers happen weekly, people leave, and the CRM is the only place the shared picture can exist. The cost of updating it is spread across thirty people and the value is concentrated in one who needs the summary.

At three people, both halves of the ratio move the wrong way. The value is much lower, because all three of them already know what is going on. They had a conversation about it this morning. And the cost is much higher per person, because the same person who just spent an hour on the phone is also the person who has to type up what happened, and they have delivery work waiting.

Any feature that adds typing without adding an answer somebody actually wanted pushes that ratio further in the wrong direction. Most CRM features do exactly that.

What it should do

Five things, and they are unglamorous.

Remember every interaction with the least possible typing. The record of what happened should mostly be a by-product of doing the work rather than a separate act of documentation.

Answer "who is this and what happened last time" in one screen. This is the single question a small firm actually asks, usually thirty seconds before a call. Contact, organisation, timeline, files, all in one place, no clicking through four tabs.

Tell you what you have forgotten. A task list against records, and appointments that warn you when you have double-booked. Not a workflow engine. A list.

Say which enquiries turn into work. Not attribution modelling, just: where did this come from, and what happened to it. Three sources and a count beats a funnel diagram nobody configured correctly.

Let you leave. Export everything, in a format that opens.

What it should refuse to do

The features that kill small-team CRMs are the ones that look impressive in a comparison table and require a person to maintain them.

Common feature	Why it fails at three people
Custom fields and objects	Somebody has to design a data model, and they will do it once, badly, in a hurry
Workflow and automation builders	The rules go stale faster than anyone updates them, then they misfire and lose trust
Lead scoring	There is not enough volume for a score to mean anything
Multi-stage forecasting	Three people forecasting nine deals are guessing, and the weighted number reads as false precision
Email sequences	This is marketing software wearing a CRM badge, and it is where the deliverability problems start
Required fields	The fastest way to teach people to type nonsense into a form

None of those are bad ideas at scale. All of them are a tax on a company that has not reached the scale.

The two things people call enterprise that small firms need most

Consent and communication preferences, because a company of three is under exactly the same data protection obligations as a company of three hundred, and the small one has no compliance officer to catch it. Recording that somebody asked not to be emailed should be part of the contact record, not a separate tool.

And export. Not as a grudging button in a settings page, but as a plain promise. Small companies change software often, and the ones who got trapped once will ask about it before anything else.

Import decides whether the product survives

The first hour is entirely about import. A spreadsheet of 400 contacts assembled over six years contains duplicated organisations, three date formats, a column called "notes 2", and someone's mobile number in a field labelled fax. If the import silently makes a mess of that, the product is dead on day one and nothing later recovers it.

The behaviour that works is a preview you approve. Show the mapping, show what will be created and what will be matched to something existing, then wait for a click before writing anything. It is slower and it is the difference between a product people keep and one they abandon in week two.

The test worth running before you buy anything

Ten minutes, no trial account needed.

1. Open your sent items and find the last twenty messages that were about a customer or a prospect.
2. For each one, write down what a colleague would need to know if you were off sick tomorrow. Usually one line.
3. Now count how many of those twenty lines the software would have captured without you typing anything, and how many need a person to sit down and write them up.

If the honest answer is that fifteen of the twenty need typing, no CRM is going to survive contact with your week, and you should be looking at something narrower: shared inboxes with decent search, or a single well-designed spreadsheet. If the answer is that most of it is calendar entries, emails and documents that already exist somewhere, then software can genuinely help, and you should choose the one that asks for the least.

Where we landed, including the bits we would defend and the bits we cannot

We build Consonas around that shape: contacts and organisations as one family of records with a timeline, leads, pipelines with stages you define, tasks, appointments with clash reporting, import with an approval preview, and export.

The expensive decision we made is that each customer organisation gets its own database rather than a row in a shared one. It wins nothing in a feature comparison. It costs us on every schema change, and it means we cannot answer a product question with one query. We think it is right for software holding other people's client lists, and we accept it is a cost we chose rather than an obvious win.

What we cannot claim: paid tiers are defined but not yet priced, and the pricing page says so rather than publishing a number we would have to walk back. There is no completed independent penetration test, no ISO 27001 certificate and no SOC 2 report. Quotations, web forms, a customer portal and invoicing are on the roadmap, which is a polite way of saying they do not exist. Anyone deciding on the strength of a roadmap should ask where each item actually is.

Further reading: Consonas.