Technical sales, like everything else in business, is a form of gambling. We’re taking a calculated risk when we spend time researching a customer organization, talking to buyers, and crafting our presentations and proposals. The hope is that the risk will pay off with a sale large enough to justify the cost to acquire as well as any opportunity cost we incurred by not pursuing other prospects.

But when a customer asks us to deliver more than a standard demo – and go to the effort of putting together a proof of concept (PoC) or implementing a pilot – that raises the stakes substantially. It’s critical that technical sales teams weigh the risk (i.e. time and effort) against the potential reward before sitting down at the table.

Demos and Presentations

Demos and presentations are the minimum ante for technical sales. No smart customer is going to buy a solution without getting a look at the actual product or a detailed breakdown of a proposed service. That said, how much a sales team customizes a demo or presentation is a case-by-case judgment call.

If your solution does a limited number of things for a limited range of customers, then you can probably get by with just a standard demo / presentation, or variants for each major vertical. For instance, when I worked at a company that developed intranets, we had one mock-up for a hospital with pages for “Pediatrics” and “Radiology”, another mock-up for a bank with pages for “Commercial Lending” and “Mortgages”, then a truly generic demo intranet for all other verticals.

As for how much effort to invest tailoring things to a specific prospect, that again is a judgment call. At minimum, it’s good to have an introductory and summary slide referencing the specific client’s context and highlighting how the rest of the presentation relates. You can also err on the side of including too much in your master presentation deck / demo, then practice skipping around and improvising on the fly (PowerPoint’s presenter view is great for that.)

But if an opportunity is so important that you’ll spend months wondering what went wrong should you lose…then it might be worth tailoring every slide, image, bullet, and feature walk-through to fit the customer’s specific goals, work context, and use case.

Proofs of Concept

Some customers demand more than a rehearsed “dog and pony show” demo. They want proof that your solution can accomplish something specific to their organization, whether it’s a drone carrying 200 kilograms of medical supplies without damaging them or an AI app searching a database of 16,000 documents for potentially classified information.

In these cases, ask:

  • Do you need to prove yourselves to this customer? If it’s a relatively small account with a relatively mundane need in an area where your demo and references speak for themselves…then perhaps not. In these cases, it might be worth putting the customer in touch with a satisfied client for whom you successfully solved a comparable problem. In other words, offer “social proof” rather than a PoC.

  • What exactly do you need to prove? Make sure both you and the customer have a clear, measurable definition of what would constitute success in terms of cost savings or capabilities added. Keep it simple and focused on the customer’s explicitly expressed goals and objectives. This is not the time to show all the other amazing things your solution can do.

  • How much can you control the process? Ideally any PoC can be on your own terms, to the greatest extent practicable. For instance, let’s say the customer just needs to confirm that the remote monitoring features of your industrial pumps work with their preferred software. In this case, you might see if it would be sufficient for your company to obtain a demo copy of the software, do the setup in advance and then run it on your own computer rather than trying to actually set it up in the customer’s environment where any number of other factors could ruin the PoC.

Pilots

Pilots – where the customer actually implements your solution at a limited number of sites, or with a limited number of users, for a limited time – represent the biggest gamble of time, money, and effort. However the customer might have a legitimate reason for conducting a pilot if there are questions about the scalability, reliability, compatibility, and/or long-term viability of the solution.

When measuring whether a full pilot is worthwhile, ask:

  • Can we still profit – or at least break even – on a limited implementation?

  • Will the pilot implementation demand more attention and pull significant resources from other sales opportunities and existing customers?

  • What is our ideal outcome and what is the most likely outcome? If we run a successful pilot within the customer’s Asia-Pacific region, will they immediately scale it worldwide?  Or will it be a slow process of selling to each other region?

  • Will the cost of the pilot fit within the acceptable cost to acquire the hoped-for larger engagement?

Obviously — unless you’re a cloud software company that can provide a free trial with near-zero implementation effort — these types of pilots should be reserved only for the largest opportunities. But as gamblers say, sometimes you have to go “all in” to win the biggest prize.

Conclusion

How much you’re willing to gamble on any particular sales opportunity is a value judgment only your team can make. Whether you deliver a standard presentation with just slight customization, a more tailored proof-of-concept demo, or a full-blown pilot implementation, the question is not just how much time and effort is required, in absolute terms, but how the risk compares to the potential reward.

If you’re interested in learning more, contact Crosscheck for a consultation.

Emil Heidkamp

Emil Heidkamp is the founder of Sonata Learning Software Success.  He has developed successful user training programs and support resources for enterprise software publishers of all sizes, from Microsoft to mid-size market leaders in various industries to growth-stage startups.

SHARE