Every Client I Lost, Lost the Same Way (Cut from the Team)
Nobody ever left over a bug.
I haven't lost many. But each time a customer has decided to leave me it feels like I'm back in 2010 watching LeBron decide to take his talents to South Beach. Gutted. It almost makes me lose my love of the Salesforce game the way The Decision killed my love for watching basketball for a while. It's been more than 16 years since then and although LeBron is still capable of breaking my heart by choosing to play somewhere other than Cleveland, I have gotten older and wiser.
What does it usually look like?
When I look back at those customers that I lost through the lens of being older and wiser, I notice that 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.
What do the survivors say?
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. And while those situations exist, I've since built enough of these to know that even a competent consultant can fail if they just build the specification they were handed by people who were never going to use the thing.
Which is the actual problem, and it isn't a technical one.
So where does it actually break?
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.
What could possibly help?
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.
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.
Here's what that looks like in practice. I was on a discovery call once, walking through the details of an accounting integration, and the boss in the room was describing how the process worked. One of the people on the call was quietly disagreeing with every word of it. Not out loud. Her face was doing the talking, and she never once said so in the meeting. So I called her afterward to debrief, and got a different version of the process entirely. It turned out she was the one who would actually be executing the thing to drive the metric her boss was describing. Once that was out in the open, we built something she could actually use, and it drove exactly the outcome her boss was after. But I had to dig it out of her, one on one, without the room listening. It was never going to surface any other way.
Getting the real requirement named is the big one. The rest of the kit is smaller, and it all points the same direction:
- Watch the numbers that don't lie: logins, records created, records edited. Adoption has a pulse and you can take it.
- Put the training inside the system. Nobody goes looking for the instruction manual. If the thing needs more explanation than a quick reference guide behind a “?” button, the thing is too hard.
- Pilot before you roll out. We run product implementations and major feature releases through a pilot period with people who use it to do their actual jobs, and we remove the friction they find before the wider team ever sees it.
- Stay close after go-live. Hypercare is where patchy adoption either gets caught or gets comfortable.
I can't tell you that the conversation is always comfortable, but building the thing people will actually use makes the whole project better. 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.