The Rolls Royce in the Garage: Why Expensive Salesforce Implementations Go Unused

Eight months ago I received a call from a client who was desperate. They had invested in Salesforce and other related products but were just not using them. Their words were "we know we have a Rolls Royce in the garage but have no idea how to drive it."

The reality, once I got in there, was worse than that. It wasn't that nobody knew how to drive it. The sales team, the one team the whole implementation had been built around, had quietly stopped trying. And when the team the system was built for isn't using it, everyone above them starts wondering out loud whether the money was well spent. Fair question, honestly.

This happens more than the Salesforce ecosystem likes to admit. A system gets built to spec, goes live, gets its launch email, and within a few months the spreadsheets are back. Nobody made a decision to abandon it. It just quietly lost the war of attrition against people's existing habits.

The software was never the problem

When a Salesforce implementation stalls like this, the instinct is usually to blame the platform, the build, or the users. In my experience it's rarely any of the three on their own. It's a mismatch between what got built and how the business actually works day to day, and nobody caught it before go-live because nobody asked the right questions of the right people at the right time.

So when I take on a turnaround like this, I don't start with the system. I start with an audit.

What the audit actually involves

What's been built versus what's being used. Not the same thing, and the gap between them tells you almost everything. I go through the org itself, objects, automation, page layouts, reports, against what the business genuinely needs to run.

Stakeholder interviews, properly done. Not a survey link. Actual conversations with the people meant to be living in the system every day, asking what actually happened, not what the project documentation says should have happened. This is usually where the real story comes out, and it's rarely the story the project sponsor was told at the time.

A hard look at the existing design. Once you know what people need and what was built, you can see exactly where the design and the day-to-day work parted ways.

Out of that comes a roadmap, one that fixes the thing that's actively costing trust first, then expands out to the rest of the organisation once that trust is back.

What "back on track" looked like, eight months on

For this particular client, that meant:

• Sales — the team that wasn't using the system at all, now fully in it, running their day-to-day through it

• Marketing running live campaigns through the platform

• Distributor management in UAT for functionality built specifically for their process

• Education in workshops, defining what they need next

Same Rolls Royce. Different driver.

If this sounds familiar

If you've got a Salesforce implementation that's technically live but practically ignored, it's rarely a Salesforce problem, and it's very rarely an expensive one to fix. It's usually a case of nobody having stopped to properly audit what was built against how the business actually works, and nobody having asked the people who were supposed to be using it why they weren't.

That's exactly what an Org Health Check is for. If any of this sounds like your organisation, I'd be happy to talk it through.