What is a CRM? A plain guide for teams that sell
Four object types and the relations between them. What a CRM actually stores, why the shape is what it is, and where the record stops being true.
A CRM is a shared, structured record of every person and company you sell to, and of every interaction you have had with them. That is the whole idea, and everything else — pipelines, automation, forecasting, reporting — is built on top of that one record being complete, shared and current. What is worth understanding underneath the definition is the shape of the record itself: four object types, a small set of relations between them, and three rules those relations have to hold. Get the shape and the rest of the category stops being mysterious.
Four object types, and the relations are the product
Strip any CRM back and there are four kinds of thing.
- Companies or organisations. The businesses you sell to. In business-to-business this matters more than most teams expect, because deals belong to organisations while people move between them.
- People. Individual humans. Name, role, email, phone, and how you came to know them.
- Deals or opportunities. A specific thing you are trying to sell, at a stage, worth an amount, closing on a date.
- Activities. The emails, calls, meetings, messages and notes that make up the history.
A tool that stores the first, second and fourth is a contact manager. A tool that stores all four, with the third able to exist on its own terms, is a CRM — which is why the deals and pipeline surface is the part worth inspecting first in any product being sold to you under the name. Hold that distinction while you are comparing products, because a great deal of software is sold as a CRM on the strength of a pleasant contact list.
The more useful observation is that the objects are the easy part. The relations are where products differ and where behaviour you will find surprising comes from: whether a deal can exist without a contact, what happens to a person when their company record is deleted, whether one person can appear in two workspaces, and whether a deal can be rooted on a company before any human is known.
Why a person is not a row on a company
Every serious CRM separates the human from the employer, and the reason is a delete rule.
Autocloz models it in three tables. A company is scoped to your workspace and unique on the combination of workspace and domain, so two tenants can independently track the same domain without one overwriting the other's enrichment. A person carries a reference to a company with a delete rule that sets it to null — delete the company and the human survives, unattached. And a lead is that person scoped into your workspace, unique per workspace and person, with a delete rule that cascades, because a lead has no meaning without the human it describes.
Read those two delete rules together and they encode a real belief about the world: people outlive companies in your records, and your relationship with a person outlives neither. A product that models a person as a child row of a company gets the first case wrong, and you will meet that case the first time a champion changes jobs — which is, incidentally, one of the highest-value signals a sales team ever receives.
The company domain being optional is a smaller decision with the same flavour. Only an identifier for the human is genuinely required; a spreadsheet import that carries a company name and no website should not be rejected for it.
Two status columns, and what merging them destroys
This one is worth understanding before you configure anything, because merging the two is among the most common self-inflicted CRM injuries.
There are two different questions you can ask about a lead. Where are they in a process? — new, queued, active, paused, replied, bounced, unsubscribed, converted, do-not-contact. And what do you think of them? — hot, warm, cold, or whatever vocabulary your team actually uses.
The first is written by machines. In Autocloz those nine values are enforced by a database check constraint, so nothing can write a tenth, and the sender, the inbound handler and the suppression logic all move a lead between them without a human involved. The second is written by humans and is free-form per workspace.
Merge them into one column and you break both. The machine now overwrites a judgement your rep made — a lead you marked hot becomes bounced and the judgement is gone — and the human now writes values the machine's logic does not recognise, so the automation silently stops matching. Keep them apart, and when a product only offers one, find out which of the two behaviours it has before you decide that is fine.
How a CRM stores history, and why it is not one table
The naive model is a single activity table. Real systems are not built that way, and knowing why explains several things that otherwise look like bugs.
Autocloz builds a lead's timeline by federating six separate sources at read time: operator events, cross-channel touches, chat messages, email threads and their messages, voice calls, and CRM activities. Each of those has a different shape, a different writer and a different retention story, and joining them at read time rather than duplicating them into one log means no writer has to know about the timeline.
Two consequences follow, and both are worth knowing. The timeline is a view, not a table — so it can be complete and still not be exportable as one file, because there is no one file. And a source that fails degrades the timeline rather than breaking it, which is the right trade for a read path a rep looks at forty times a day.
This is also the mechanical answer to why automatic capture matters more than any feature on a comparison table. A history assembled from six writers is complete because none of them required a human to remember. A history assembled from a "log activity" button is complete only to the extent that your least disciplined rep felt like typing, and the gap is invisible — nothing is missing on screen, the record simply describes less than happened.
Custom fields, and the price of the escape hatch
Every CRM eventually offers a way to store something its model did not anticipate: an ARR band, an account tier, a renewal owner, a licence key. In Autocloz that lives as a JSON bag on the lead, the company and the deal, validated at the API layer against per-workspace field definitions rather than by a database schema.
That design is deliberate and it has a cost worth naming. The benefit is that adding a field is a configuration change rather than a migration. The costs are three. Reporting on a custom field is slower and clumsier than reporting on a real column. Type safety is only as good as the validation layer, so a field defined as a number can hold whatever an older integration wrote before the definition existed. And custom fields are the part of a CRM most likely to be absent from an export — which is exactly why the export probe is worth running on day one of a trial rather than at cancellation.
The practical rule is to be sparing. Every custom field is a thing somebody has to fill, a thing that goes stale, and a thing that will not migrate cleanly if you ever move. Add one when a decision genuinely depends on it, not when it would be nice to know.
The five questions that separate a CRM from a contact list
Ask these of anything being sold to you as a CRM, and prefer the answers you can watch rather than the ones you are told.
- Can a deal exist independently of a contact, with its own stage, value and close date, and can it be rooted on a company before any person is known?
- Does email and call history attach itself, or only when someone remembers to log it? This is the highest-leverage question in the whole category and the one most often answered with a technically true yes.
- Can two people see the same record at the same time and both trust it?
- Can you filter on any field, and export everything you put in? Ask which columns the export contains, by name.
- Does it tell you what has gone quiet without you building a report first?
A no to the second question is the most consequential, because manual logging is the reason most CRM deployments end up describing a version of reality that stopped being true weeks ago. How to choose a CRM turns each of these into a probe you can run inside a trial with an observation written down in advance.
What a CRM costs, and what the model does to behaviour
Most CRMs charge per user per month. The model is so standard that it is easy to stop noticing, and it has one specific effect: it makes you ration visibility. The founder who wants to watch the pipeline, the finance lead reconciling forecast to cash, the delivery team who needs to know what is about to land — each is a seat, so each becomes a decision, and the usual outcome is that they do without.
The alternative charges on usage. Autocloz takes that approach: the CRM is free forever for 5 users, 10 mailboxes and 100,000 contacts, and what scales with price is per-channel sending volume, because sending mail and placing calls is the part with a real marginal cost behind it. On the free plan that is 1,000 emails a day and 15,000 a month, alongside a daily allowance on calling, LinkedIn, SMS and WhatsApp; the seat cap lifts from the Growth tier upward.
Neither model is universally right, and the point is not which one to prefer. It is that you should count everyone who should be able to see the pipeline before you compare prices, because that number — not the seat rate — determines the bill and, more importantly, determines who in your company gets to operate on facts. Booking pages, calendar sync and video links are included at no per-seat charge in Autocloz, which is worth checking on any shortlist because scheduling is a common place for a per-user fee to reappear; the booking surface is where that sits.
Autocloz's free plan covers 5 users, 10 mailboxes and 100,000 contacts with the pipeline, custom fields, warmup and DMARC monitoring built in — start free and import a real segment rather than a sample.
Setting one up without over-engineering it
The most common failure of a rollout is not choosing the wrong tool. It is configuring the right tool as though you were a much larger company.
- Start with four stages, not nine. Add a fifth when you can name what specifically happens between two existing ones. Stages are configured per workspace, with a stable internal key and a separate display name — use that split, because renaming a column later should not break every report.
- Define stages by what the buyer did. "Proposal sent" describes your activity. "Proposal reviewed with the decision maker" describes their commitment, and only the second predicts anything. The reasoning is worked through in sales pipeline stages explained.
- Make exactly one field required. Usually the next step. Every required field is a tax on entry, and each one raises the odds a rep skips the record altogether.
- Import clean, not complete. Bring the contacts you will actually work. Everything you migrate you will maintain.
- Automate capture before anything else. If email and calls do not attach themselves, no amount of workflow automation rescues the data quality.
What a CRM does not do, and where the record stops being true
Five limits. The first three apply to the category; the last two are specific to Autocloz and are the kind of thing worth knowing before you build a number on it.
It does not make anyone sell better. It makes history shared, the pipeline visible and follow-up systematic. Those are large, and they are not the same as skill.
It does not clean itself. A CRM reflects what enters it. Duplicate people, stale titles and deals nobody has closed or lost accumulate silently, and no product raises an alert because your data has aged.
It does not preserve what it never recorded. If a decision was made on a call that nobody wrote down, the CRM has no view on it, and the confident-looking timeline will read as though nothing happened.
Stage history is not kept. Autocloz stores a single stage-entered timestamp on each deal and overwrites it at every transition. Current dwell time is available; the path a deal took is not, so "which stage do our deals die in" cannot be answered retrospectively. Start recording it now if you will need it, because it will never exist for the past.
Two reported numbers need reading carefully. Average days to close is computed over won deals only, so it is right-censored — the deals still open, and the ones that died after nine months, are not in the average, and it therefore reads shorter than your true cycle. And the deal record carries an engagement-score column that is documented as a nightly heat number but which nothing currently writes, so it reads zero; do not build a view or a filter on it until it is populated.
Those last two are the sort of thing that separates a record you can operate on from a dashboard you can only believe. If you are deciding whether you have outgrown a shared sheet, CRM versus spreadsheet covers the four failure modes that actually force the switch, and the Autocloz and Salesforce comparison covers the other end of the scale, where the question stops being whether you need a CRM and becomes how much configuration you are willing to own.
Frequently asked
What does CRM stand for?
Customer relationship management. The phrase describes the job rather than the software, and the job predates the software — a filing cabinet of index cards, a rep's notebook, a shared spreadsheet. What software adds is that the record survives the person who made it, updates in more than one place at once, and can be queried rather than only read.
What does a CRM actually store?
Four object types and the relations between them. Companies, the people who work at them, the deals you are trying to close, and the activities that make up the history. Every feature you will ever be sold — pipelines, forecasting, automation, reporting — is an elaboration of one of those four or of a relation between two of them.
What is the difference between a CRM and a contact list?
A contact list stores people and, if you are lucky, notes about them. A CRM additionally stores a deal that can exist independently of any one contact, with its own stage, value and close date, and it attaches history to records automatically rather than when somebody remembers. The second half of that is what separates them in practice, because a manually maintained history describes a version of reality that stopped being true weeks ago.
Do you need a CRM if you only have a few customers?
Not necessarily, and there is no virtue in buying software before the problem exists. The moments that reliably change the answer are two people working the same list, somebody leaving and taking the context with them, being unable to answer how many deals are open without twenty minutes of reconciliation, and follow-ups quietly slipping. None of those is about volume — a five-person team with two hundred contacts can hit all four.
Is a free CRM a real CRM?
It can be, and the question to ask is which cap binds first rather than what the tier is called. Autocloz's free plan carries 5 users, 10 mailboxes and 100,000 contacts with the pipeline, custom fields and booking pages included, so it is a complete records system for a small team rather than a trial — but a sixth user is a paid decision, and that seat count is what pushes a growing team to a paid tier.
How many pipeline stages should you start with?
Four, and add a fifth only when you can name what specifically happens between two existing ones. Define each stage by something the buyer did rather than something you did — proposal reviewed with the decision maker predicts an outcome, proposal sent does not — and give each stage a stable internal key separate from its display name, so renaming a column later does not break every report that referenced it.