If you’re a SaaS company, you know the demo is a critical part of the sales process. But not all demos are effective. In fact, many are downright boring and end up losing the customer’s interest. This article intends to answer the question once and for all, how to run a demo for your SaaS company that actually gets more customers to sign up.
In order to describe the “perfect demo”, we need to talk about the types of demos. There are three different demo styles or scripts.
- The “Menu” Demo
- The “Feature Review” Demo
- The “Day in the Life” Demo
Each of these three scripts has a different feel to them. And they can all be useful in different parts of the sales process.
Whatever script you use, the structure is critical. You need to capture the attention of your audience in the first 2 minutes of the discussion. Otherwise, you might lose their interest – and the sale.
How to Run a Demo and How Not to Run a Demo
The three demo types we’ll be focusing on highlight different perspectives on the purpose of a demo. Some are useful in some scenarios. Some are not.
The important thing is knowing what part of the sales process you’re in. If you’re trying to sell to potential users, you need to speak their language. Sometimes, however, we’re just trying to check boxes off an RFP questionnaire. That’s a completely different scenario requiring a different script.
But we’ll run through each one and highlight the pros and cons.
The “Menu” Demo
The “Menu” demo is the most frequently used demo script. In the “Menu” Demo, the demonstrator goes through each of the major functions of the software – as if going through the top level menu – and explains why they’re there and what they do. The demonstrator doesn’t go into each detail, but the overall context of each section is provided.
For example, imagine the main menu of your software were: Import, Review, Approve, and Reporting. Those menu items forms the script of how to run a demo of this software.
The demonstrator would spend some time on the Import function. Describe some of the major features, talk about why it’s there and when you would use it.
Then the demonstrator would move onto the Review menu item. Again, they would discuss what Review is for, who would use it and what major features are there.
And so on until each of the menu items have been covered.
The “Menu” demo is a popular way to run a demo because it’s easy to remember – you simply follow the menu. Hence the name. The demonstrator is sure to cover all the major points because they’re included in the menu.
The problem with the “Menu” demo is that it’s “software-centric.” The menu items were created to resemble some broad workflow, but not necessarily from the user’s perspective.
And if the menu was created without the user’s workflow in mind, then this script is even more disconnected from what a real user would do with the software.
If your software is even moderately complex, a user will rarely use all the menu items in a single session. In fact, many of the menu items might not be used on a regular basis. If your software is designed for the enterprise, then a user might not even need many of the menu items; they have been designed for other user types.
Despite how you might view the workflow, the menu items will likely not represent how your customer actually uses the software. And because of this disconnect, although the “Menu” demo is informative, it’s rarely persuasive.
The “Feature Review” Demo
The “Feature Review” demo is like the “Menu” demo on steroids. The demonstrator goes through each and every feature, every box, every option to demonstrate the power of the software.
The idea is to overpower the the prospect with all the possibilities and they will want to license your software.
That result rarely occurs. In fact, unless such a demo is required by a Request for Proposal (RFP), you should never run a “Feature Review” demo. They are overwhelming and usually end up making your software look complex and unwieldy.
Just like the “Menu” demo, the “Feature Review” demo is “software-centric.” It’s all about your code and nothing about the customer. What the “Menu” demo tries to do is stick with the workflow embedded in the menu. The “Feature Review” leaves this intention behind, getting lost in functionality at the expense of actual function.
Most customer who watch a “Feature Review” demo end up impressed by the thought that has gone into each component, but often do not understand how the software actually works.
This “shock and awe” approach is not how to run a demo. You’ll find your prospects with more questions afterwards than they had before. And worse yet, they may be too confused to know what to ask.
The “Day in the Life” Demo
It turns out what your prospects want to know most is how they’ll use your software in their day-to-day work. You will want to think through how to run a demo that highlights the typical use cases your customer will go through.
The focus on use cases can be complex when you have enterprise software and multiple user types. That only emphasizes how important it is to structure demos around the audience.
Regardless of the different types of users, your demo needs to be “customer-centric.” It needs to focus on things your customer actually does. Build a script around what life actually looks like for your user – pre and post-implementation of your software.
The “Day in the Life” demo is a scenario-based demo. Start with a typical situation – ideally one your software makes easier. Set up the scenario verbally and then walk through the exact steps the user would take to handle that scenario.
Choose scenarios that are common rather than one-off “corner cases.” If you can include commentary about workflow that is happening outside the software, you’ll find your prospective user understanding better how your software will affect their work.
In the end, you’re shooting for dramatic changes in outcomes. You need to justify the return on investment in your software. And your demo should make it clear that the day-to-day work of the user will result in that ROI.
You will be tempted to “throw a few things” into the “Day in the Life” demo because your scenario doesn’t hit on some key features or functionality. Resist this urge. Your prospect will be won over by seeing how your software interfaces with their already existing workflow. Detours and breaks in the flow only serve to confuse the prospect. That disruption makes it less likely for them to see your software fitting “into their life.”
If you find your “Day in the Life” demos are missing key features and function, that should tell you something. Either you’re telling the wrong stories or your key features aren’t all that key.
If you adopt an agile development framework, some of these stories should already be a part of your internal language. You’re just showcasing them to your prospects now.
How to Run a Demo that Gets People to Buy
All the theory in the world isn’t helpful if you can’t visualize it in action. That’s true for your customers. And it’s true for you. To that end, here are some examples of outstanding demos you might use for some inspiration.
In the end, your goal is simple. More customers.
But to do that, your prospect needs to go on a journey with you. They need to see a relevant, valuable outcome. They need to recognize a problem with what they’re doing today. And they need to see you solving that problem.
These problems are a part of your customers’ daily life. The scenarios you describe in your software demo need to reflect those daily challenges.
Your potential customer will not be swayed by the latest feature or shiny object. Especially not when that new gadget doesn’t immediately address their pain points.