"Nobody Here Will Actually Use It" — The Adoption Objection, Answered

The objection is a compliment, and it is also a no

Somewhere near the end of a good call, after the demo has landed and the buyer has said "yeah, that's the problem" twice, you will hear some version of this:

"Honestly? I like it. I just don't think anybody here will actually use it."

New reps hear that and panic, because it sounds like the whole thing just collapsed. It didn't. Read it again. The buyer is not disputing that the product works. They are not disputing the price, the timeline, the security review, or whether the problem is real. They have accepted all of that. What they are telling you is that they have watched software get bought before and then sit there, and they do not want to be the person who signs for the next one.

That is a compliment about your product and an indictment of their last three purchases. It is also, and this is the part that matters, a no if you handle it badly. The deal doesn't die on this call. It dies quietly in two weeks when they stop returning your emails, because you gave them nothing new to think about and the safest thing an exec can do with a purchase they can't defend is nothing.

So let's talk about what actually moves it.

The two answers that kill the deal

There are two reflexes here and both of them are fatal. I have done both. I still catch myself starting to do the second one.

The first is agreeing with the buyer about their own team. It comes out as sympathy and it lands as an insult. "Yeah, change management is hard, people resist new tools, we see it all the time." You have just told a leader that their organization is the problem. Even when they said it first, they are allowed to say it and you are not. This is the same rule as complaining about your own family. Watch what happens on the call — the tone goes flat and polite, and polite is where deals go to die.

The second is worse because it feels productive. It's the onboarding promise. "We have a dedicated customer success manager, a 30-day onboarding program, in-app guides, a certification track." Every vendor they have ever bought from said that. The three tools currently rotting in their stack came with onboarding. You have just described the exact package that already failed them twice. You are not answering the objection, you are reciting the brochure that preceded the last failure.

Both answers share a flaw. They treat adoption as a motivation problem — people just need to be encouraged, trained, reminded, nudged. Adoption is almost never a motivation problem. It is a design problem. And the fastest way to get a serious buyer to lean back in is to be the first vendor in the room who treats it that way.

The diagnostic question that separates real from soft

Before you respond, find out what you're dealing with. "Nobody will use it" comes in two flavors and they need opposite handling.

Flavor one is a real adoption risk. This buyer has scar tissue. They can name the tool, the year, the champion who left, the invoice they kept paying. They are genuinely afraid.

Flavor two is a soft brush-off. This buyer doesn't want to say "I don't have budget" or "my boss won't approve this" or "I'm not the one who decides," so they reach for the most socially acceptable no available. Adoption is perfect for this because it sounds thoughtful and it isn't about them.

Here is the question that tells you which one you have:

"What was the last tool that didn't stick, and what happened to it?"

That's it. Ask it plainly, then shut up.

A real adoption risk answers in detail. You'll get the name of the product, the person who championed it, how long it took to die, and usually a little heat. "We bought a scheduling system in 2022, the ops director drove it, she left, six months later nobody was logging in and we were still paying for it until I found it in the renewals list." That is a gift. That story contains the entire specification for what your rollout has to survive.

A soft brush-off answers vaguely. "Oh, you know, there've been a few." No names, no dates, no heat. Nothing happened to it because there is no it. When you get that answer, stop selling adoption — you're solving the wrong objection. Go back and find the real one. Something like: "That's fair. Set adoption aside for a second — if I could guarantee your team used it every day, what else would need to be true before you'd move forward?" That question forces the actual blocker to the surface, and it's usually money, authority, or timing.

One question, thirty seconds, and you've saved yourself from spending the rest of the call building a rollout plan for a deal that was never about rollout.

Four responses, ranked by how often they move the call

Assume you asked the diagnostic and you got the scar tissue answer. Now you're in a real conversation. These are the four moves I keep coming back to, roughly in the order of how often they work.

1. Turn it into a design question, out loud, on the call

This is the highest-percentage move and almost nobody makes it. Instead of defending, you agree that adoption is the risk and then start designing against it in front of them.

"You're right to worry about it. Most tools don't fail because they're bad, they fail because they ask someone to do a new thing that doesn't pay them back that day. So let's actually work it out. Who physically touches this — name the roles. How many times a day does that person need to open it. And is that something they're already doing in another window, or is it net new behavior?"

Then build it with them. Not a pitch, a whiteboard.

The three variables that predict whether software survives are the same every time. Who touches it. How often. And whether it sits inside a workflow they already run or asks them to start a new one. A tool that a dispatcher opens eleven times a shift because that's where the job list lives will survive a bad rollout, a champion leaving, and a reorg. A tool that asks a field supervisor to log in once a week to fill out a form nobody reads will die no matter how good the onboarding was.

When you run this live, two things happen. The buyer starts talking about their own operation in specifics, which is where every good deal lives anyway. And you find out fast whether your product is actually in a daily path or bolted to the side of one. If it's bolted to the side, better you learn that now than at renewal.

2. Narrow the first rollout until it can't fail

The adoption objection is almost always an objection to the size of the thing. The buyer is picturing a company-wide launch, an all-hands, a training deck, and forty people who will nod and then never log in. Of course they're scared. That picture has happened to them.

So shrink the picture.

"Let's not roll this out to the whole team. Pick the one crew, one plant, one region where the pain is loudest. Who's the person who complains about this most?"

You want the complainer. Not the enthusiast — the complainer. The enthusiast will use anything new for two weeks. The complainer has a real problem and will tell you the truth about whether you solved it. If the complainer keeps using it after a month without being reminded, you have proof, and proof is the only argument that beats scar tissue.

This also does something quietly useful for you: it changes what the buyer has to defend internally. Signing off on "we're putting one crew on this for six weeks" is a fundamentally different conversation with their boss than "we're rolling out a new platform." The second one requires a case. The first one requires ten minutes.

3. Name the graveyard before they do

If you've done discovery properly you already know what's in their stack and roughly what's dead in it. In manufacturing and construction especially, I've found that the fastest way to earn credibility is to bring up the tool graveyard yourself, without being asked. This is the same instinct that drives the questions in the manufacturing discovery playbook for plant managers and maintenance leaders — you're asking about the last thing that failed before you ask about the next thing they might buy.

On the call it sounds like:

"Before you tell me you like it — what's already installed that people stopped using? I'd rather know now, because if we're the fourth thing on somebody's screen this ends the same way."

Asking that costs you nothing and buys you enormous room. You are now the vendor who is more worried about adoption than the buyer is. Nobody has ever done that to them. And practically, you learn whether your product will be competing for the same real estate as something they already ignore.

4. Pre-agree what happens the day someone skips it

This is the one that separates a real plan from a hope. Ask it directly:

"Walk me through the first Tuesday somebody doesn't use it. A super doesn't log the inspection, or a rep doesn't put the call in. What actually happens? Does anyone notice? Does anyone say anything?"

Most of the time, the honest answer is nothing happens. Nobody notices. And that answer, spoken out loud by the buyer, is the whole adoption problem in one sentence. It is not that people are lazy. It is that skipping is free.

Once that's on the table you can ask the useful follow-up: what would have to be true for skipping to not be free? Sometimes it's that the data feeds a report the boss reads every Monday. Sometimes it's that payroll or billing depends on it, which is the strongest force in enterprise software — people will use anything that stands between them and getting paid. Sometimes there's no natural consequence and someone has to manually check, in which case you should know that going in and name who that person is.

A buyer who has answered this question has stopped evaluating your product and started operating it in their head. That's the transition you're trying to cause.

What good looks like when you put it together

Here's roughly how the sequence runs. Buyer says nobody will use it. You don't flinch, don't agree about their team, don't mention onboarding.

"That's the right thing to be worried about. What was the last tool that didn't stick, and what happened to it?"

They tell the story. You listen, and you ask one follow-up about why it died, not who killed it.

"Okay. So here's what I'd want to do differently. Who touches this every day — just the roles. How many times a shift. And is that inside something they already open, or is it a new tab?"

You map it. Then you narrow it.

"I don't want this going to everybody. Which crew has the loudest version of this problem, and who's the person there who complains about it most?"

Then you close the loop on failure.

"Last thing. First week someone skips it — what happens? Who notices?"

No part of that is a pitch. All of it is operational. And at the end of it the buyer is holding a rollout plan they helped build, which is a much harder thing to walk away from than a proposal you emailed them.

This pattern isn't industry-specific, but the vocabulary changes. In clinical settings the same conversation is about whether the workflow sits inside the EHR or beside it, and who has to click one extra time — which is why the healthcare discovery playbook for CMIO and clinical ops calls spends so much of its runtime on workflow placement rather than features.

Twelve months later, this is a renewal call

Here's why I care about this objection more than almost any other.

If you handle it with the onboarding brochure and the deal closes anyway — and it will sometimes, because a motivated champion can push a purchase through on enthusiasm alone — you have not avoided the conversation. You have scheduled it. It comes back in eleven months, and by then you're not selling, you're defending. Usage is flat. The champion has moved on or gone quiet. Someone in finance has run a report on seats versus logins and the number is ugly.

That call is brutal and it is entirely preventable. The structure for surviving it exists — the renewal script for saving an account after a year of dead adoption is built for exactly that scenario, as is the SaaS save call for a renewal you're six weeks from losing — but the honest truth is that both of them are recovery operations. You are trying to rebuild in three weeks something that should have been designed in the first meeting.

The design questions on a save call are identical to the design questions on the first call. Who touches it. How often. Is it in the workflow. What happens when someone skips. Same four questions. The only difference is that on the renewal call you're asking them with a number on the screen that says nobody logged in since March, and the buyer's face is different.

So ask them early. When a buyer raises the adoption objection in a first or second meeting, they are handing you the renewal conversation twelve months ahead of schedule, for free, with no usage data to argue about. Take it. Build the rollout in that call, write down who the complainer is, write down what happens on the day someone skips, and then — this is the part reps forget — put those notes somewhere your CS team will read them, because that document is the difference between a renewal and a save call.

What I'd do next

If this objection is one you fumble, the fix is not reading more about it. It's saying the words out loud until the diagnostic question comes out of your mouth before your defensive reflex does. That's the whole skill. Anyone can memorize "what was the last tool that didn't stick" — the hard part is asking it calmly two seconds after a buyer has just told you your deal is probably dead, without your voice going up. That's what I'd run reps through in DrillCall, on a live call with a buyer who pushes back, until the pause before the question disappears.

But you can do a version of it tonight with a colleague and a timer. Have them say "nobody here will actually use it" and start you cold. If your first sentence contains the word onboarding, run it again.