Ben Kennedy of Branch.io on Why You Are Using Trials Incorrectly

Ben Kennedy, senior sales engineer at Branch.io, believes you are using your software trial incorrectly in your sales motion.

The proof-of-concept stage in a SaaS sales motion needs prove three things:

The Business Win — does the ROI make sense?
The User Win — would the day-to-day operator say they would adopt it?
The Technical Win — does the tech work with this customer’s data?

These can come from three different people you need to say yes: for example, a CFO, an end-user, and an engineer.

Different Tools For Different Problems

As a sales organization you have a portfolio of tools you can use to accomplish each type of win above.

Whitepapers can present analysis and data on the solution’s capabilities and value.
Reference calls to existing customers can validate assertions about the post-sale value of the solution, but can be hard to scale if you offer a direct connection for each opportunity versus a recorded testimonial.
Demo instances, in which the customer sees sample data in a sample instance, do not require a technical onboarding. One single demo instance can be cloned and distributed.
Full-blown trials, in which the customer’s data is spun up inside a working instance of the software, are from a technical standpoint equivalent in cost to a full customer. Trials are therefore a powerful but relatively expensive tool.

Why Not Trials For Everything?

Many salespeople, especially those early in their career, default immediately to offering a full trial because it’s an effective way to get a prospect to keep talking to you.

One problem with using trials for all three proof-points is that trials focus attention on the data not the product or potential value. This may not be effective for the Business/ROI win, where you want attention focused on value instead of the location of buttons or whether the first-pass configuration is exactly correct.

A second problem is that trials are resource intensive on your technical team. A 60% conversion rate from trial may sound great…until you realize you are chewing up your technical team providing full customer portals to a 40% of opportunities that never become customers.

“Trials are very difficult to measure, and take a lot of resources and time. They stifle the way you can scale an SE organization.” ~ Ben Kennedy, Branch.io

How To Use Trials Effectively

Where then is the appropriate place to use trials?

Trials for the Business Win: no. Using a trial to try and prove ROI will hurt you by focusing the business decsionmaker on the wrong inputs, like a pet feature request. To prove ROI for the business win the best tools are benchmarks, analysis, and references.

Trials for the User Win: no. Your end-user is imagining whether they will be happy using the product in six months. Yes a full-blown trial with their own data could help them imagine that. However the risk is that they focus on the minor inconsistencies in their data that are inevitable from a first-pass trial implementation. You want your user focused on the potential of the product, not the details of the data. For the User Win, the best tool is a demo instance.

Trials for the Technial Win: yes. Of the three wins, only the technical win requires validating that the product works with a specific set of data. For this, the best technique is indeed to onboard that specific dataset into the product via a trial instance.

This is so important that Ben has a slide dedicated to this in his training deck:

source: Ben

Putting Demos and Trials Into Practice

Ben offers three suggestions for putting the above best-practices into practice.

Recognize what you’re trying to prove or accomplish. Is the customer asking whether the product works technically? That’s a Technical problem, use a trial. Is the customer asking whether teams can manage the software day-to-day? That’s a User win, give them a demo instance.
Handle the request for a trial like it’s a sales objection. Respond by uncovering the customer’s true need, and then use the tool appropriate to that need.
Have a Demo version of the product in your toolbox. If you don’t have a demo version of your product, not only are you hampering your SE team’s ability to scale, you are missing an opportunity for higher conversion rates by focusing users on product potential.