Why the wrong consultant costs more than the software

In 2023 a fifty-person trading company came to me after spending roughly three times their Zoho licence cost on a CRM implementation partner who had configured forty custom modules and zero working processes. Sales still ran on Excel. The consultant had done exactly what was asked, invoiced monthly, and disappeared. Nothing was technically broken, which is precisely why nobody could point to a breach of contract.

The software cost was trivial. The real losses were eighteen months of pipeline data that never got captured, a sales team that now actively distrusted any new system, and the internal champion who quit out of frustration. When people tell me consultants are expensive, I tell them the cheap ones are the most expensive purchase they will ever make. The selection interview is where you prevent all of this, and most SMEs spend less than an hour on it.

Part of the problem is an asymmetry of experience. You buy CRM consulting perhaps once every five or seven years; the person across the table sells it every week and has answered every soft question a hundred times. Generic questions get rehearsed answers. The questions in the rest of this article are designed to be hard to rehearse, because they ask for specifics, trade-offs, and admissions that a script cannot fake convincingly.

Ask about failures before you ask about successes

Every consultant has a slide deck of wins. Amateurs and veterans look identical in a portfolio review. The question that separates them is simple: tell me about an implementation that went badly, and what you changed afterwards. Amateurs deflect, blame the client, or claim it has never happened. Veterans answer immediately, because failure analysis is how they built their method. Listen for specificity: a real failure story names the mistake, the cost, and the corrective habit, in that order, and it never flatters the storyteller.

My own honest answer involves a rollout where I let the managing director skip user interviews to save two weeks. Adoption collapsed within a quarter and we rebuilt the pipeline stages from scratch. I now refuse to quote a project without talking to at least three end users first. A consultant who cannot produce a story like that, with a specific corrective habit attached, has either done very few projects or learned nothing from them. Both should worry you.

The discovery question: how will you learn my business?

Ask the candidate to walk you through their discovery process before any configuration begins. The amateur answer is a requirements workshop, meaning one meeting with management where everyone lists features they think they want. The professional answer involves shadowing actual users, reading real deals from first contact to invoice, and asking why the current spreadsheet has that strange column nobody can explain.

Discovery is where CRM implementation succeeds or fails, because a CRM is a model of your sales process, and management almost always describes an idealised process that the floor does not follow. When I ask a sales rep to show me how they actually log a deal, I routinely find three unofficial steps that no manager mentioned. A consultant who quotes a fixed price without discovery is guessing, and you will pay for the guess in change requests.

Also ask what the discovery phase produces. The answer should be tangible: a process map your team can read and correct, a shared glossary of terms like lead and qualified that everyone signs off on, and a written list of exceptions the system will deliberately not handle in phase one. If discovery produces nothing you can hold, argue with, or reuse after the consultant leaves, it was a sales exercise wearing a lanyard.

Certifications and partner badges: what they actually prove

As a Zoho consultant I will say something my peers dislike: a partner badge proves a company passed exams and sells licences. It does not prove they can map a messy quote-approval workflow across three departments. Certifications filter out complete pretenders, so treat them as a minimum bar, not a differentiator. The differentiator is domain scars: ten implementations in businesses like yours teach things no syllabus covers, like what happens to a workflow when the one person who understood it goes on leave.

Better signals: has the consultant worked in a business like yours, at your size, with your constraints? A brilliant enterprise Salesforce architect can be genuinely wrong for a twelve-person distributor, because enterprise habits assume budgets and staffing you do not have. Ask what the smallest company they have served is, and what they did when that client could not afford the ideal solution. The answer reveals whether they design for the client or for the demo.

Who does the work, and who trains your team?

The person selling you the project is frequently not the person building it. Ask directly: who will configure the system, and can I speak to them before signing? In larger partner firms, senior consultants close the deal and juniors execute from a template. That is not automatically bad, but you deserve to know, and the handoff quality varies wildly. I have inherited projects where the junior executing the build had never spoken to the client and was working from a two-page brief. Ask for the builder's name in the contract.

Then ask about training and handover. Amateurs deliver a user manual PDF and a recorded webinar. Professionals train your internal admin to make routine changes without them, because they know dependency is bad for you even when it is good for their revenue. When a consultant volunteers to make themselves less necessary, that is the strongest trust signal in this entire checklist. When they insist every field change must go through them, you are buying a hostage situation.

Pricing models reveal incentives

Hourly billing rewards slow work. Fixed-price rewards corner-cutting once the estimate is blown. Neither is evil, but you should ask the consultant which model they use and why, then watch how honestly they discuss the trade-off. The ones who pretend their model has no downside are the ones who have not thought about incentives, which means they have not thought about yours.

My preference for SME work is fixed-price phases with an explicit scope document and a small retained hours pool afterwards, because it forces both sides to define done before money moves. Also ask what happens if you want to stop after phase one. A confident CRM implementation partner designs each phase to leave you in a usable state. An amateur designs a long dependency chain where nothing works until everything is paid for.

Finally, a short list of red flags that end my own confidence in a peer instantly: guaranteeing adoption percentages before meeting a single user, quoting a fixed price without seeing your data, discouraging you from calling past clients, and proposing to start configuration in week one. Any one of these is survivable. Two or more, and you are not hiring a consultant; you are financing someone's learning curve.

Key takeaways

  • Ask every candidate to describe a failed project and the specific habit they changed afterwards; deflection is disqualifying.
  • Insist on real discovery: user shadowing and actual deal walkthroughs, not a single requirements workshop with management.
  • Treat partner badges as a minimum bar; the real differentiator is experience with companies of your size and constraints.
  • Prefer phased fixed pricing with defined exit points, and favour consultants who train your team to not need them.

Conclusion

None of these questions require technical knowledge, which is the point: you are evaluating judgment, honesty, and incentives, not syntax. If you are shortlisting a CRM implementation partner and want a second opinion on the proposals in front of you, I do this evaluation for clients regularly at Funai Consulting, and I am happy to tell you if the amateur alarm goes off. Sometimes the best money I save a client is the project I talk them out of.

Enjoyed this article?

Vivek Kumar Singh

Vivek Kumar Singh

Technical Expert · Full Stack Cloud Engineer · Tokyo, Japan