5 Steps To Sell A Demo
As a SaaS seller are you going through other people’s demos? Are you taking notes on the parts you hate? On the parts you want to steal?
Most SaaS sellers aren’t buying a ton of products so you may not have experienced a truly great experience and if you have chances are they weren’t life changing. Most demos are boring as hell. Let’s face it. And until you invite your prospect into a story that includes them saving the day, your demos will be boring too.
Let’s talk about the five steps I use to sell on a demo call.
For an enterprise software, in an outbound scenario this is after an intro call and discovery call. In an inbound scenario it’s most likely after the discovery call.
Tailored & Tested
Many SaaS sellers are so excited about all the features that they offer that during the call they go over ever freaking feature and it’s just way too much information.
People aren’t actually interested in features per se, they are interested in solutions that the features can solve. When you go over every feature you’ll often hear the objection, “I don’t think I need all the bells and whistles”. That phrase, “bells and whistles” is short hand for a bunch of junk I don’t need.
You don’t want your features that your dev team worked really hard on to be treated like that. The old saying “don’t cast your pearls before swine” comes to mind. Since not every feature is important to your prospect, don’t show them everything.
This is why the discovery call is so important because it gives you the opportunity to do an intake to find out what really matters to the prospect. That way you can come prepare with a demonstration that matches their use case.
If your product can be templatized, do the work of building a template that best suits the needs of the company so that they can see it working for their use case from day one. You may even use a platform specialist in your company to act more as a demo engineer with the responsibility of tailoring demos for unique use cases.
This is why I schedule discovery calls before demos. I want a little bit of time in between to prepare the demo. It’s also important to test your demo like crazy before hand. Look, we’re all in software here. We know the truth. Software doesn’t always work perfectly. And when it doesn’t, it’s like there are little landmines waiting to be triggered when you’re on a sales call. You think something is working and then you end up on the call looking foolish because something isn’t working. If that’s happening, the unfortunate thing is that it’s really hard to salvage a sale once they think your product doesn’t work. But you and I know the truth. Every product is a forever work in progress and sometimes bugs slip through no matter how good QA is.
So test your demo over and over. Make sure it’s looking good and all the landmines are sniffed out before and do a small amount of custom configuration to let your prospect see it in action for their use case. Nothing more, nothing less.
Foreshadow the climactic scene
When I get on the call, I love casting vision with the prospect. Given the intro calls and discovery I should have a good idea about what they want and what their main problem is. I’ve already positioned myself as the guide and have laid out a plan of action. All of this has happened before the demo. Now that I’m in the demo I want to paint a picture of how good their life will be with the product in their hands.
I do this a couple of ways. One is to use a case study example, told verbally and about a time a customer (or even when I) had success using the product. I like talking about statistics like how one of our car dealer clients increased their lead to revenue conversions from 16% to 1 in 3 cars being booked and sold through the periodic system. Then I’ll ask a question like, what would your life look like if you could double your closing ratio?
It’s vital to understand that people just want to solve their problems and it takes a lot of mental gymnastics to imagine how your unique offer can solve their unique problem. You can make that easy to wrap their mind around when you paint a picture of what their life will look like when their problem is squashed.
Collaborate on Problem Solving
So many sellers and especially founders are so laser focused on what their product does that they have a hard time paying attention to the underlying problems that their customers have. They think strictly through a lens of how can I solve this problem only using my product and if it’s outside of scope then I don’t talk about it.
I understand why it’s scary to venture outside of your product offer but I’m not suggesting you toe the line of mission or scope creep. I’m suggesting you get good at advising what your customer needs to do in-house and what you can do to facilitate their success.
So much of sales is just facilitating success through a combination of efforts. Some of them yours, some of them theirs, and some of them third-party collaborators.
When you position yourself to collaborate instead of just being a presenter, you start actually solving problems. In this level of saas sales, they are relying on you to bring expertise to the table. They understand that you can’t do everything and realistically they don’t want you to do everything because they aren’t attempting to buy your company or put your team on payroll. They want to know what they can do to solve their problems and how you can amplify their efforts.
That takes ideation, whiteboard sessions, feasibility testing, pressure testing the market, mapping out implementation, and so on. But the research shows that when you invite people into a collaboration it doesn’t feel like being sold to, it feels like getting stuff done. And that feels good.
Requirements gathering
At this point you may be thinking, my gosh, this is taking entirely way too long but here is the reality. Large complex deals can take months to close and it’s not enough to present once and then put them in an email trickle campaign as an attempt to bug them into submission. If you’re making a 5 or 6 figure deal, you are going to have many points of contact to convince. Many opinions to take into account. And many objections to overcome.
So during that time it’s best to set up a cadence of engagement meetings like the collaboration meetings I mentioned above and use the time to uncover all of the requirements for the project.
Requirements include writing little use case stories for how each feature will be used. Stories have a beginning, middle, and end. The beginning introduces the problem, the middle introduces the plan of action, and the end foreshadows the resolution or in other words the ideal outcome.
Requirements include details regarding integration needs, custom design and features, and other technical requirements. All of these things are necessary to produce a proposal with an accurate assessment of work as well as a price that is value tailored to the prospect.
Writing the proposal is a part of process but it shouldn’t be the first time price is discussed. Move the topic of price up in the conversation by giving a range and anchor the ball park high enough so that when they are ready for the real proposal they are surprised by how doable the solution is.
The goal is to end up with an MVP
MVP, minimum viable product. Just like your dev team began with a minimum viable product for launching the application so to, you want to think of implementation as beginning with an MVP.
Here’s the deal, switching and implementation costs for companies is really high. There are a lot of things they have to figure out. How do they get old information into the new system? How do they go about training the new system with their team? How will their customers respond to the new process. How steep is the learning curve? How much time will it take to implement?
You have to remember that these companies are busy with huge agendas on their plate. They don’t want to spend a lot of resources on implementing a new software but they know they have to.
This is why starting with an MVP is so valuable. I know your product does a lot of amazing things. But be patient. Start with the smallest implementation that’s viable both from a profit stand point and an impact stand point and grow the integration from a basic starting point.
The bigger the implementation process the longer the customer will have to endure the product not actually making them money. So you have to get something implemented and providing a return as fast as possible.
Remember that the only reason a business spends money is to enable making money. So if the upfront investment is too great and the return is far in sight, it is your obligation to ask yourself whether you can speed up the process to get to profitability.
That’s why in this stage it’s smart to hone in the demo and get it as close to the point of release ready as possible. But be careful not to over commit your time to an MVP that may never launch.
To avoid the risk of never launching, you can do a couple of things. You can enter into a pre-agreement contract which obligates the customer to a small opt out fee if they decide not to move forward with the project. That’s a tough conversation to have but if you don’t have the resources to spend that much free time with a prospect it’s worth a shot. It also has them put some skin in the game. You can call this a pilot program or a guided trial.
Another tactic you can use with the guided trial is to cut the length of the guided trial according to deal size. The bigger the potential deal size the longer the guided trial, but the cutoff date is where rubber meets the rode. If they aren’t ready by that date, then you move on.
This process of collaborating on a demo that is ready to “drive” is really great when you have a complex product that does a lot of different things. It also kills two birds with one stone. Instead of just watching you go through a wrote demo which they could do on their own time with a video or better yet you put and an interactive demo on your site that they can play around with at any point; this gives them something that is tailored to their use case and it teaches them how to use it in the process. The only step after that is to sign the proposal.
Now Go and Practice
Alright! Here’s the deal. If you try this process once, you might fall flat on your face. Especially, if you are used to just going through every feature of your interface in the same way every time. It takes practice. You’re going to have to get comfortable with asking more questions and being prospect lead. You’re going to have to practice collaborating and not just talking at people.
So try it out with a colleague. Ask your mom. Just get the reps in.
Torlando Hakes, is the author of the book Sprint and host of such podcasts as The CTA Podcast, The PaintED Show, and No Trade Secrets. Torlando is open to meeting new friends and building a community of like-minded peers. You can jump on his calendar for a 1–1 anytime for advice, to share networks, for podcast interviews, and for help getting more bookings.
Design a site that books with Periodic.is and Webflow.
