The problem is not the software — it is the gap between the software and the work
Walk into most mid-market companies with a CRM and you will find two systems running in parallel. There is the CRM, which contains contacts, some opportunities, and a reporting layer leadership looks at monthly. And there is the real system — a set of spreadsheets, shared documents, and inbox threads where the actual revenue work happens, because the CRM cannot represent it.
That gap is the whole subject. It is not a training problem and it is rarely a discipline problem. People route around systems that make their work harder, and they do it rationally. When a rep maintains a personal pipeline spreadsheet, that spreadsheet is a bug report about the CRM — written in the most honest format available.
What does a packaged CRM actually give you?
A great deal, and it should be said plainly, because the custom-software industry has a habit of understating it. A mature packaged CRM gives you a contact and opportunity data model refined over two decades, a permissions system, an audit trail, a mobile client, an integration marketplace, and a security posture you could not economically reproduce.
- A proven data model for conventional sales motions — leads, accounts, opportunities, activities
- Infrastructure you do not maintain: uptime, backups, security patching, compliance certifications
- An ecosystem of integrations and a labour market that already knows the tool
- Predictable per-seat pricing, which finance can model
For a company selling a conventional product through a conventional motion, this is decisive. Configuring a packaged CRM is the correct answer far more often than a custom-development firm will volunteer. We tell clients this regularly, and it costs us work.
So where does packaged CRM stop being enough?
At the point where your revenue process is a differentiator and the platform cannot express it. Three patterns show up repeatedly:
- Your core object is not an opportunity. Lenders track applications through underwriting stages. Field service companies track jobs against assets and technicians. Membership organisations track renewals and entitlements. Forcing these into an opportunity record works until it does not, and the failure mode is a custom-object sprawl nobody can report on.
- Your process logic lives outside the system. If pricing, eligibility, routing, or approval rules run in someone's head or a spreadsheet because the platform's configuration layer cannot hold them, you have already built a bespoke system — just an undocumented one with no owner and no tests.
- The customisation bill exceeds the build. Some organisations spend years bending a platform into a shape it resists, then pay again at every upgrade. At a certain depth of customisation you have accepted every cost of custom software while keeping every constraint of the package.
How do you decide, honestly?
Do not run this as a feature comparison. Feature matrices are won by whichever vendor writes the matrix. Run it as a process test instead.
Write down your five highest-volume revenue workflows — the ones that happen daily, not the exception cases everyone loves to debate. For each, describe what actually happens today, including the workarounds. Then walk both options through those five, with the people who do the work in the room rather than the people who will approve the budget.
What does a bespoke CRM obligate you to?
Everything the vendor was doing for you. This is the part that goes unsaid in most custom-development pitches, so here it is directly: you take on hosting, security patching, backup and recovery, access control, an upgrade path, and — the one that surprises people — a permanent product owner. A bespoke system without an owner degrades faster than a packaged one, because nobody is shipping improvements underneath you.
The right question is therefore not "can we build it?" — you can — but "will we still be maintaining it well in year three?" Companies that answer yes get a system that fits the business exactly and improves every quarter. Companies that answer no should configure a package and put their engineering effort somewhere it compounds.
The sequence that avoids the expensive mistake
The costliest version of this decision is making it early, from a demo, without evidence. The cheapest version is making it late, from instrumentation.
If you have no CRM: start with the package. Instrument it. Record every workaround your team invents over the first year — those workarounds are free requirements gathering, and more honest than any workshop.
If you have a CRM and it is not working: resist replatforming as the reflex. Most CRM failures are governance failures — undefined metrics, unowned data, unenforced process — and they migrate cleanly into whatever you buy next. Diagnose before you procure. If the diagnosis genuinely shows a structural fit problem rather than a discipline problem, then build, and build against the evidence you have collected.