Why Salesforce Implementations Fail After Go-Live, Not During It

There’s a moment in almost every Salesforce project I’ve worked on where everyone relaxes a little too early. Go-live happens, the dashboards look clean, leadership sends the “great job, team” email, and the project is quietly filed under “done.” I’ve learned to distrust that moment. In my experience, the real test of a Salesforce implementation doesn’t happen in the war room during UAT. It happens about ten to twelve weeks later, when the training decks are forgotten and people are back to doing their actual jobs under actual deadlines.

That’s when you find out whether you built a CRM or just a very expensive database that sales reps quietly stopped opening.

I’ve been doing business analysis and Salesforce implementation work for over fifteen years now, across sales, service, and marketing rollouts, and if there’s one pattern I keep running into, it’s this: organizations plan obsessively for the build and barely at all for the six months after. They treat go-live as the finish line when it’s really the starting gun. I want to walk through why that happens, what it actually costs a business, and what I’ve found works to close that gap — not in theory, but from sitting in enough post-mortems to know where the cracks usually are.

The build isn’t the hard part anymore

This might sound strange coming from someone whose job title has “implementation” in it, but the technical build has gotten easier. Salesforce’s declarative tools — Flow, Screen Flows, dynamic forms, the improved CPQ configuration options — mean a competent admin can now do things that used to require a developer and three sprints. Data migration tooling is better. Integration patterns are more standardized. None of that is where projects die anymore.

Where they die is in the space between “the system works” and “people use the system the way it was designed to be used.” Those are not the same statement, and I think a lot of consultants — myself included, earlier in my career — used to conflate them.

I remember one implementation for a mid-sized distribution company where the Sales Cloud build was, honestly, some of the cleanest work our team had done. Opportunity stages mapped precisely to their actual sales process. Validation rules caught bad data before it entered the pipeline. Approval processes for discounting were automated end to end. Everyone signed off. Four months later, their VP of Sales called wanting to know why forecast accuracy hadn’t improved at all. When we pulled the login and activity data, half the sales team had reverted to updating deals in a shared Excel sheet and having an assistant manually re-key the important ones into Salesforce once a week, if that. The system was fine. The behavior around the system had quietly collapsed.

Requirements gathering catches the wrong things

Part of the problem, and this is something I’ve had to unlearn in my own process, is that traditional requirements gathering is very good at capturing what people say they need and much worse at capturing what they’ll actually resist changing.

When you interview a regional sales manager about their process, they’ll tell you the steps in the order the process is supposed to happen. What they usually won’t volunteer, not because they’re hiding it but because it doesn’t occur to them as relevant, is the workaround they’ve built around a step that’s mildly annoying. Maybe it’s how they track a competitor mention that doesn’t have a clean field to live in. Maybe it’s a private scoring system they use to prioritize follow-ups that has nothing to do with the official lead score. These workarounds are invisible in a requirements workshop and enormously visible six weeks after go-live, when the shiny new fields sit empty because nobody bothered to migrate the workaround into the new system.

This is where I think the business analyst role matters more than the implementation role, honestly. Gathering requirements isn’t just documenting a process. It’s finding the informal process running underneath the official one and deciding, deliberately, whether the new system needs to absorb it, replace it, or actively kill it. Most BAs I’ve seen get trained to do the first job and skip the second one entirely.

Adoption metrics that actually mean something

A lot of organizations measure adoption with login counts, and login counts are close to useless. Someone can log in every morning, glance at their dashboard, and do all their real work somewhere else. I’ve moved toward a small set of metrics that tell you something closer to the truth:

• Field completion rate on required-but-not-mandatory fields — the ones you didn’t hard-lock, because you wanted user buy-in rather than forced compliance. If those fields are empty six weeks in, you’ve lost the argument for why they matter.
• Time-to-first-touch on new leads or cases, measured inside the system rather than reported anecdotally. This tells you whether the system is actually driving behavior or just recording behavior that started elsewhere.
• Manual override frequency on anything you automated — approval routing, lead assignment, case escalation. Overrides aren’t inherently bad, but a rising override rate usually means the automation doesn’t match how the business actually operates, and people are voting with their clicks.

None of these show up on the standard adoption dashboard Salesforce gives you out of the box. You have to build them, and you have to look at them monthly for at least the first two quarters, not just in the thirty-day post-launch check-in that most statements of work budget for.

The training problem nobody wants to admit

I’ll say something that tends to make project sponsors uncomfortable: a single round of training, delivered right before go-live, does almost nothing for long-term adoption. It teaches people how to click buttons in a system they haven’t yet had a reason to care about. The actual learning happens when someone hits a real, high-stakes situation — a big deal they’re trying not to lose track of, a case that’s about to breach an SLA — and either the system helps them handle it or it gets in their way.

What’s worked better for me is deliberately under-training at launch and over-supporting afterward. Teach the core workflow, get people live, and then have someone genuinely available — not a ticketing system, an actual person — for the first month to answer the “wait, how do I…” questions in real time, at the moment they come up. Those questions are worth more than anything covered in a formal training session, because they’re anchored to something the user actually needed to do.

Governance is a business decision, not an IT one

The last piece, and maybe the one that gets neglected most, is who owns the system after the consultants leave. I’ve seen too many implementations where governance was treated as a technical afterthought — someone in IT gets assigned as the “Salesforce admin” almost incidentally, often as one responsibility among many, without the authority to actually enforce data standards or push back when a department wants to bolt on a new custom object that duplicates half of what already exists.

A CRM without a business owner who has both the mandate and the time to defend its structure will drift. Fields get added ad hoc. Naming conventions break down within a year. Reports stop matching each other because two departments quietly built parallel logic. This isn’t a technology failure. It’s an organizational design failure that happens to show up inside a piece of software.

What I’d tell a company starting this process today

If I could change one thing about how most organizations approach a Salesforce implementation, it wouldn’t be the discovery workshops or the sprint planning. It would be insisting, before a single flow gets built, on a clear answer to three questions: who owns this system a year from now, what does real adoption look like in numbers we’ll actually track, and what informal processes are we deliberately choosing to kill versus preserve.

Get those three answers early, and the build tends to take care of itself. Skip them, and you can have the cleanest Sales Cloud configuration I’ve ever reviewed, and still end up with a VP asking why nothing changed.