When a Buyer Says the Last Trial Didn't Work

Decide whether a previous unsuccessful trial deserves another look, what needs to change, and when to leave it there.

When a Buyer Says the Last Trial Didn't Work
On this page

When a buyer says, “We tried that before and it didn't work,” don't answer with a new feature list. Find out whether they want to discuss the experience at all. If they do, identify what failed and what would need to be different before asking them to spend more time on another evaluation.

The previous trial may contain the clearest explanation of what the buyer needs. Treat it as work already done, not an objection to get past.

The examples below concern an unnamed product and are fictional. They show how to make the next decision, not how Trellus or a particular competitor behaved in a customer trial.

Let the buyer decide whether to reopen the conversation

Start by acknowledging the previous effort without pretending you know what happened. “That sounds frustrating” may be appropriate if the buyer has described frustration. “I know exactly what went wrong” isn't, unless you actually do.

“Understood. I don't want to ask you to repeat an exercise that wasn't useful. Would you be open to explaining what didn't work, or would you rather leave it there?”

This isn't a line to deliver before continuing regardless of the answer. If the buyer declines, stop the investigation. Follow your team's contact-preference process rather than turning their explanation into a task to chase them again.

If they are willing to talk, don't make them reconstruct every day of the old trial. Ask for the part that decided the outcome. A buyer might say the product “didn't work” when a required field couldn't be saved, when setup took too much effort, or when the team didn't see enough useful conversations. Those are different problems.

Separate the requirement from the explanation for the failure

Suppose the buyer says, “We needed a callback to appear in the account owner's worklist, and it didn't.” That's a requirement and an observed result. It doesn't yet tell you why the callback was missing.

Perhaps the intended action wasn't supported. Perhaps the trial used a different record or owner. Perhaps the next step required a confirmation that no one understood. Keep those as possible explanations, not diagnoses.

“So the result you needed was a callback in the account owner's worklist. What did the rep do, and where did you check afterward?”

Ask about the exact setup only as far as it helps answer that question. If records from the earlier evaluation are available through the team's normal access, read them before asking the buyer to repeat information. Don't forward a private transcript or open another customer's account to demonstrate a point.

Write down what the buyer remembers as their account of the experience. If neither side has the original record, leave the cause unresolved. You can still decide whether a present-day check would be worthwhile without inventing a confident history.

“It's changed” needs to answer the old problem

A new interface, a different package or a broad compatibility announcement doesn't necessarily change the result the buyer needed. Before presenting an improvement as the reason to return, check the particular workflow.

For the callback example, that means the relevant platform, record, action, owner and destination. If the current alternative is a note that someone copies into a task, say so. A manual alternative may be acceptable, but it isn't an automatic callback appearing in the worklist.

The same standard applies when the earlier trial was of another vendor. You can explain the behavior you can substantiate now. You can't diagnose the other product from a brief complaint or promise that your product avoids every difficulty the buyer encountered.

If you don't yet know the answer, use the product-question check to send a precise requirement to the right colleague. “Please confirm whether this action creates this result in this setup” is answerable. “Tell me why we're better” isn't.

Two fictional cases, two different next steps

The required result is still unavailable

A sales manager previously tested an unnamed calling product. Her requirement was that a rep's requested callback reach a colleague's worklist without a separate manual task. The result didn't appear, so the team stopped.

After checking the current setup, the seller confirms that it still needs a manual task. The buyer says the extra action was the reason they stopped in the first place.

The useful answer is straightforward: the current workflow still doesn't meet that requirement. Don't book another pilot to see whether the buyer becomes more comfortable with the same gap. Explain the manual option once if it is relevant, let the buyer assess it, and accept the answer.

The earlier result doesn't settle the current question

In another fictional evaluation, a manager says that a small calling test produced few conversations. The team used one old list for a short period. They didn't record comparable calling time or agree what counted as a conversation.

That doesn't prove the product failed, and it doesn't prove that a larger trial will succeed. It means the earlier result can't answer every question the seller might want to ask of it.

First find out whether the manager still has a reason to evaluate the workflow. If not, the uncertainty isn't a reason to reopen it. If they do, propose a defined comparison using suitable lists, consistent outcome definitions and recorded calling time. Agree on what the test can teach; don't promise a minimum number of meetings.

In the first case, the seller can answer the requirement now. In the second, the buyer still has to decide whether another comparison would be worth their time. Booking both into the same trial would ignore what each conversation established.

Use a retry-decision card before suggesting another pilot

Decision aid for another trial: stop when a requirement is still unmet, check an unclear fact, or agree a demonstration of a relevant confirmed change; the buyer chooses whether to continue.

Keep this short manual note in the account location your team already uses. It isn't a required CRM schema or an automatic product feature.

  • Previous attempt: Which product or approach did they try, in what setup, and approximately when? Mark missing details as unknown.
  • Needed result: What specific job did the buyer need to complete?
  • What happened: Record the buyer's description and any available supporting activity. Separate an observed result from a proposed cause.
  • What is different now: Name a confirmed relevant change, or say that no relevant change has been established. Don't use a generic release announcement.
  • Smallest useful check: What demonstration, setup check or comparison could answer the remaining question? Who would do the work?
  • Decision: Stop, check one unresolved fact, or agree a further evaluation. Record only the next step the buyer actually accepted.

A filled note for the first case would end: “Current behavior still needs a manual task. Buyer confirmed that this doesn't meet the requirement. No new trial or follow-up meeting agreed.” That's a useful outcome even though it isn't a new opportunity.

The second might end: “Buyer is willing to review a comparison plan before deciding on another test. Seller sends proposed lists, definitions and effort. No trial start agreed.” Permission to read a plan is not permission to restart an account or send invitations to the whole team.

Make the next test smaller before making it longer

If a setup question can be settled by showing one action and its saved result, start there. Ask who needs to see it and what would count as an answer. There's little value in arranging a week of calls while a required record destination remains uncertain.

Other questions need ordinary working time and a sensible comparison. The one-week dialer pilot guide covers running that evaluation once the buyer has agreed it is worthwhile. It shouldn't be used to bypass the earlier decision.

Be specific about the buyer's work. Who prepares the list? Who checks the record? What access or setup is needed? What happens if the original gap appears again? If nobody can make time for the test, a different date or a decision not to proceed may be more useful than an unstaffed trial.

Finish by recording what actually happened in the call note. Keep the old experience visible so the next seller doesn't open with the same promise. Don't label the buyer “re-engaged” when they only explained why they stopped.

If you're considering Trellus for calling inside a supported CRM or sales engagement platform, bring the task that failed before and the result you need now. Ask to walk through that task. Another evaluation earns its place by answering a worthwhile question, not by asking the buyer to forget the last one.

Back to the Blog

About the author

Trellus Team

Guides from the team behind Trellus on power and parallel dialing, sales coaching, and working inside your CRM.