The CRM is not the problem. The process nobody wrote down is.
Businesses replace a CRM when the real problem is that the process it was configured for was never agreed. The second platform gets configured around the same unexamined assumptions, at greater cost, and the complaints come back inside a year.
Thirty minutes · no predetermined package
A platform complaint is usually a process complaint with a product name on it.
Almost every business that wants to replace its CRM can name what is wrong with it. Very few can produce the process the system was meant to encode, because it was never written down — so the configuration reflects a series of individual guesses made by whoever was in the tool that week.
Replacing the platform carries those guesses across. The migration is real work, the invoice is real, and a year later the same people are keeping the same spreadsheet next to the new system for the same reason.
What this looks like from inside the business.
The same information is typed into two or three systems by different people.
Critical steps run on a spreadsheet one person maintains and nobody else understands.
The CRM was implemented by a vendor and is now used as a contact list.
Stages exist that nothing ever moves out of, and everyone knows which ones.
New hires learn the process by shadowing, because it is not written down anywhere.
Reports have to be assembled by hand before anyone will trust them.
Four mechanisms, and none of them is the software.
The process was never mapped
Configuration decisions get made in a vacuum by whoever is in the tool that week. Six months later the object model reflects a series of individual guesses rather than a design anyone agreed to.
No system of record was chosen
When two systems both hold customers, both are authoritative and neither is. Every downstream report has to reconcile them, which is why reporting takes days and still gets argued about.
The uncovered fifth is where you differ
Platforms cover the common four fifths well. The remainder is usually what makes the business competitive, and it ends up in spreadsheets because nobody built for it.
Nothing was documented
An undocumented system is a single point of failure with a notice period. Businesses discover this at the worst possible moment.
Six questions before changing anything.
One record, and everything else reading from it.
The direction of the arrows is the decision. Which system wins is agreed before anything is configured, because every report downstream inherits that answer.
What we would actually be doing.
Where this has already been built.
The platform this describes, running
Lead routing, partner ingest and attribution in production — the same shape, built for an operation that had outgrown three tools.
See what we've builtWhy customising a CRM is not a warning sign
The argument that off-the-shelf configuration is safer than a build, and the specific cases where it stops being true.
ReadConfiguration first, every time
What we do in the first two weeks, and the point at which we would tell you the platform is genuinely the problem.
How we workWhat teams ask before they start.
Do we need to replace our CRM?
Usually not, and we would rather tell you that than sell you a migration. A large share of CRM complaints are configuration and process complaints attached to a product name. We evaluate what you own before proposing anything you do not, and if the platform genuinely cannot do the job we will show you the specific requirement it fails.
How long does the mapping take?
A week or two of elapsed time for most operations, and a few hours each from the people who do the work. It is deliberately front-loaded: everything after it is cheaper when the process is written down, and the map is yours whether or not we build anything.
How do you avoid building something nobody uses?
By writing the process down with the people who will use it before anything is configured, and by shipping in phases that each get used before the next one starts. If a phase is not being used, that is the signal to stop and find out why rather than to build the next thing on top of it.
Who owns the system afterwards?
You do — the accounts, the data, the code and the documentation. Engagements are structured so that ending one is a decision rather than a risk, which means the documentation is part of the build and not an afterthought.
What if the answer really is a custom build?
Then we say so, and we show you the requirement that led there rather than asserting it. A build is a larger commitment and it should be entered with the specific reason written down, so that in two years somebody can check whether the reason still holds.
Describe what your team works around.
The workaround names the constraint. Tell us what sits in the spreadsheet and we will tell you what we would look at first — and whether it is even a job for us.