P: 1300 000 336

Home  >  B2B Blog

How to Win Software Trials, Bake-Offs and PoCs

Kim Brebach - Friday, June 01, 2018

How to Win Software Trials and PoCs | Technoledge

If you’re selling enterprise software, you'll be familiar with all of these. While they each have a place in the sales cycle, each can also work against you if you're not familiar with the nuances. We show when and where to use each, and the benefits and pitfalls. 

1. Unguided trials

Free trials are more common for consumer rather than business software, where vendors provide free downloads for trial periods of say 7 to 30 days. Free trials of enterprise software are becoming more common though, as more software is delivered as a service (SaaS).

Dell and Atlassian are 2 vendors who offer trials, and Zendesk is another. Zendesk provides an on-demand help desk and customer support portal for millions of users around the world, and offers a 30-day trial. With Zendesk, very big numbers re involved, so the company uses Totango technology to analyse user behaviour during trials, so they can fine-tune their marketing and sales activities. In Zendesk's case, it makes sense to enable thousands of people access to free trials like this, as the data gained is of such value.

So, what if you’re a small to medium sized company selling specialised enterprise software to a niche market?

You’ve probably had direct contact with prospective buyers already - phone call, online demo or maybe face-to-face meeting - and have an idea of their organisation, situation, people and problems. 

Should you let them play with your software? Let's take a look at the pros and cons. 

If you let your prospect's techies play with your software for a couple of weeks, what happens next? You'll ask them: ‘how did it go?’ or ‘what do you think?’

And you’ll get answers like ‘yeah, it went well,’ or ‘it’s pretty good.’ And just as often, you’ll get answers like: ‘Sorry, I only had time to take a quick look at it. Work got in the way.’ You will have no idea what they did, saw or experienced or even if they tried.

How do you recover from lukewarm responses like these? How do you rekindle the initial excitement and sense of urgency? Not easy. Products don’t sell themselves - unless they’re the type that people fall quickly in love with. So the big question is: if you can’t be sure of getting real traction with a free software trial, why would you agree to it?

We think you shouldn't. Unguided trials have no cost, no commitment and no criteria for the trialist and no guarantees at all for the vendor. For enterprise software, we'd say no to an unguided trial.

2. Semi-guided trials

If your software is off-the-shelf and ready-to-use, a free trial without limitations is only worthwhile if you can be absolutely sure that:

  • The trialist has agreed to a clearly defined outcome and trial period
  • The trialist has allocated a resource(s) to it
  • The trialist has agreed to a formal test process and to provide a formal test report at the end 
  • You have an internal champion who will safeguard your interests
  • You are welcome to go on-site (with notice of course) and check progress of the trial's progress
  • You have agreed on the next steps after the trial, when the software has proven itself. 

If you can't be sure of these, you might as well go the extra distance, make it a guided trial and be done with it. If your software isn't 'ready-to-use' and is more like a set of tools for developers, the Sandbox below in 4 would be more suited.    

3. Guided trials

Sure, the formality of a guided trial will knock out the tyre-kickers, but you don't want them anyway. You only want genuine prospects who want to try your software because they have real problems, because it will soak up your time - as well as that of the trialist. team.

Here are a few guidelines which will give you more control and involve less time for them and you:

  • Make sure there are other vendors under trial - but no more than 3
  • Agree a fixed time frame for the trial - and what happens at the end
  • Ensure the trialist has allocated at a resource(s) to the trial - and find out who it is
  • Agree on a formal test process and on the format of the test results report
  • Shortlist the key functions of the product or service to be tested
  • Agree on the datasets to be used for the trials
  • Define the outcomes the trialist seeks - and how to measure them
  • Agree on how much contact the trialist/trialist team can have with your people during the trial
  • Agree on the next steps once the trial is over - and the software has achieved the desired results.

The guided trial will knock out the time-wasters who just want to play, but that's why you do them. We think you're far better off doing fewer trials with fewer, more serious trialists.

The more you get to know the trialist before and during the trial, the more you can assess him, his team, the reality of his problems and his genuine desire to solve them. And the more he gets to know, like and trust you and your software. Guided trials are good for developing real relationships..

4. Development Sandboxes

This is a more common approach for development teams who want to check out software tools, rather than off-the-shelf software.

The sandbox is an environment created for the trialist where his engineers can ‘play’ with the technology to their hearts’ content. If it’s a cloud-based product or service, it’s even easier for both parties.

Whether on premise or in the cloud, the sandbox is a technical environment with well-defined rules and secure boundaries. It's a working environment where trialist developers can build prototypes and test them with real data, without affecting the production side of their business. While the environment is quite different from the guided trial above, exactly the same rules apply. You need to agree with the trialist organisation beforehand:

  • The timeframe for the evaluation and who will be involved in it
  • The test process and format of test report
  • The key functions to test (a shortlist not all)
  • Datasets to be used, the desired outcomes and how to measure them
  • The amount of contact between the trialist and your team
  • The expected next steps, if the software meets all the test criteria.

5. Bake-offs

A ‘bake-off’ is an evaluation process that is similar to a Proof Of Concept, but is quite distinct.

In a bake-off, trialists compare competing technologies head-to-head, to help them select the best one for their needs.

The problem with bake-offs is the amount of time they consume on both sides, so you need to be sure the trialist is serious, and also objective.

Another problem with bake-offs is that the best technology doesn't always win: it's not uncommon for a C-level exec to override the bake-off conclusion, and choose a vendor for reasons not based on the technology or the result.  

For best results in a bake-off, pay attention to these details: 

  • Are the customer’s problem(s) and the desired solution clearly stated?
  • Are the evaluation process and criteria clearly defined?
  • Has the expected outcome been defined in measurable terms such as speed, cost, time or effort?
  • What form will the results be presented in - reports, sets of data, charts or a presentation?
  • Will you be able to ensure that your product is installed and set-up for top performance?
  • Is the timeframe clear and does it include next steps when the Bake-off is complete?
  • Are there only 2 vendors being considered? (Any more will make the results very hard to interpret and compare.)

By the way, a 'Proof of Concept (PoC) and “Bake-Off” are not the same thing,’ says Cathy McKnight at the Digital Clarity Group, ‘although many people treat them as such.’

She believes that bake-offs are ‘inherently flawed’ since they’re often used to cover up an existing preference for a vendor, or tend to focus on features and functions instead of outcomes, and because ‘Bake-Offs devalue the finalists by putting them in a cage-match of sorts.’

The Pros and Cons of Bake-offs

For these reasons, you may be averse to bake-offs, even if it’s a way to show the trialist that you’re willing to invest in the relationship. A bake-off will consume about the same vendor resources as a PoC, so it’s not a light decision to take.

Ideally the exercise is limited to 2 short-listed vendors. If more are included, think twice before agreeing. If more than 3 are invited, decline the offer. If you feel that the bake-off is well-designed and well-defined, that the prospect is open-minded and that you can outperform your competitor, then it’s worth a shot, if you're up against one other vendor.

Many of our clients compete with global software vendors and the big guys love bake-offs: they fly out their top product people from HQ, they wine, dine and impress the trialists - and they have inordinate influence over the bake-off criteria. Not only does this disadvantage the local players, it can cloud or eliminate key criteria on which they could win - like speed, knowledge and depth of local support which, later on, will be far more important when the big wigs have gone home. 

Key considerations in bake-offs have to do with the trialists: if they have a long-standing relationship with the other bake-off contender or have some of their software installed, it's possible that a bake-off is a formality. They may have made up their minds already, and just need a bake-off to 'prove' their decision. If you suspect this, don't waste your time. 

6. Proof of Concept (PoC)

The term is used rather loosely these days. Originally, inventors and developers used a PoC to prove to stakeholders that a new technology could deliver on its promise. These days, it’s become a process for assessing IT vendor performance and is often confused with the bake-off. As a client of ours puts simply: ' a PoC proves that the product does what it says on the box.’

Cathy McKnight puts it more eloquently in Putting the “Proof” in Proof of Concept: ‘a PoC is an execution of project-related tasks that provide evidence that what has been promised by the (singular) preferred technology vendor and/or service provider can be delivered. Yes, she argues that a rewarding PoC should focus on a single vendor’s technology.

Secondary PoC Considerations

A PoC should do more than test that your product delivers the functionality you claim. It’s an opportunity for you to show how your technology integrates with the buyer’s IT environment, and how compatible it is with the IT products and services installed. This applies even more so if you’re proposing a cloud service. Often these questions will have been discussed before the PoC, but the trialist's team may want to see proof of your claims and assurances.

At this point, it’s useful to think of this exercise as a PoV or Proof of Value. Andrew Brockfield from AppDynamics makes this distinction: ‘… a PoC proves the proposed solution works, a PoV proves it will work for the customer, and that the expected value to be realised is real and can be justified and measured.’ In other words, it’s an opportunity to go that extra step to win the customer over.

Should you charge for a PoC?

You need to be sure that you can commit your best people to the PoC for the right amount of time, and that the buyer will do the same. You also want to make sure that a couple of business managers are involved in the process, so they get an early introduction to its purpose and understand the evaluation process. Doing that reduces the risk of the C-level over-ride we mentioned above, with guided trials.

The final question is: should you ask to be paid for your contribution to the PoC?

Cathy McKnight argues for it, especially for service providers, and Jeff Goldberg at Celent is in favour of ‘paying a fair price for the proof-of-concept phase.’ He argues that ‘an unpaid PoC is like playing poker without having to pay the ante. You might start off interested in the game but you won’t care as much about your cards. The reality is that a proof-of-concept won’t be successful without both the carrier and vendor working together, regardless of how strong a solution the vendor offers.’ For a PoC to work, you both need skin in the game.

Think of the single-vendor PoC as a mini pilot, which puts the technical team in a really strong position to justify its decision to the senior managers. For a small investment, you have proven the value of your product to the organisation and that is does  ‘what it says on the box’. Few CEOs or CFOs will argue with that.


Kim Brebach
Content Chief

I've always loved people and words. As long as I can remember I've been a story-teller and the team here says I'm good at it. That's probably why I head up the Content Creation team: I create the arc of the story and others add their magic.

Trackback Link
Post has no trackbacks.

Comments Posted

Post a Comment Here

Captcha Image

Recent Posts


We thought we needed a quick website update, but the Technoledge process made us realise we hadn’t really considered our competitors, how our customers see us and what markets we are best suited to serve. As a result, the website has been completely redone, including new functions. We can now focus on just one market, which also better suits our channel model.
Nick Power
MD, Highway 1.


Meet more clients



Call us on 1300 000 336 or book a Growth Strategy Session