CRM or marketing automation platform: which do you actually need?
Most companies with under a few thousand contacts need one system, not two, and the one they need is usually the CRM. Modern CRMs send sequences, and modern marketing platforms track deals, so the categories overlap far more than their pricing pages suggest. The decision only becomes genuinely difficult when marketing needs to operate on people who are not yet, and may never be, records a salesperson owns.
What is each system genuinely built for?
A CRM is built around a deal and the people involved in it. Its core assumptions are that every record has an owner, that progress is measured in pipeline stages, and that the important history is a series of interactions a human had. It is strongest at accountability: who is responsible, what happens next, what is the forecast.
A marketing automation platform is built around a person and their behaviour. Its assumptions are that most records will never have an owner, that progress is measured in engagement, and that the important history is a series of things the system observed. It is strongest at operating on large groups of people nobody is individually working.
Both send email, both hold contacts, and both offer reporting, which is what makes the choice confusing. The distinguishing question is whether the records you care about have owners.
Why does the object model cause so much trouble?
Because the two categories model the same human differently. Marketing platforms almost always key identity on the email address, so one person with two addresses is two records and two people sharing a mailbox is one. Traditional CRMs separate a lead, which is an unqualified individual, from a contact, which is a person attached to a company, and converting between them creates a new record with a new identifier.
That mismatch produces the classic problems: a person who exists twice after conversion, activity history that stops at the moment of conversion, and reports where the same human appears in two funnel stages simultaneously. None of this is a bug in either product, it is two reasonable designs meeting.
If you can avoid running both, you avoid the entire class of problem. That is a stronger argument for a single system than any feature comparison, and it is the argument that rarely appears in a vendor evaluation.
| Capability | CRM strength | Automation platform strength | Who should own it |
|---|---|---|---|
| Pipeline and forecasting | Native | Superficial | CRM, always |
| One to one sales email | Native, with tracking | Possible but awkward | CRM |
| Bulk sending and deliverability infrastructure | Limited, often shares the sales sending domain | Native, with dedicated infrastructure | Automation platform once volume is meaningful |
| Behavioural tracking across the website | Basic or bolt-on | Native | Automation platform |
| Consent and preference management | Often a single checkbox | Native, with granular preferences | Whichever is authoritative, and only one |
| Lifecycle stage | Native to the sales stages | Native to the marketing stages | One system writes, the other reads |
When is a CRM alone enough?
When almost everyone you market to is someone a salesperson would want to own, and the volumes are small enough that sequences of a few hundred recipients cover your needs. Most CRMs now include sending, list segmentation and simple sequences that are entirely adequate at that scale.
It is also enough when the sales cycle is short. Nurture exists to keep a relationship warm across months of inactivity; if your buyers decide in two weeks, there is very little to nurture and the effort is better spent on response time and follow-up discipline.
The signal that you have outgrown it is usually deliverability rather than features. When bulk sends start affecting whether individual sales emails arrive, the two workloads need separating, because they need different sending domains and different reputations.
When do you genuinely need a separate platform?
When you are regularly communicating with a large group of people who have no owner and may never have one. Newsletter subscribers, event attendees, downloaders, customers in a low-touch tier. A CRM handles these badly because every part of its design assumes ownership and pipeline.
You also need one when consent and preference management get complicated: multiple subscription types, several regions with different rules, and a preference centre people can use themselves. A single opt-out checkbox stops being sufficient quickly, and building that logic on top of a CRM is more work than licensing a platform that has it.
And when behavioural tracking genuinely drives decisions rather than decorating a record. Tracking page views is only worth the complexity if scoring or routing acts on them, which requires a scoring model somebody validates.
What does running both actually cost?
More than the second licence. The real costs are the integration work, the ongoing field mapping, the deduplication that follows from two identity models, and the confusion of two reporting systems producing different numbers for what is meant to be the same funnel.
It also costs a decision, repeatedly: which system is the source of truth for each field. Teams that never make that decision explicitly discover it later through data corruption, when a nightly sync overwrites a value a person entered that morning.
The saving is real too, when the marketing workload is genuinely large. The question is not whether the platform is capable, it is whether your marketing operates on a population big enough that the CRM's assumptions get in the way.
How do you decide this in an afternoon?
Count the people you communicated with in the last quarter, and split them into those with a named owner in your CRM and those without. If the unowned group is small, one system will do. If it is several times the owned group, that population is a marketing audience and it needs a system designed for it.
Then check your sending volume against your current sending arrangement. If bulk marketing mail leaves from the same domain as individual sales mail, you are already carrying a risk that a separate platform, with a separate subdomain, would remove.
Finally, ask who would operate the second system. If the honest answer is nobody in particular, the platform will be configured once and then age. That answer decides more of these evaluations than any feature matrix and is the one worth asking first.
Common questions
- What is the difference between a CRM and a marketing automation platform?
- A CRM is built around deals and ownership: every record has an owner, progress is measured in pipeline stages, and history is what a human did. A marketing automation platform is built around people and behaviour: most records have no owner, progress is measured in engagement, and history is what the system observed. Both send email and hold contacts, which is why the categories look interchangeable and are not.
- Do you need both a CRM and a marketing automation platform?
- Only when you regularly communicate with a large population that has no owner and may never have one, such as subscribers, event attendees and low-touch customers. If nearly everyone you market to is someone a salesperson would want to own, one system is enough, and running two adds integration work, duplicate records and two reporting systems that disagree.
- Why do contacts get duplicated between a CRM and a marketing platform?
- The two model identity differently. Marketing platforms key on the email address, so one person with two addresses becomes two records. Traditional CRMs distinguish a lead from a contact and create a new record with a new identifier on conversion, which breaks the link the marketing platform was matching on. It is two reasonable designs meeting rather than a defect in either.
- When has a company outgrown its CRM's built-in email?
- Usually when deliverability, rather than features, starts to hurt. Bulk marketing sends and individual sales emails need different sending reputations, and when they share a domain, a poorly received campaign can affect whether a salesperson's message reaches an inbox. Complex consent and preference requirements across multiple regions are the other common trigger.
- Which system should own the lifecycle stage field?
- One of them, exclusively, with the other reading it. When both systems write the same field, a scheduled sync will eventually overwrite a value a person entered by hand, and a customer can re-enter a prospecting sequence as a result. Field-level ownership decided in advance prevents an entire category of data corruption that is very hard to diagnose afterwards.
