The Smallest Line in the Contract Decides the Biggest Outcome

There is a particular kind of silence that settles into a Salesforce project around week eight after go-live. It isn't dramatic. Nobody sends an email announcing that things have gone wrong. It shows up in smaller ways first ; a login report that looks thinner than it did in week two, a sales manager who quietly asks their team to "just send me the numbers in the usual spreadsheet for now," a rep who has rebuilt their own pipeline tracker because the platform one takes too long to update between calls. None of it looks like failure. It looks like people being busy.

By week twelve, the pattern has a name, even if nobody says it out loud. The system is live. Nobody's using it properly. And the people who built it have already moved on to the next client.

This is the moment every implementation quietly hopes to avoid, and statistically, most of them don't. Somewhere between half and two-thirds of CRM implementations fail to deliver the value they were built for, and the leading cause, cited again and again across the research, isn't the platform, the integrations, or the data model. It's adoption. Fewer than four in ten organisations ever reach genuinely high usage rates. The rest live somewhere in the gap between "technically live" and "actually working" ; a gap that gets quietly absorbed into next year's budget as if it were unavoidable.

It was avoidable. It was, in fact, written down in advance.

Ask most organisations what went wrong and you'll get a version of the same answer: the users resisted change, the training didn't stick, the team wasn't ready. It's a comfortable explanation, because it locates the problem in people rather than planning, and because it can't really be audited after the fact. Nobody can go back and prove exactly how "ready" a sales team was eight months ago.

But there's a document that can be audited, and it was signed before a single user ever logged in. It's the implementation contract ; the one that carved up the budget into discovery, configuration, integrations, data migration, testing, and, somewhere near the bottom of the list, training and adoption. That document is not vague. It is precise, itemised, and, in the vast majority of implementations, remarkably consistent in its priorities.

Look across enough Salesforce implementation budgets and a pattern emerges with almost boring regularity. Configuration and customisation ; the build itself ; typically consumes somewhere between forty and sixty percent of total project cost. Data migration, integrations, and testing take meaningful slices too. And training, change management, and user adoption ; the work of actually getting several hundred people to abandon old habits and trust a new system under real business pressure ; usually lands somewhere between five and fifteen percent. Often it sits at the low end of that range. Occasionally it's cut further still once the inevitable overruns in configuration and integration eat into contingency.

Sit with that for a moment, because the proportion matters more than any single figure. An organisation will commit hundreds of thousands of pounds, sometimes millions, to building a system correctly ; to elegant object models, clean data architecture, integrations that talk to every other platform in the stack. Then it will allocate a fraction of that spend, sometimes barely enough to run a handful of workshops and a launch webinar, to the part of the project that determines whether any of the rest of it gets used at all.

This is the line that matters most in the whole document, and it's treated as the one with the most room to give. It is, almost by design, the smallest, most compressible line in the contract ; and it is that line, not the object model, that decides whether the other eighty-five or ninety percent of the spend ever gets used.

That's not a training problem. That's an arithmetic problem, and it was solved in the wrong direction before the project ever started.

Here's where the arithmetic gets more interesting, because it isn't only about the size of the training line. It's about how that line gets arrived at in the first place, and it's a different process entirely from everything else in the contract.

Configuration gets scoped. Someone works out how many objects, how many flows, how many integration endpoints, how many hours of build and test that implies, and the number on the page is a reflection of the actual work required. Data migration gets scoped the same way ; volume, complexity, cleansing effort, all converted into hours and cost. Every major line item in an implementation contract is built from the work backwards to the number.

Training and adoption is very often built the other way round. A budget figure gets set ; sometimes a percentage taken as a rule of thumb, sometimes simply what's left over once everything else has been priced ; and the training plan is designed to fit inside it. Nobody runs a proper training needs analysis first to establish what would actually be required to get four hundred people across three departments confidently and correctly using a rebuilt sales process. The number comes first. The plan gets fitted to the number afterwards.

Flip that order for any other line item and the absurdity is obvious. Nobody prices data migration by deciding "we've got fifteen thousand pounds for this" and then working out how much of the organisation's data can be migrated for that money, hoping the important bits made the cut. Yet that is, in practice, how training and adoption gets treated in a great many proposals. Scoped last, funded first around everything else, and expected to deliver an outcome ; genuine behavioural change across an entire workforce ; that has never actually been sized against the budget assigned to it.

Part of why that happens is that Salesforce, on the surface, looks deceptively simple. Clean interface, familiar structure, a few clicks to log an activity or update a stage. It doesn't look like the kind of system that needs serious investment to get people using it properly. It looks like the kind of thing people will just figure out.

That impression is the trap. Behind the simple interface sits a set of processes the organisation has specifically designed ; which fields matter, which sequence of steps counts as "done," what has to be logged and when, and why. Getting those steps right isn't a UI problem. It's a judgement and habit problem, and the consequences of getting them wrong are rarely trivial.

A rep who logs an opportunity incorrectly doesn't just create messy data ; they can miss their own commission, because the number that triggers payment never got recorded the way finance needed it to. A field service technician who logs a job incorrectly the previous week can turn up at a customer site with the wrong parts, the wrong tools, or no idea the job has already been escalated. A marketing consent field left unchecked, or checked incorrectly during a rushed data entry moment, can mean a customer who opted out of email receiving one anyway ; a minor-looking error with genuine compliance consequences. None of these are technology failures. The system did exactly what it was configured to do. They're failures of a person not fully understanding why a particular click, in a particular order, mattered.

The platform being intuitive to look at has nothing to do with whether the underlying process is intuitive to execute correctly, under time pressure, five months after the one training session anybody attended. Simplicity of interface is not the same thing as simplicity of use, and conflating the two is one of the quieter reasons the training line gets treated as less serious than it is.

There's a deeper layer to this, and it isn't about any one implementation or any one partner. It's about how the people who design, build, and architect Salesforce solutions were trained to think about the job in the first place.

Adoption and change management have never carried much weight in the certifications that shape how the ecosystem thinks. The original Salesforce Administrator credential included a change management section, but it sat at a modest ten percent alongside categories like security and process automation ; useful context, not a core competency anyone needed to master to pass. In the most recent restructuring of that exam, change management has effectively disappeared as its own named category altogether, folded away while a new Agentforce section was introduced and weighted at eight percent. The signal, whether intended or not, is unmistakable: understanding how people actually adopt a system has quietly become less examinable than understanding a brand-new AI capability most organisations haven't even rolled out yet.

That matters more than it might first appear. Certifications aren't just credentials ; they're the informal curriculum for an entire industry. They tell administrators, consultants, and architects what's considered core to the job and what's considered peripheral. If adoption barely features in the syllabus, it's not surprising that it barely features in the solution design conversation either. Nobody in that room learned, as part of their professional formation, that a beautifully configured object model with a forty percent unadoption rate is not actually a successful project. Some pick it up anyway, through experience, through working closely with a change or training team, through one rollout that went badly enough to teach the lesson the hard way. Plenty don't, and default instead to the assumption baked into their training: if adoption fails, it must be a technical shortfall, something else to reconfigure, rather than a structural one.

This isn't a criticism of any individual consultant or architect, most of whom are highly capable at exactly what they were trained and examined to do. It's an observation about an entire ecosystem ; platform, certifications, implementation partners, and buying organisations alike ; that has never quite made adoption feel like a first-class problem worth building deep expertise in. It doesn't photograph well in a product keynote. It doesn't fit neatly into an exam blueprint. It doesn't show up in a go-live demo. It only shows up twelve weeks later, in a login report nobody's presenting at the executive review.

It's easy to say "spend more on training" and leave it there, which is exactly why that advice tends to get ignored ; it's vague, it's soft, and it sounds like something a training company would say because they sell training. The more useful question isn't how much more to spend. It's what that spend is actually supposed to buy, and what process should set it, because most organisations that do increase the training line still spend it on the wrong thing: more content, delivered once, in the week before go-live, sized to a budget rather than to an actual need.

A properly funded adoption budget starts the way every other line item does ; with a proper needs analysis, not a percentage pulled from habit. It looks like a structured programme that runs on both sides of go-live, not just before it ; reinforcement sessions at thirty, sixty, and ninety days, when the platform meets real business pressure for the first time and the gap between what was demonstrated in training and what's actually needed becomes obvious. It looks like adoption being measured with the same rigour as a defect count, with someone on the org chart actually accountable for the number, not just hopeful about it. It looks like role-specific enablement rather than one generic session for an entire sales floor, because a field service technician and an account executive are not struggling with the same three clicks, and the consequences of them getting it wrong look nothing alike either. And it looks like capability building that continues past the point the partner's contract ends, because a system doesn't stop needing champions and confident users the day the invoice is paid.

None of this is complicated. None of it requires new technology. It requires the organisation to treat adoption as a deliverable with the same specificity as data migration ; properly scoped, properly resourced, properly owned ; rather than an outcome it quietly hopes will follow from good software and a well-run project.

Before automation comes alignment. Before the next capability gets switched on, the foundation underneath it needs to be able to carry the weight. That's not a slogan. It's the plain, unglamorous truth sitting underneath every one of those budget percentages, and underneath every exam blueprint that quietly decided this wasn't core knowledge after all.

None of this gets solved by simply asking for a bigger training budget. A bigger number without a better process just repeats the same mistake at a higher price point. What actually needs to change is the order of operations ; and it starts before a single proposal gets requested.

The first move is a proper needs analysis, run with the same seriousness as the technical discovery phase. Before anyone prices training, someone needs to establish who's actually using this system, in what roles, under what pressure, doing what today that will need to change. That's not a workshop question answered in an afternoon. It's the same rigour applied to working out how many objects need building or how many records need migrating, just pointed at people and process instead of data and configuration. Skip this step and every number that follows it is a guess dressed up as a budget line.

From there, the rollout itself needs to be planned as its own workstream, not bolted onto the tail end of the technical plan. What does week one look like for a rep who's never seen the new process under real pressure? What happens at day thirty, when the novelty's worn off and the old habits start creeping back? Who's checking in at day ninety, when the system has to survive quarter-end without anyone in the room who built it? A rollout plan that only covers the two weeks either side of go-live was never actually a rollout plan ; it was a launch event with a training slide attached.

And then it needs to be priced for longevity, not for go-live. Go-live is a moment. Adoption is a condition that has to hold for years. A budget built only to get the organisation through launch day is, by definition, a budget that stops caring the moment the thing it was meant to protect starts actually mattering. Price the first ninety days. Price the first year. Price what it costs to onboard the next intake of new hires who'll never have sat in that original training room.

None of that happens without the right person owning it from day one, which is where most organisations quietly under-invest without ever noticing they've done it. Nobody would run a serious implementation without an architect, a project manager, and a business analyst on the team from the very first week ; that's simply assumed, non-negotiable, priced in from the start. Adoption deserves exactly the same standing. A change manager or trainer, brought in at kickoff rather than parachuted in for a fortnight before launch, with real experience and the right tools for the job ; not a generalist asked to "also do the training bit," but a specialist treated with the same seriousness as everyone else at that table. Organisations that get this right aren't spending dramatically more. They're spending on the same five roles from day one instead of four roles and an afterthought.

All of that matters for the next project. It's less useful if you're already twelve months into one that shipped without any of it. Most organisations don't know where their own version of this compression is happening until it has already cost them a year of underused licences and a sales team quietly running its own spreadsheet on the side. It's rarely one dramatic failure. It's usually a scatter of small, quiet signs of operational friction spread across teams and roles, each one easy to explain away on its own. The Salesforce Operational Health Assessment exists for exactly that reason ; a way to see, with some precision, where the productivity leakage in your own organisation is actually happening, before it becomes next year's budget line for a rescue project.

The next time a proposal lands on your desk with a clean, confident breakdown of costs, resist the urge to look at the total first. Look at how the smallest number on the page was actually arrived at ; the one sitting quietly under "training" or "adoption" or "change management," usually a single digit, usually a figure that was decided before anyone worked out what the job actually required. That figure isn't a footnote to the project. In a very real sense, it is the project. It's the number that decides whether everything above it on the page ever gets used the way it was designed to be ; or whether, twelve weeks after go-live, someone quietly starts rebuilding their own spreadsheet, and nobody in the room is quite sure how to say so out loud.