None of them left over a bug.
I haven't lost many. But the ones I lost all ended identically, and it took me longer than it should have to notice the pattern.
None of them left over a bug. Nobody fired us because a flow broke or a deployment went sideways. What happened, every time, was that they couldn't get their people to use the thing.
The sequence is always the same and it's slower than you'd expect. The system goes live. Adoption is patchy, which nobody panics about at first, because early adoption is always patchy. Six months in, leadership pulls a report and the numbers look wrong. They are wrong. The data underneath is thin, because half the team has been entering the minimum required to close the record and keeping the real information somewhere else. Somebody quotes a data cleanup. The quote is expensive, because cleanup always is. And now you're asking a client to spend real money fixing a system they already don't trust, to produce reports they've stopped believing, so they can keep using something their team is actively avoiding.
Nobody says yes to that. I wouldn't say yes to that.
Different industries, different builds, different sizes. Same ending every time.
I hear the reverse constantly, from people arriving with a bad Salesforce experience already behind them. New client, kickoff call, and someone says some version of we tried this before and it didn't take.
It's nearly always the same two complaints. The system wasn't intuitive. Or they couldn't get to the data they needed without asking somebody for help.
For a long time I assumed the team before me had just been careless. Bad architects, lazy admins, a rushed implementation. I've since built enough of these to know that's usually not what happened. Those consultants were generally competent, and they were handed a specification by people who were never going to use the thing, and they built what they were told.
Which is the actual problem, and it isn't a technical one.
Here's the shape of it. Leadership decides on a process. They have it built without talking to the people who will live inside it eight hours a day. Then they can't work out why nobody adopted it.
The build is usually fine. That's the part that surprises people. The flows fire, the validation rules hold, the reports run. It's a perfectly competent answer to a question nobody on the floor was asking.
And I'll say the uncomfortable part: most consultants and architects I've worked with struggle to push back on this, myself included for longer than I'd like to admit. I understand exactly why. The person specifying the process is the person approving the invoice. Telling them their design won't survive contact with their own staff is not a comfortable conversation, especially early in a relationship, especially when they've already sold the project internally on that design.
So it doesn't get said. The thing gets built. Everyone finds out eighteen months later at a much higher cost.
The job isn't to build what was specified. It's to get the real requirement named out loud, and then build that.
In practice that means persuading whoever's in charge that the people doing the work should have a say in how it gets done. Not a veto. A say. Usually that's as simple as a separate session with the daily users, without their leadership in the room, where people will actually tell you what they think.
Let leadership own the KPIs, and let the users own the process.
The split that works: let leadership own the KPIs, and let the users own the process. Executives get to decide what they need to measure, which is genuinely their call. Then you go to the floor and design a workflow that produces those numbers as a byproduct of people doing their jobs in a way that makes sense to them. Leadership gets a measurable result. The team gets something that doesn't fight them. Nobody has to lose.
That conversation is uncomfortable, and it makes the entire project faster. Every hour spent getting the real requirement named is an hour you don't spend rebuilding in month nine.
I want to be straight about the limits of this.
This is a pattern, not a study. It's consistent across a decade and I'd stake a lot on it, but I can't yet hand you a chart with adoption rates before and after and a return figure at the bottom. That's a fair thing to want and I'm working on collecting it properly.
What I can tell you is that in ten years I have never once seen an implementation fail because the technical work wasn't clever enough. Every single failure I've watched came down to the same thing. Somebody built the right system for the wrong person.