Do you need a CRM consultant? A decision framework, not a sales pitch.

I'm Lauren Pearson, and this is the question I get asked before almost every engagement I run: do I actually need help with this, or can my team just do it themselves? It is a fair question, and the honest answer is that plenty of businesses genuinely do not need a consultant. This is the framework I use to tell the two apart.

The short answer. Complexity decides it, not headcount.

A CRM consultant earns their fee once a project has more than one moving part to coordinate: more than one department's process to map onto the system, an existing tool, an invoicing platform, a booking engine, a support desk, that needs to talk to the CRM, or a previous implementation that was attempted and did not stick. Below that threshold, a single team setting up an out-of-the-box CRM like HubSpot, Pipedrive or Zoho, with one sales process and nothing else to integrate, is usually well served by the vendor's own onboarding team, which exists specifically for this scenario and typically costs nothing extra.

Company size is a weak proxy for this. I have seen a five-person business with three product lines, two sales channels and an ageing invoicing system need real help, and a twenty-person team running one simple process on one platform manage perfectly well alone. Ask about the process, not the payroll.

How it works in practice. Where the fee actually pays for itself.

What a consultant actually protects against is captured well by G2's 2025 CRM report, which found usability is the top driver of adoption at 68%, and simultaneously the leading reason for abandonment at 42%. Read those two figures together and the risk becomes obvious: the same factor that makes a CRM stick is the one businesses most often get wrong when they configure it themselves under time pressure, without having seen enough implementations to know what "usable, for this specific team" actually looks like in practice. A consultant is not selling magic, they are selling the pattern recognition of having watched that specific mistake happen enough times to design around it before go-live rather than after.

I turn away roughly a third of the enquiries I get for exactly this reason. When a founder calls about a straightforward single-team HubSpot setup with no integrations and one clear sales process, I usually tell them to use HubSpot's own onboarding team and keep the fee. The engagements I take on are the ones with a genuine coordination problem underneath, three departments with different definitions of "qualified," a previous Salesforce rollout nobody uses anymore, a booking system that has to feed deal data into the CRM without manual re-entry. That is where the judgement and the process work genuinely change the outcome, not the software configuration itself, which any half-decent implementer can do.

Budget usually settles the remaining doubt once complexity is clear. A focused setup on an out-of-the-box CRM with a vendor's own onboarding typically costs a few thousand pounds at most, often nothing beyond the licence itself. A multi-department implementation with custom integrations runs well into five figures. If the complexity signals above point to DIY but the fee for a consultant still feels tempting purely for peace of mind, that is usually a sign the real gap is confidence, not capability, and a shorter, cheaper advisory session rather than a full implementation engagement is the better spend.

A worked example. Two founders, two different right answers.

Two founders asked me the same question within a fortnight of each other, and the right answer was different both times. The first ran a six-person consultancy on Pipedrive, one sales process, no other systems to connect, and simply wanted a second opinion before spending money on help. I walked through the framework above with her on a single call, confirmed there was nothing here a consultant would meaningfully improve on, and pointed her to Pipedrive's own setup guides instead. That call cost her nothing and saved a genuine engagement fee she did not need to spend.

The second ran a twelve-person hospitality technology firm already on Salesforce, badly, after a rushed implementation eighteen months earlier had left three regional teams each tracking deals differently, none of them trusting the reports, and a finance system that still required manual re-keying of every closed deal. That was a straightforward yes to a consultant, not because the team was incapable, but because nobody inside the business had the hours or the cross-department authority to fix three conflicting processes and a broken integration at the same time as doing their actual job. The engagement took eleven weeks, most of it spent reconciling what "qualified" meant across the three regions before a single workflow rule was touched.

The distinction between those two calls is the entire framework in miniature: one process, one team, one platform, decide it yourself. Multiple processes, competing definitions, and a broken integration nobody has the standing to fix alone, that is worth paying for.

What good looks like. Signs you made the right call, either way.

If you went the DIY route, the test six months in is simple: is the team still using the CRM without being chased, and has nobody quietly gone back to a spreadsheet for the parts that felt too fiddly to configure properly? Both are fine outcomes if true. If either has quietly slipped, that is useful information, not proof the DIY decision was wrong, it might just mean the specific gap, reporting, a missing integration, needs a short, scoped piece of outside help rather than a full consultant relationship from scratch.

If you hired a consultant, good looks like a project that ends with your team able to run the system without them, not one where every small change still needs a call to the consultant six months later. A consultant who has done their job leaves you with documentation, trained users and a clear sense of who owns what, not a dependency. Ask this directly before signing anything: what does the business look like the day after you leave? A vague answer to that question is worth noticing before the contract, not after.

Pitfalls to avoid. Where this decision goes wrong both ways.

The first pitfall is hiring a consultant for a project simple enough to have handled internally, mostly out of nervousness rather than genuine complexity. This is not free, it delays the team building its own competence with the system, and the fee could have gone towards the sales activity the CRM is meant to support in the first place.

The second, more common pitfall is the opposite: attempting a genuinely complex, multi-department implementation internally because the headline cost of a consultant looks avoidable. This usually costs more in the end, not less, once you count the months spent half-configured, the trust a team loses in a system that never quite worked, and the eventual cost of bringing in outside help anyway to fix what DIY left behind, now with a team that has already decided the CRM does not work for them.

The third is hiring the wrong kind of help for the stage you are actually at. A consultant brought in to choose a platform needs to be broadly platform-agnostic, since one who only implements a single system has an obvious incentive to recommend it. A consultant brought in to implement a platform you have already chosen benefits from deep, certified expertise in that specific system instead. Confusing the two, hiring a generalist for a complex Salesforce build, or a Salesforce specialist to help you decide whether Salesforce is even the right choice, wastes the exact expertise you are paying for.

The fourth is bringing a consultant in too late, after an internal attempt has already failed and the team has quietly stopped trusting the CRM. That is still fixable, but it is a harder and more expensive job than starting clean, since a consultant now has to repair confidence as well as configuration. If you are already several months into a DIY attempt that is clearly not landing, the honest move is to call it early rather than let a struggling rollout run for another quarter on the hope it improves on its own, rather than waiting for a review meeting that keeps getting pushed back. For where that conversation naturally goes next, our approach to CRM consulting and selection covers both the platform-choice and implementation stages this framework points to.