Adoption is the deliverable.
Most CRM builds fail on adoption. The system goes live, works exactly as specified, and the team quietly stops using it within a few months. This is where we spend the largest share of an engagement, because it's the part that decides whether any of the rest was worth building.
$4,500 fixed fee. Two weeks. Refunded in full if you say it wasn't worth it, at the readout or afterwards.
This assumes the system already exists. If it doesn't yet, start with how we build it.
Where the effort actually needs to go.
Gartner has put CRM implementation failure at around 50 per cent and Forrester at around 47 per cent. Those numbers count the failures. They don't explain them. What we find in portals is consistent, and the pattern behind it is consistent enough to have a name: the 10-20-70 rule.
The 10-20-70 rule: where a CRM or AI project's outcome actually comes from
Most vendors sell the 10 per cent. A good implementation partner adds the 20. Almost nobody builds for the 70, which is where projects with sound technology still come apart. The proportions are indicative rather than measured. The ranking is the point.
We treat that 70% as the actual scope of the job. The hard part is whether a partner, a rep or a technician changes how they work on a Tuesday morning, and whether that change is still holding six months later. That's a people and process problem, and it needs the same rigour as the technical build: a plan, an owner, and a way to measure whether it's working.
Prosci ADKAR, applied to a CRM rollout.
We don't invent our own change methodology. We use Prosci's ADKAR model, one of the most widely used change management frameworks, alongside an Agile approach so the team sees a working system early instead of a reveal at the end.
Awareness
The team understands why the system is changing before it changes. A plain explanation, well ahead of go-live, of what's changing and why it matters to their job specifically.
Desire
Named stakeholders are bought in. We identify who has to want this to work, partners, team leads, the people others watch before deciding whether to comply, and get them on side while the rollout can still be shaped around them.
Knowledge
Training happens before go-live. Every user can do their actual job in the new system before the old one is switched off, while there is still time to fix what confuses them.
Ability
The system holds up in real workflows. We test it against how the team actually works, mid-call, on a phone, under time pressure, because a system that only works in a calm training room doesn't survive contact with a Tuesday.
Reinforcement
A named owner and scheduled check-ins after go-live. Someone is accountable for whether adoption is holding at 30, 60 and 90 days, and for what happens if it slips. This is the step most builds skip entirely.
Agile delivery cadence
We build in short cycles with visible progress each sprint, rather than going quiet for the length of the build and revealing the finished system at the end. Your team reacts to a working piece of the build early, tells us what's wrong with it while it's still cheap to fix, and gets used to the new system gradually instead of all at once. By the time the full system goes live, nobody in the room is seeing it for the first time.
Why we spend more time on change.
AI speeds up the part of a build that used to eat the schedule: cleaning data, mapping fields, migrating records, wiring integrations. We don't use that time back to finish early. We put it into the part that actually decides whether the system survives: named owners, stakeholder workshops, training, and the reinforcement that happens after go-live, when most partners have already moved on to the next project.
This is a claim about how we run our own engagements, and only that. The technical work AI accelerates for us, the field mapping, the deduplication, the first-pass data cleanse, is real and it's faster than it used to be. What we do with that time is a choice. We could hand back a cheaper, shorter engagement. Instead, the hours move to workshops with the people who'll actually use the system, to writing training that matches how they really work, and to the follow-up conversations three months after go-live that most partners have already stopped having by then.
The result is the same length project, with the technical risk retired earlier and more of the total time spent on the 70% that the 10-20-70 rule says determines the outcome. AI buys us the hours to do the human side of a rollout properly. Once your team trusts the system enough to run on it day to day, that's when AI inside HubSpot starts doing real work: read how AI operates once your team trusts it.
Run the way a consultancy designs a rollout.
Adoption is the part most builds skip and the part that decides whether yours survives. Jack ran change programmes at EY before this, so we design the rollout the way a consultancy designs one: a named owner per practice, partners who see their own pipeline in the first week, and a system that earns its place by doing their prep for them. If the partners don't use it, it didn't work, and that's our problem to solve, not yours.