In this post, I profile the 6 most common ‘pre-purchase try-outs’ — the benefits and pitfalls, when to choose which, when to charge — and how to win more by b2b tech marketing. The principles apply equally to software, hardware and services.
1. Unguided Software trials
Free trials are more common for consumers than business software, and vendors provide free downloads for trial periods of 7 to 30 days.
Dell and Atlassian are two 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 the large numbers Zendesk sees the company uses Totango technology to analyse user behaviour during trials; that helps them fine-tune their marketing and sales activities. In Zendesk’s case, it makes sense to give thousands of people access to free trials like this. 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 – a phone call, an online demo or maybe a face-to-face meeting – and have an idea of their organisation, situation, people and problems.
Should you let them play with your software, on their systems or in the cloud?
The pros and cons
If you let your prospects’ techies play with your software for a couple of weeks, what happens next? You’ll ask them: ‘how did it go?’ or ‘what did you think?’
And you’ll get answers like ‘yeah, it went well,’ or ‘pretty good.’ 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’ll have no idea what they did, saw or experienced or even if they tried.
How do you recover from lukewarm responses like these? And how do you rekindle the initial excitement and sense of urgency? Not easy. Products don’t sell themselves – unless they’re the kind that people fall head-over-heels 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 for the vendor. For selling high-value enterprise software, guidance based on agreed criteria is essential, not just nice to do.
2. Semi-guided Software 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
- They have allocated resources to it (i.e. nominated staff)
- And then 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’re welcome to go on-site (with notice of course) and check on the trial’s progress
- You’ve agreed upfront on the next steps once the software has proven itself.
If you can’t be sure of these, you might be better off making it a guided trial, to give you more control. 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 Software trials
The formality of a guided trial will knock out the tyre-kickers you don’t want anyway. You only want genuine prospects who are keen to try your software because they have real problems, especially because the exercise will soak up your time as well as theirs.
Here are a few guidelines which will give you more control and involve less time for both sides:
- Where multiple vendors are involved, make sure there are no more than 3 on the shortlist
- Agree on a fixed time frame for the trial
- Make sure the prospect has allocated resources to the trial, and find out their contact details
- A formal test process and on the format of reporting the results has been agreed on
- The key functions of the product or service to be tested have been agreed on
- Agree on the data sets to be used for the trial
- Define the outcomes the prospect seeks, and how they’ll be measured
- Agree on the next steps once the trial is over and the software has produced the desired results.
The guided trial will knock out the timewasters who just want to play with your gear. We think you’re far better off doing fewer trials with more serious prospects.
The more you get to know the prospect 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. It works in reverse too; he’ll get to know, like and trust you and your software. Guided trials are an opportunity for building lasting relationships.
4. Development Sandboxes
This is a more common approach for development teams who want to check out software tools or middleware, rather than off-the-shelf software.This is a more common approach for development teams who want to check out software tools or middleware, rather than off-the-shelf software.
The sandbox is an environment created for engineers who want to ‘play’ with your technology to find out how clever and robust it is. 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 a prospect’s 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 on the same rules with the prospect beforehand:
- Time frame for the evaluation and who will be involved in it
- Test process and format of test report
- Key functions to be tested (a shortlist, not all)
- Data sets to be used, the desired outcomes and how to measure them
- Amount of contact between the prospect’s and your team
- Expected next steps, once the software has met all the test criteria
5. Bake-offs
A ‘bake-off’ is an evaluation process that is similar to a Proof Of Concept, but there are distinct differences.
In a bake-off, prospects 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 prospect is serious, and also objective. In addition, bake-offs tend to include hardware and/or cloud services that add more complexity and cost to the exercise.
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 related to the technology or the test result.
For best results in a bake-off, these questions should have positive answers:
- Are the prospect’s problem(s) and the desired solution clearly stated?
- Is 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 time frame clear and does it include next steps when the bake-off is complete?
- Are there only two 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 prospect 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 a single competitor, then it’s worth a shot.
Many of our clients compete with global software vendors, and these big guys love bake-offs: they fly out their top guns from HQ, they wine, dine and impress the prospect, and they tend to 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 – such as speed, expertise and depth of local support which will be far more important later on 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, a bake-off may be just a formality. They may have made up their minds already, and just need a bake-off to show that they’ve evaluated other vendors. 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 which 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 existing IT products and services. This applies even more so if your proposed solution includes hardware and / or cloud services. Often these questions will have been discussed before the PoC, but the prospect’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 that paying a fair price for the proof-of-concept phase is the way to go, especially for service providers. Another IT veteran compares an unpaid PoC with a game of poker that has no money on the table. The participants will soon lose interest, and the outcome won’t be memorable.
For a PoC to work, you both need skin in the game. Often, you have to create an environment for a PoC that mirrors the final installation, in functionality if not in size. That’s an expensive exercise both in terms of cost (for equipment and services) as well as specialist resources, and that makes it reasonable to ask for payment.
Think of the single-vendor PoC as a mini pilot, which lets the prospect’s technical team test its preferred solution before presenting it to senior managers. For a small investment, they can prove the value of the solution to the organisation and satisfy themselves that your product does ‘what it says on the box’. Few CIOs or CFOs will argue with that.
Contact us if you’d like a hand tightening your trial, bake-off or POC criteria – or your marketing processes.
Original text written by Tracey James and Updated by Matthew Whyatt
