Hire someone who diagnoses before they build, names deliverables you can inspect, and stays long enough for the team to adopt the work. Nearly every engagement that disappoints fails one of those three tests, and you can check all three before you sign anything.
Most founders buy this once, under time pressure, after something visible broke. That is a bad position to evaluate from, so here is what to look at.
First, check you are hiring for the right problem
Two mistakes happen upstream of the hire. The first is buying a tool when the problem is a process, which is how businesses end up on their third CRM with the same complaints. The second is buying process work when the real problem is that not enough people are asking to buy. Settle that question first. A perfectly engineered pipeline with nothing in it is an expensive way to be organized.
Six questions that separate candidates
Ask these on the first call. The answers sort people quickly.
- "What would you need to see before recommending anything?" You want access to the live CRM, conversations with everyone who touches a deal, and one real opportunity traced end to end. If the answer is a walkthrough of their standard template, they are selling a product and calling it a diagnosis.
- "Who does the work?" Name the person who runs the interviews, the person who makes the design decisions, and the person who builds. A low quote often means the person selling it is not the person delivering it.
- "What will exist at the end that I can inspect?" A documented pipeline, tested automations, a written runbook, and a reporting view is a deliverable. "CRM optimization" is a description of activity. You cannot hold activity to a standard.
- "What happens if my team doesn't use it?" The good answer covers training, documentation, a support window, and a usage check some weeks after launch. Adoption is where this work succeeds or quietly fails, and it should appear in the scope rather than in a reassurance.
- "What do you need from me?" Specific hours, specific decisions, named people, and system access, with dates. Anyone who says "very little of your time" is either not doing discovery or is about to reprice when the project overruns.
- "Show me something you built." A redacted runbook, a pipeline design, or a reporting view tells you more than any case study. Logos and testimonials tell you who paid them, not what they made.
Signals worth reading
| Reassuring | Worth questioning |
|---|---|
| Asks about how you deliver the work before asking about your CRM | Opens with a platform recommendation |
| Prices the diagnosis separately from the build | One number for everything, scoped properly after you sign |
| Talks about who owns each step | Talks almost entirely about automation |
| Volunteers what they will not do | Agrees to everything you raise |
| Writes things down during the sales process | Everything stays verbal until the invoice |
| Can describe an engagement that went badly and why | Has only success stories |
Asks about how you deliver the work before asking about your CRM
Opens with a platform recommendation
Prices the diagnosis separately from the build
One number for everything, scoped properly after you sign
Talks about who owns each step
Talks almost entirely about automation
Volunteers what they will not do
Agrees to everything you raise
Writes things down during the sales process
Everything stays verbal until the invoice
Can describe an engagement that went badly and why
Has only success stories
Fit matters more than credentials
Platform certifications tell you someone can configure a tool. They say nothing about whether they can design a process or get people to follow it. Ask instead whether they have worked with businesses your size, in a founder-led motion, with a sale shaped like yours.
That last part matters more than industry knowledge. Someone whose experience is a 40-person inside-sales team will bring instincts built for volume: heavy stage gating, activity quotas, rigid sequences. Applied to a consultative sale with 15 opportunities a quarter, that produces a system your team works around within a month.
How the engagement should be shaped
The sequence that protects you is diagnosis, then build, then optional ongoing support. A fixed-scope diagnosis caps your exposure while you find out whether you want to work with this person, and it leaves you holding a scope you can take elsewhere.
- The build scope should trace back to findings, not to a template. Every deliverable should answer a problem someone confirmed during discovery.
- Ongoing support should have defined monthly capacity, a visible change queue, and terms for ending it. Open-ended monthly work with no deliverable can run a year and leave nothing you can hand to a new hire.
- Payment should track milestones you can see. Tie it to delivered artifacts rather than elapsed weeks.
If you are comparing quotes, the gap between them is almost always scope rather than rate. What this work costs and why covers how to read two proposals against each other.
What you owe them
Engagements overrun more often because the client was unavailable than because the consultant was slow. You owe system access on day one, interview time from the people who actually sell and deliver, decisions inside an agreed window, and a single internal owner who is not always you. Agree those before the first invoice and most of the usual friction disappears.
How to tell it worked
Decide the test before the work starts, then check it at 60 and 90 days after handover.
- Follow-up happens without you chasing it.
- The pipeline number holds up when someone challenges it.
- A new hire can run the process from the documentation rather than from shadowing you.
- The team is still using the system three months after the consultant left.
One last thing worth doing before you talk to anyone: run a short audit yourself. You will interview better, and you will know immediately whether the person across from you is seeing what you already saw.