"We Tried Something Like This and It Didn't Stick" — Selling to a Buyer Who's Already Been Burned

There is one objection I still slow down for. Not price. Not "send me some information." Not even "we're happy with our current vendor."

It's this one:

"We tried something like this a couple of years ago. It didn't stick."

Every other objection in the book is, at some level, a guess about the future. Too expensive is a guess. No budget is a guess. This one is a memory. The buyer isn't speculating about whether your category works. They already ran the experiment, they signed the paper, they told their boss it was going to be great, and then twelve months later they were quietly not renewing and hoping nobody brought it up in the QBR.

They are not wrong. That's the whole problem. Most of the time, when someone tells me a previous rollout died, and I dig in, the story checks out. Somebody sold them a platform, the champion got promoted or laid off, nobody in the field ever logged in, and the thing became a line item that finance eventually killed. That happened. You cannot argue with it and you shouldn't try.

The reflex that kills the deal

The instinct — and I've done this, more than once, early on — is to separate yourself. "I hear you, but we're actually pretty different from those guys." Then you list the differences. Better onboarding. Dedicated CSM. Modern architecture. Whatever your differentiation deck says.

Here is why that fails. Say it out loud and imagine the buyer hearing it. Now imagine what the last rep said in the same chair eighteen months ago. It was the same sentence. Word for word, probably. Better onboarding, dedicated CSM, we're not like the others. The buyer has heard this exact reassurance before, delivered with the same confidence, by someone who turned out to be wrong.

So when you claim to be different, the claim itself is evidence that you're the same. You've matched the pattern. In my experience this is the single most common way a well-qualified deal quietly dies in stage two — the rep handled the objection technically correctly and confirmed the buyer's fear in the process.

The other failure mode is going soft. Nodding a lot, saying "that's really frustrating," and moving on to your agenda. That reads as not listening. Which, to be fair, it is.

There's a third thing you can do, and it's the only one that works.

Get the post-mortem

Stop selling and run the incident review.

When a buyer tells me a prior tool didn't stick, my next move is not a rebuttal. It's a request:

"Can you walk me through what actually happened? Not the sales pitch you got — the rollout. Where did it fall apart?"

Then shut up. Take notes visibly. Let it be uncomfortable.

What happens next is the most valuable ten minutes of the entire sales cycle, for two reasons. First, nobody has asked them this. The last three vendors who called all pivoted to their differentiators the second the word "burned" came out. You're the first person to treat the failure as information rather than as an obstacle. That's an enormous amount of trust for a very cheap price.

Second — and this is the part reps miss — the failure story is your implementation plan. It's free. They are handing you a detailed spec of exactly what your deployment has to survive, written by someone who watched a competitor's deployment not survive it. You could not buy that research.

The questions that get you the real story

The generic "what went wrong" gets you a generic answer: "adoption was low." That's not a cause, that's a symptom. Push into specifics.

"Who owned it internally? Are they still here?"

"How long between signing and the first person actually using it in a real workflow?"

"Was it a technical problem or a people problem?"

"Which team never picked it up? Why that team specifically?"

"Did it integrate with the systems you already had, or was it a second place to type things?"

"When you decided to kill it, what was the actual trigger? Renewal date? Budget cycle? Somebody complained?"

That last one is my favorite. The trigger tells you what the organization's immune system responds to. If the trigger was a field supervisor complaining loudly enough in a Monday meeting, then field supervisors are the real buying committee, whatever the org chart says.

The four ways these things actually die

Across the deals I've worked and the post-mortems I've sat through, the stories collapse into a small number of shapes. Knowing them helps you ask sharper follow-ups.

The rollout died in the middle. Someone bought it, IT was supposed to configure it, IT had four other priorities, and by the time it was live the enthusiasm was gone. Nobody was accountable for the gap between contract and usage. This is the most common one I hear.

The integration was a lie. The tool technically connected to their ERP or EHR or CRM, but the sync was one-way, or ran nightly, or dropped fields, so people ended up entering data twice. The moment a tool becomes a second place to type things, it's dead. It just takes a couple of quarters for the body to stop moving.

The field never used it. Headquarters loved it. The people doing the work found it slower than what they were doing before, so they kept doing what they were doing before, and then reported usage numbers that were technically true and completely meaningless.

The sponsor left and nobody inherited it. No one could articulate what value it was producing, because nobody had ever defined what value would look like. When budgets tightened, it was the easiest thing on the list to cut, because cutting it produced no visible pain.

When you can name the shape back to them — "so it sounds like this was less a product problem and more that nobody owned the last mile between IT configuring it and the crews using it" — you've done something the last vendor never did. You've understood their organization.

Their failure story is your implementation plan

Now you build.

Every specific thing they told you becomes a specific commitment in your proposal. Not a value, not a philosophy — a commitment with a name and a date attached.

If the last rollout took five months to go live, your plan says which day in week two the first real user touches the system. If nobody owned the last mile, your plan names the person on your side who owns it and the person on theirs who has to sign off, and you get that second name from them out loud, on the call. If the integration was one-way, you go find out today whether yours is, and if it is, you say so before they find out.

This is the moment the conversation changes character. You're no longer a vendor asking for a decision. You're two people designing a rollout that doesn't repeat a known failure. I've had deals where I never gave the standard pitch at all — we spent the whole cycle on the deployment plan, and the product conversation happened in the margins.

Name the owners

A first-90-days plan without names is a brochure. Write it with names.

Week one: kickoff, our implementation lead is [person], your operational owner is [person], your technical contact is [person]. Week two: integration mapped and tested against real records, not sample data. Week three: ten named users, from the group that ignored the last tool, running one real workflow end to end. Week six: those ten people either use it daily without being reminded, or we stop and figure out why. Week twelve: the go/no-go.

The specificity is the message. Anyone can promise partnership. Very few reps will write down a date in week six and let themselves be measured against it.

Give them a kill criterion

This is the part most reps won't do, and it's the part that closes burned buyers.

Write down, in advance and in writing, the condition under which this is a failure and they should stop. Something like: if by day sixty fewer than seven of the ten pilot users are logging a real job through the system in a normal week, we agree the deployment isn't working and we address it or we end it.

Every instinct in your body says don't hand the customer a loaded weapon. Two things about that. One, they already have the weapon. It's called not renewing, and last time they used it. All you're doing is agreeing on when it fires. Two, and more important, offering a kill criterion is the only claim you can make that the previous vendor definitely did not make. It's unfakeable. A rep who thinks the thing won't get used cannot afford to write that sentence.

In my experience, buyers rarely pull the trigger. What the kill criterion does is convert an argument about your credibility into a small, bounded, reversible decision. Burned buyers aren't afraid of your product. They're afraid of being wrong again in front of their boss. Give them a documented exit and you've removed most of the personal risk from saying yes.

This changes your demo completely

Here's where a lot of deals get thrown away after a great discovery call. The rep runs a beautiful post-mortem, builds real trust, and then shows up to the demo and runs the standard demo. Dashboard first. AI feature second. The impressive thing your product does that nothing else does.

Wrong room. A burned buyer does not want to see the ceiling. They want to see the floor.

The shiny feature is what got them last time. Somebody showed them a gorgeous predictive dashboard, they imagined the future, they signed, and then discovered that populating that dashboard required their crews to enter data they were never going to enter. The demo sold the top of the product and the bottom of the product is what killed it.

So invert it. Show the boring workflow. The single most common thing a frontline user does, start to finish, at realistic speed, with realistic data — messy names, missing fields, the record that has a typo in it. Count the clicks out loud. Show what happens on a bad connection. Show the part where it syncs to the system they already have, and show the record landing on the other side.

Then say the quiet thing: "That's the screen your people will be on all day. Everything else I could show you doesn't matter if that screen is annoying."

I've built out how this plays by room, because the burn pattern differs by industry. If you're selling into field operations, the way to run this is laid out in the construction and trades demo script for a VP of Operations who's already been burned once, where the entire structure assumes the buyer is watching for the moment your product asks a foreman to do extra typing. In network operations the scar tissue is more specific — the telecommunications demo script for a room that's already been burned by AIOps deals with buyers who have sat through three anomaly-detection pitches and now want to see the false positive rate before they'll look at anything else. And in clinical settings, where the previous failures were often loud and expensive, the healthcare demo script for a CMIO who's already killed two vendors starts from the assumption that the buyer's job is to find the workflow break, not to be impressed.

The common thread in all three: let them look for where it breaks. Invite it. "Try to break this" is a much stronger position than "look how good this is," because if they go looking and don't find much, they've convinced themselves. Nothing you say will do that.

Two situations that need extra care

The person in front of you championed the last tool. This happens more than you'd think and it changes everything about tone. They didn't just get burned, they got burned publicly, and they may have spent political capital they haven't recovered. Never let them feel like the fool of the story. My framing is that the failure was structural — the rollout had no owner, the integration was oversold, the sequencing was wrong — because it almost always was. Then make the win theirs. "You already know more about deploying this than anyone else here. Last time nobody gave you a sixty-day checkpoint. This time you set it."

The previous vendor was your company. It happens. Different rep, different era, maybe a different version of the product. Say it first, before they do. Get the account history, find out what actually went sideways, and be specific about what changed — not "we've come a long way" but what shipped, what broke and got fixed, what's structurally different now. If you don't know, say you don't know and go find out. The one unrecoverable move is being surprised by your own company's history in front of the customer. Similar dynamics show up on the carrier side, where the insurance claims demo for buyers who are looking for where it breaks assumes a room full of people whose job is professional skepticism about promises.

The reframe worth keeping

A buyer who tried something like this and got burned is better than a buyer who has never tried anything. They have budget precedent. They have a defined problem they cared enough about to spend money on once. They have a detailed, hard-won understanding of what implementation actually requires in their organization. Most of your discovery is done for you.

What they don't have is a reason to believe you. That's not built with adjectives. It's built by taking their failure seriously enough to design around it, putting names and dates on paper, and being the only rep willing to write down the conditions under which they should fire you.

If I were sharpening this today, I'd rehearse it before I ran it live, because the post-mortem question only works if you can sit through the silence afterward without filling it — which is a skill, and it's not one you build on real deals. That's what I use DrillCall for: run the burned-buyer scenario a dozen times, get the follow-up questions to the point where they're reflex, and practice holding the pause until they actually tell you what happened.

Then go ask the question. "Walk me through what happened." Most of the time, they'll tell you exactly how to win.