'We Tried It Before' Objection: Recovery Scripts

The "we tried it before and it failed" objection isn't a rejection, it's an invitation to run a post-mortem the buyer never got to run. Your job is to separate the tool from the implementation, the sponsor from the strategy, and the old context from the current one. Do that in the next ninety seconds of the call, and you turn a hard no into a diagnostic conversation where you're the expert helping them understand why it failed — which is exactly the seat you want.

Why this objection is actually a green flag

A prospect who says "we tried it before" is telling you three useful things at once. They already understand the category, so you can skip the education phase. Someone internal championed the idea once, meaning the political will existed. And the pain was severe enough to justify a purchase, which almost never disappears completely after a failed rollout.

The reps who lose here treat the objection as terminal. They apologise, retreat to "well if anything changes...", and burn the account for a quarter. The reps who win treat it like discovery gold. Failed implementations leave behind stakeholders with strong opinions, unused budget lines that got quietly reallocated, and a very specific mental model of what "not working" means. All of that is information you can use.

The move is not to defend your product against a competitor's failure. It's to get curious, faster and more precisely than any rep who came before you.

The three-question diagnostic

Before you deploy any script, you need to know which failure you're dealing with. There are really only three:

1. Tool failure: the software genuinely couldn't do what was promised.
2. Fit failure: the tool worked, but for a different use case or company size.
3. Adoption failure: the tool worked and fit, but nobody used it.

The distinction matters because your recovery script changes completely depending on the answer. Adoption failure is the most common by a wide margin, and it's the one where your product is least relevant to the actual root cause. If you try to sell features against an adoption failure, you'll lose to the incumbent's ghost.

Ask these three, in this order:

• "When you say it failed, what did failure look like day-to-day? Was it that the tool couldn't do something specific, or that people stopped logging in?"
• "Who owned the rollout, and are they still there?"
• "If you had to point at one decision that, in hindsight, sealed it, what would it be?"

That third question is the one most reps skip. It forces the buyer to move from a vague grievance to a specific narrative, and the specifics almost always reveal that the failure wasn't about the category at all.

Recovery scripts by failure type

If it was a tool failure

"That tracks with what we hear about [competitor] in [specific segment/use case]. The architecture decision they made around [specific technical thing] works for [X] but breaks down when you need [Y]. Can I show you how we handle that specific piece, and you can tell me if it would have solved what you hit?"

The move here is specificity. Naming the exact architectural or design limitation shows you understand the category deeply, not just your own pitch deck. If you don't know the competitor's weaknesses at that level, get your product marketing team to build you a one-pager for every major alternative. This is table stakes for handling this objection well.

If it was a fit failure

"Makes sense. A lot of teams buy [category] when they're at [stage A] and outgrow the tool at [stage B], or vice versa. Where are you now versus when you bought it, and what's changed about how the team works?"

You're reframing the past purchase as a snapshot of a prior version of the company. The tool didn't fail; the company evolved past it. This lets the buyer save face and opens the door to "so what's different now?" which is where you want to be.

If it was an adoption failure

This is the hardest one, because if you can't credibly explain why adoption will be different this time, you'll fail the same way. Do not skip past this.

"Adoption is where most rollouts in this category go sideways. What was the plan for driving usage after go-live, and who owned it? I ask because we've seen the same pattern enough times that we built [specific onboarding/enablement motion] into how we deploy, and I want to be honest with you about whether it would actually change the outcome."

The word "honest" is doing real work in that script. You are explicitly not promising this time will be different. You're inviting a shared examination of whether the conditions that caused the last failure still exist. If they do, and you can't change them, walking away is the right call, and saying so out loud builds more trust than any close.

The reactivation play most teams miss

Failed implementations are often sitting in your CRM as closed-lost from eighteen or twenty-four months ago, and nobody is working them. That's a mistake.

Say your team has 200 closed-lost opportunities where the loss reason was "went with [competitor]." In a typical B2B market, expect that a meaningful chunk of those deployments have quietly underperformed or been ripped out. The champion may have left. The economic buyer may have changed. Budget cycles have reset at least once.

A short, specific reactivation sequence works well here. First touch: reference the original evaluation by date and mention one specific thing that's changed on your side since. Second touch: a genuinely useful piece of content about common failure modes in the category, written for people who already own a tool. Third touch: a direct ask for fifteen minutes to compare notes.

You are not selling. You are auditing. The pitch is that you've watched this movie enough times to be useful, whether or not they end up buying from you. Teams that run this play consistently source pipeline that costs nothing to generate and closes faster than net-new, because half the qualification work is already done.

The takeaway

• Diagnose which of the three failure types you're dealing with before deploying any recovery language; the wrong script against the wrong failure will lose you the deal.
• Build a competitor weakness one-pager for every major alternative in your category, at the architectural level, not the feature level.
• For adoption failures, be willing to say out loud that this time might not be different unless something specific changes; that honesty is the differentiator.
• Run a quarterly reactivation motion against closed-lost opportunities older than eighteen months, filtered by "went with competitor" loss reason.