Your customers can't do the thing they need to do. So you build them a tool that does the hard part.
Two years ago that was a real project. Now it's an afternoon, which is why everyone's done it, and why so many of them landed with a thud.
The tools mostly work. That's what makes the failure confusing.
Two different gaps
When a customer isn't doing what they need to do, it's one of two things, and they look identical from where you're standing.
A capability gap. They'd do it if they knew how. The skill is missing, the domain is unfamiliar, the blank page is intimidating. Hand them something that produces a decent first draft and they're away.
A willingness gap. They could do it. They aren't going to. It's not their priority, it competes with things they care about more, and it stays at the bottom of the list forever.
A tool closes the first one completely and does nothing whatsoever about the second, because a tool produces an output and somebody still has to act on it.
That's the whole thing. Hand a willing-but-unskilled customer a generator and you've solved their problem. Hand the same generator to a customer who was never going to get to it and you've given them one more artifact to not act on. Now it's sitting in a tab, mildly reproachful, next to the thing it was supposed to unstick.
The test, and it takes ten seconds
Imagine handing this customer the finished output. Not the tool. The actual thing, done, correct, free.
Would they use it?
If yes, you have a capability gap and a tool will help. If you hesitated, it was never capability, and no amount of tooling touches it. You've been solving the wrong problem carefully.
Most teams have never asked the question, because building the tool feels like progress and asking feels like pessimism.
Why this got worse rather than better
When tools were expensive, you had to justify one, and justifying it meant someone asked what it was for. That's gone. Anyone can produce something plausible in an afternoon, so nobody has to make the case, so nobody asks.
Which is how you end up with the state a lot of teams are in now: several versions of the same thing, built by different people, drifting apart, the good one known to three people, and every one of them leaving with whoever built it. A tool for everything and a system for nothing.
None of that is caused by the tools being bad. It's caused by cheap tools removing the step where somebody had to say what problem this solves.
What closes a willingness gap
Two things, and neither is a tool.
Do the work. If the customer was never going to act on the output, the output is not the deliverable. The done thing is the deliverable. This is the option that sounds expensive and mostly isn't, once you count what you currently spend chasing work that never happens.
Or make the thing complete the job rather than produce a draft. This is the actual difference between a tool and a workflow, and it's why the agentic framing matters beyond being a word people say. A tool hands back a document. A workflow takes the thing all the way to done, and surfaces a human at the one point where judgement is genuinely required rather than at every point.
The test for whether you've built the second one: after it runs, is there a task left on the customer's list? If there is, you've built a very good tool, and your unwilling customers will not use it either.
The part worth keeping
None of this is an argument against building things for customers. It's an argument for knowing which gap you're aiming at before you spend a quarter on it.
And there's a version that's underrated, which is pointing the same capability at your own team. A new hire who can't yet do the domain work is a real capability gap, and it's the kind a tool genuinely fixes. You stop waiting for somebody to become an expert before they can contribute, which is worth more than most of what gets shipped to customers.
Capability gaps are the ones tools are for. They're just rarer than they look, and the other kind is the one costing you the money.
Lincoln Murphy formally named and popularized Customer Success starting in 2010 and has spent 15 years connecting it to expansion revenue and commercial outcomes. Read The Premise.