Most tool problems aren’t tool problems. That’s the pattern I keep running into with sales leaders, whether the conversation starts with a CRM, a process gap, or an AI report nobody quite knows what to do with. They move to change something at the surface. Yet the behavior underneath it doesn’t. And the leader is left wondering why the fix didn’t take.
I’ve started to think the tool is rarely the real question. The real question is about the system underneath it. By system, I mean all the operational glue holding it together. The people. The process. The signal clarity. And the decisions being made, often without anyone naming them as decisions at all.
Three moments from recent conversations keep coming back to me.
Why doesn’t the CRM upgrade fix adoption?
A leader told me her team just went through a CRM upgrade. New configuration, cleaner layout, better reporting. The reps still weren’t logging activity consistently. Deals were still living in spreadsheets on the side.
She was frustrated, understandably. But what stayed with me wasn’t the adoption problem. It was something she said almost in passing. “I just need them to use it.”
I’ve been sitting with that framing for a while now. Because “use it” and “find it useful” are two different asks. Which one you’re actually asking tends to shape everything downstream: how the system gets built, what expectations get set, how the team experiences the whole thing. The tool was never the question in that conversation. The real question is who the system is designed for.
Why does deal qualification depend on the rep?
A similar pattern shows up around process. When I ask sales leaders how their team decides whether a deal is qualified, I usually hear some version of the same answer. It depends on the rep.
Most say it as if it’s a feature. Sometimes it genuinely is. Experienced people making judgment calls on complex deals is real skill, not a gap.
But there’s a difference between a team that shares a definition of qualified and trusts people to apply judgment inside it, and a team that never made that definition. From the outside, both look like flexibility. Only one of them holds up under pressure.
The place I notice the difference most is in forecasting conversations, when every deal review starts with “walk me through your thinking on this one.” That’s usually a signal worth sitting with.
What do you do with an AI-generated pipeline report?
The third moment involved AI. Though it wasn’t really about AI at all. I watched a sales manager get handed an AI-generated pipeline summary. It was clean and well-organized, with a few deals flagged as gone quiet and some timing patterns surfaced across the quarter.
He looked at it for a long moment. Then he said, “Okay. But what am I supposed to do with this?”
It wasn’t a complaint about the tool. He understood what he was looking at. The real questions were something else. Whose job is it to decide what this means? What changes if he acts on it?
AI didn’t create that gap. It just made it visible faster than a person would have.
Why fix the system before the tool?
In each of these situations, someone tried to solve a system problem at the tool layer. A new CRM. A rule about qualification. A smarter report. And underneath all three, no one touched the actual decision design, who decides what, based on which signal, and why.
That’s the pattern worth naming directly. Before you change the tool, change the system. Not the software. The people, the process, the signal clarity, and the decisions being made around all of it.
A few questions tend to surface the gap faster than any tool evaluation will. Is this reactive or deliberate? What signal are we actually trusting? What decision are we really making, underneath the one we’re talking about?
The tool question is usually the easier one to ask. It’s concrete, it’s actionable, and it hijacks the real question underneath before anyone asks it out loud.
I don’t think that’s a failure of judgment. I think it’s what happens when systems drift quietly enough, for long enough. The tool starts to look like the whole problem.
Before you change the tool, it might be worth asking what you wanted it to do that it never could.
