If you’re selling enterprise hardware, software or services, you'll know these three types of 'try-outs' too well. Chances are you've invested heavily in some, but found they went nowhere; there are reasons. In this post, I profile the six most common 'pre-purchase try-outs' — the benefits and pitfalls, when to choose which, when to charge — and how to win more. The principles apply to hardware and services, too, not just software.
1. Unguided trials
Free trials are more common for consumer rather than business software, where vendors provide free downloads for trial periods of say seven to 30 days. Free trials of enterprise software are becoming more common with more software delivered as a service (SaaS).
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 Zendesk, very big numbers are 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 - 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 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 did 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 kind 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, we say guidance is essential.
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 resources to it (i.e. nominated staff)
- 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 on the trial's progress
- You have 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 trials
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 are keen to try your software because they have real problems, especially because the exercise will soak up your time as well as that of the trialist's team.
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
- Agree on a formal test process and on the format of reporting on results
- Agree on the key functions of the product or service to be tested
- 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 time-wasters 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. And the more he gets 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, 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 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:
- The timeframe for the evaluation and who will be involved in it
- The test process and format of test report
- The key functions to be tested (a shortlist, not all)
- Data sets to be used, the desired outcomes and how to measure them
- The amount of contact between the prospect's and your team
- The expected next steps, once the software has met all the test criteria.
A ‘bake-off’ is an evaluation process that is similar to a Proof Of Concept, but is quite distinct.
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, please pay attention to these details:
- Are the prospect’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 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 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 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, 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 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 you’re proposed solution includes hardware and cloud service. 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 for it, especially for service providers, and Senior VP Jeff Goldberg at Novarica 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.’
In other words: 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 specialised 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.
- Trackback Link
- Post has no trackbacks.