Why a Good Demo Can Still Miss the Buying Decision?

The VP likes the software demo, but the operations team is still worried about data migration. The account team books another meeting and records the opportunity as progressing.

I’d be careful about calling that progress. The senior person may be comfortable with the business case, but the people who have to work with the system still have unanswered questions. We could run another round of demonstrations and find ourselves in the same position.

Skip Miller’s ProActive Selling has sections on educating buyers, validation and “finding trains.” I use those ideas whenever possible to ask what each person in a buying decision needs to settle.

The demo and the decision are doing different jobs

Consider a company evaluating a marketing platform. The campaign manager wants to know how leads move into the CRM, whether existing data can be migrated and what happens to live campaigns during the change. These are reasonable questions. If the new system makes everyday work harder, somebody will have to deal with that long after the sales team has moved on.

So show the manager how it works. Let the team challenge the workflow. I would be concerned if we spent an entire meeting discussing pipeline growth without anybody asking whether the system could be implemented.

The VP of Marketing may be looking at a rather different problem. The team could have a limited budget, agreed targets and projects that already demand attention. A new platform would need to justify the time and money taken away from that work.

Miller’s distinction is useful here. I would use education to help the buyer understand what the platform does in their workflow. Validation asks whether the proposed purchase holds up against their requirements, priorities and risks. That might call for a technical test, a financial comparison or evidence from an existing customer.

I wouldn’t assume that only managers need education or that every VP wants validation. Some executives may ask to inspect the technical details themselves. An end user might challenge the financial assumptions. I’d ask each person what they are responsible for deciding.

And a positive conversation with an executive tells us very little about whether the product meets the requirement. If it cannot, I would rather discover that while we’re still discussing the purchase.

Which train is leaving the station?

Miller also talks about “finding trains.” I like the image because executives already have several initiatives in motion. A new purchase has to find a place among them, and a long feature list may have little to do with what the business is trying to finish this quarter.

The same VP of Marketing may be working on lead quality and preparing to launch in a new market. Both sound like areas where a marketing platform could help. But perhaps the market launch has a deadline and an approved budget, while improving lead quality is still an idea on someone’s planning sheet.

If the launch is the priority, we’d need to know how campaigns are created for the new market, who will run them and whether the current tools can support the work. A lead-scoring demo might be rather impressive and still have little to do with the decision in front of us.

I’d ask which initiative is taking up management time and where it is getting stuck. Then I’d speak to the people responsible for doing the work. They could point out a missing feature or a migration problem that changes the whole proposal. I’d rather hear that early than build a pitch around an initiative our product cannot support.

Salespeople are quite capable of hearing a priority mentioned in passing and building an entire pitch around it. I’d want the buyer to confirm the problem before calling that an opportunity. Polite agreement during a presentation tells us very little.

The VP cannot settle every objection

Take data migration. Operations has to work out whether the existing records can move safely, and security may ask who will have access to customer information. Procurement could still have contract terms to settle. The VP’s enthusiasm won’t answer those questions.

I’d want each team to tell us what could stop the purchase. If operations asks for a trial, we should agree on what it will prove. Security may need to examine the access model before the team can proceed. A room full of people nodding along can be misleading when they are nodding for different reasons.

The VP might need the platform before a market launch, while the implementation team says migration will take longer. We need to examine that disagreement before promising a delivery date. Otherwise, the sales team has simply moved the problem to somebody else’s calendar.

What did we actually agree?

After a demo, I’d ask whether the customer has named a problem it wants to solve now and agreed on a test that will help it decide. If migration is the concern, who will run the trial? And what happens if it fails? That is a rather more useful follow-up than another hour of slides.

Sometimes the customer likes the product but has no budget or reason to buy now. A technical trial might expose a gap. I’d rather know either of those things than spend months producing presentations that nobody can use to make a decision.

If all we have at the end of the meeting is a request for the slides, I would hesitate before marking the deal as progressing.