Why buyers do nothing after a good sales demo

Imagine you have built software that takes a job someone does in a spreadsheet and makes it easier. You show it to the person who does that job. They understand the product, recognise the problem and say the demonstration was useful. Then the conversation goes quiet, and the spreadsheet survives another month.

You can spend a lot of time trying to work out which feature was missing. Perhaps the product needed another integration, or the homepage failed to explain the automation properly. Those are possible explanations. But before changing anything, find out what the buyer chose to keep doing after your call.

That existing arrangement is a competitor too. If it keeps producing an acceptable result, your product has to justify the work and risk of replacing it. A buyer can agree that your software is better and still decide that changing over is not worth doing now.

What doing nothing actually means

Doing nothing sounds like an absence of activity, but a company that declines your product still has to get its work done. Someone continues entering orders, assembling reports or chasing approvals. The customer has chosen to carry on with a process that already exists.

April Dunford starts her positioning method with the alternatives a customer would actually use if the product did not exist. Those alternatives can include a spreadsheet, a manual process or another person doing the work. A list of software companies with similar features can miss the comparison that matters in the buying conversation. Dunford's positioning guide

Suppose your product prepares a weekly operations report. Another reporting tool may have an uglier interface and fewer integrations, so you can explain why yours is better. But the prospect may never have seriously considered either tool. Their actual alternative is a colleague who knows which files to open on Friday afternoon.

That colleague may take a while and occasionally make mistakes. They also know which figures need checking, which exception needs explaining and who will complain if a number looks wrong. You are asking the business to replace some of that familiar knowledge along with the spreadsheet.

The buyer has a working arrangement

From the founder's side, adopting the product can look like one purchase. From the buyer's side, the purchase begins a piece of work. In our reporting example, someone has to connect the data, check the output against earlier reports and work out what happens when an input is missing.

The buyer also needs to know who will take responsibility for the result. If the current report is late, the team knows whom to call. If the new system produces a convincing but incorrect number, the person who recommended it may have to explain why the business trusted it.

This gives the old process an advantage that will never appear on your feature comparison. Its faults have already become familiar. People know how to work around them, and keeping it does not require them to introduce a new system to everyone else.

That does not make the current process good. It means you have to understand the whole replacement. Faster report generation is one benefit, while checking, training and handling a failed import are part of the proposed change. A credible sales conversation needs to account for both.

It is worth asking whether the prospect has already tried to improve the process. Have they paid someone to fix the spreadsheet, looked for a replacement or had to redo a report after an error? A complaint tells you where the irritation is. An attempted fix gives you something more concrete to investigate.

Find the point where the old process becomes costly

A spreadsheet can be an adequate solution for one team and an awkward one for another. The useful difference might appear when the person who maintains it goes on leave, when another department needs the report or when a late correction affects a decision that has already been made.

These are possible situations to investigate, not reasons to declare every spreadsheet broken. If the existing process works, the buyer is allowed to keep it. Your task is to find the circumstances in which your product delivers a benefit that the customer cares enough about to make the change.

That also changes what you should demonstrate. In the reporting example, showing that a report appears quickly leaves several important questions unanswered. Showing how the buyer checks a disputed figure, traces it to its source and corrects it before distribution may address the part of the job that carries responsibility.

You need evidence that your product can do this reliably. Positioning cannot make an inaccurate report trustworthy, and a confident explanation of a feature cannot replace testing it on the customer's data. The demonstration should give the buyer something they can inspect.

Dunford also distinguishes customer positioning from the story told to investors. Customers need to understand the value available now against their alternatives. A vision of where the company might eventually go serves a different conversation. Her explanation of positioning preparation

Sometimes the buyer already wants to change

There is another situation that can look almost identical from the seller's side. The buyer agrees that the current process needs replacing and prefers your product, but still cannot commit to the purchase. They may be uncertain about the package to choose or whether the result will justify the decision.

The team behind The JOLT Effect separates preference for the status quo from indecision about a purchase the customer wants to make. The two can coexist, so a stalled deal alone does not tell you which explanation applies. The JOLT team's account

In that second situation, repeating the damage caused by the spreadsheet can fail to answer the buyer's question. They may already understand the damage. What they need to establish is whether changing to your product will create a problem they cannot handle.

For our reporting tool, a useful next step might be to run it alongside the current process for one reporting cycle. Agree on which report to test, how the outputs will be checked and who will investigate a discrepancy. Keeping the current process available during the test can make it easier to examine the proposed replacement.

That is a test you could propose, not a guarantee that the customer will buy. A security requirement, a missing capability or an unaffordable price can still stop the purchase. The test is useful if it resolves an actual uncertainty rather than adding another meeting to the deal.

What to ask in the next conversation

Before rewriting the pitch, ask the prospect to show you how they completed the job last time. Follow the process far enough to see where the work happens, what needs checking and who owns the result. Then ask what, if anything, has made them want to change it now.

If they cannot identify a reason to change, you may have found a person who understands the product but does not currently need it. If they want the change, ask what they would have to establish before they could recommend the purchase. Their answer can tell you what the next demonstration or test needs to resolve.

For the reporting tool, I would start with the last report that caused trouble. Ask the buyer to open it, show where the disputed number came from and explain what they had to do to put it right. You can then see whether your product would help with that particular piece of work, and what the buyer would need to check before trusting it.