Great SaaS Sales Demos

Sales demos for Software as a Service (SaaS) products are vital to introducing your product to customers and gaining their interest or desire to use your product. The typical way that a SaaS product is demonstrated, especially in this day and age of remote work, is by presenting the application remotely, showing off features and highlighting use cases for the potential customer. A good demo can show the customer that your product is a good fit for them, but it can also do the opposite: a demonstration might reveal problems, shortcomings, or gaps that your SaaS product has that your customer might pick up on.

As a DevOps engineer, I’ve received and viewed many demonstrations for a wide variety of products over many years. I’ve never had to present a sales demonstration myself (at least, not directly), but I have had to do setup and perform internal demonstrations, and I’ve also had to participate in designing or configuring SaaS product demonstrations. There are two SaaS demonstrations that I’ve participated in that were so memorable, they always come to mind even years later and after hundreds of demonstrations I’ve witnessed. The first demonstration was an unmitigated disaster and the second was one of the best that I ever witnessed thus far. Both of these examples lead to the 3 ways that you can make your SaaS sales demo the best it can possibly be.

The Bad Example

One of the worst examples of a SaaS sales demo disaster happened quite a long time ago when a SaaS company was in the middle of releasing a new version of their software. They were also going public and the combination of these two events was a source of great fanfare in the industry and at the SaaS company. The company I worked for had tested the previous version of the product—let’s say the “1.0” product—and we were prospecting to get a very good deal on a one year implementation. The new “2.0” product was being released and our company was one of the customers that would be a “logo” used to promote how well the product worked and that was trusted by our brand.

The problem was that internally, many of us engineers and even some of the leadership, agreed that the product wasn’t very good. We were excited to try out the new version but were a bit skeptical the product would be vastly different than the 1.0 product. In our view, the product was large, bloated, unstable, and crashed often. In preparation for the big 2.0 sales demonstration, I sat across from an executive at the SaaS company and listed a long laundry list of issues that I considered important to be fixed in the new product. The executive (who turned out to be the SaaS provider’s CTO!!!) agreed with me completely and reassured me that “all of the issues” had been resolved in the new version.

The large conference room lights dimmed and in a standing-room-only hush, the product demonstration started and was displayed on the projection screen. It was obvious the product was slow: noticeably slower than even the original. It also crashed almost immediately. The sales person started the demonstration again with a smooth cover-up. I remember the mood was still forgiving because it had crashed so suddenly and so quickly, nobody had really invested too much time yet. The sales demo started again and the product was slightly better. However, I could tell from the tics and movements on the screen that the sales person was purposely avoiding certain features and buttons that I personally knew were problematic in the old version. I knew he was avoiding them because they were likely to be buggy or cause issues.

Despite such careful choreography, the product crashed yet again, in fact, it crashed numerous times to the point where the demonstration simply couldn’t continue. The executives from the SaaS company who were there to personally oversee the demonstration were flabbergasted. I personally heard one of the sales engineers speaking in hushed tones into his cell phone telling his operations folks to try to reboot the demo server, again.

These are a sample of the types of excuses we were offered:

• “Oh, the new version hasn’t been deployed yet, this is a pre-release demo.”
• “You know, the dataset is wrong, we need to load more data.”
• “The internet connection is really laggy and we have a production network environment for the real product.”
• “The demo server isn’t ready for production yet, we’ve been upgrading our systems as fast as we can.”
• “We haven’t fully tested this new feature, and it wasn’t supposed to appear in this demonstration. Sorry.”

But eventually the truth was that the sales demo itself had failed. This had almost nothing to do with the product in actual practice, but that didn’t matter. The demonstration was unable to satisfactorily show what the product could do.

The Good Example

On the opposite side of the spectrum, one of the best sales SaaS demos I witnessed was nearly perfect and stood out how great the process was. The SaaS product was a monitoring tool that provided metrics and log events for a running application, and would be used to drill down and into metrics, events, logs, and so forth. This demonstration occurred many years ago and does not reflect on any present companies or products you may think of. I just want to clarify this so that you do not form an impression of any existing company or product today.

The SaaS salesperson ran the demonstration by logging into the actual live product with a special demonstration credential, and showed real, live data that were flowing from a fake application that was written specifically for the demonstration. It ran on a ten-minute cycle of generating pre-created events, metrics, logs, and so forth. The salesperson was able to look at “real,” “live,” and updated data as events happened in the application. Because the data were pregenerated and ran continuously, it seemed like the product worked perfectly and would do exactly what the salesperson seemed to make so easy.

There was one flaw that I spotted and confirmed but it was relatively minor. This flaw does demonstrate one of the key points I will discuss later on for a successful SaaS demonstration. The salesperson was unable to change or update any of the data or the layout of the screen. They were unable to demonstrate the ability to create and edit reports for the product. They were using what was essentially a “read-only” demonstration of the product and could not change anything inside the account. The reason for this is to perfectly preserve the demonstration process so that the next time the product is reviewed, it would be exactly the way it was before without any possible changes.

Based on these examples, I will now detail the 3 most important ways to pull off a perfect SaaS sales demonstration.

Game Changer 1: Provide a “Real” Experience

Your SaaS demonstration must be as “real” as possible. I use the word “real” in scare quotes because often you cannot provide any actual “real” customer data since the prospects aren’t customers yet. Even if you do have some customer data or can use actual real data of some sort, the customers are not interacting in any real way with the product yet, so let’s just use the scare quotes. Never-the-less, the data that you use in the sales demonstration needs to be realistic enough to provide a valid reflection of what your product can do and what the customer needs, in a way that the product actually works.

There is no other way to perform this than to use your actual live product in its actual live state. There are a lot of excuses and corners you will want to cut around this issue, but believe me when I tell you that this is critical. You must use your actual product in its actual state to perform the SaaS demonstration. When a customer test drives a car at the dealership, they are driving a real car that can be sold, not a fake or reproduction or toy model. You must do the same with your SaaS product.

You will need a stable, performant, fully functional, and fully capable product that functions exactly the way it will function when the customer logs in and starts using the product. It must function perfectly the first time, the second time, and the nth time you demonstrate your product. It must not conflict with someone else when two salespeople perform a demonstration at the same time, and it must not have any leftover or incorrect settings from a previous demonstration. It also must be stable and not be updated or rebooted or crash because of normal operations of the live site.

This is where a Release sales demonstration environment comes into play. A salesperson or organization that uses Release would have an environment setup and ready to deploy at a moment’s notice with pre-populated data, user accounts, and features fixed to a particular time or branch set. A few minutes before the demonstration, the salesperson would simply start a new, completely isolated and perfectly preserved application stack and dataset, ready to fully demonstrate the full, live, exact duplicate SaaS product to the customer. There is no chance for shared environments to conflict; the demonstrations can be tailored to each customer industry or feature set (if applicable); and there is no possibility of having incorrect settings or data present that can disrupt the demonstration.

Because the scale of the application can be set for one person or only one small subset of a customer, the application can be tuned to perform perfectly and for very little cost compared to the production environment. As soon as the demonstration is finished, the environment can be destroyed so that any hosting costs stop immediately.

Game Changer 2: Provide a Live Experience

Notice I did not use scare quotes in this section for the word “live.” The demonstration experience can be faked to some extent in terms of pre-populated data or accounts, but it cannot be faked in terms of actual functionality. You cannot just show a static video of your product demonstration and expect customers to buy into it. The potential customers must be able to intervene, interject, ask “what if,” or (even better) take over the controls and “see what happens.”

I already can hear some objections from salespeople who say that when an application is truly live then it is subject to unknown influences and problems. This is true, except that if you have a product experience that is well-tested and fixed in place at a particular time and version, then the demonstration can be well-rehearsed and practiced. This is directly at odds with the usual organization's push to release new features and update the product regularly. How is it possible to be able to have completely stable, well-populated, isolated environments at the same time that the development cycle needs to be fast, regularly spaced, and turn quickly?

This is where Release sales demonstration environments come into play. An application template can be set to a stable version or branch that is well-tested and cleaned for use to show to customers. It will be prepopulated with well-known, well-tested data. When a salesperson or sales organization is ready to show off new features or product enhancements, those features can be versioned and configured for use either as a separate application or as an existing branch of the Release application so that it can be spun up on demand for a customer. Once the branch and application template are tested, that version can be used by anyone in the sales organization to demonstrate the new features or product experiences and data.

In this scenario, it doesn’t matter if the production application is running on version 0.9 or 1.1 or even 2.0, the sales demonstration environment can be configured to run exactly the same version 1.0 every single time it is deployed and demonstrated to potential customers. Also, it could be devastating if the product version were to change in the middle of the demonstration or during the customer demonstration time period. Conversely, if the production environment is running on a delayed version and a customer wants to see the new features, the new sales environments can be configured and tested for potential preview customers to give early feedback, advice, or to gain other valuable information.

In fact, all of these scenarios could be in play at any one time: some sales environments could be set behind on an extremely stable, well-tested product experience while some sales environments can be spun up on demand at exactly the same version of the production experience, while yet other environments can be ahead of production to showcase new features and product experiences. The sales person or organization could pick and choose which scenario they would like to demonstrate and create the new environment tailored to their exact requirements and customer profile.

Each environment would be isolated and stable without any contention or changes interfering.

Game Changer 3: Provide a Malleable, Persistent Experience—Which Can be Recreated

Even in the best SaaS sales demonstrations I have experienced, there was always a critical and nagging worry I had that the environment was not going to persist and that anything that I was working on or being demonstrated would not last for long after the demo. Strangely, the reverse is true as well: oftentimes the customer might want to revert all their changes back to a pristine state after “messing around” with things. How can you resolve this tension between two extremes?

This is where Release sales demonstration environments come into play. The salesperson or organization can spin up entire environments for one or more customers and allow the customer(s) to “play” with the product without any fear of damaging or impacting anything else. If the customer wants to start over, a new environment could be created, or the exact same environment could be duplicated to start over. In fact, the salesperson could construct several accounts for the customer to use if that is appropriate, or if multiple employees or departments could be interacting with each other or the demonstration. All of this can happen in such a way that the isolated environment can be snapshot or ported to production once everything is set up the way it should be. Alternatively, the snapshot could be ported to a new sales demonstration environment for a “reset.”

Even better, in some cases, the new sales demonstration environment could become a staging or testing environment for the customer to use indefinitely or on-demand when they need to test possible scenarios or possibilities. All of this can occur without any impact or conflicts with the live production product. In a few rare cases, the SaaS product could become so customized to an industry vertical or customer that it may become a standalone environment live in production for use by that customer or industry.

This brings up a great point about environments at Release: they are all identical in design and spirit, and can be used for any and for all purposes. A software engineer’s local development idea can become a testing ground for product development, which can easily be deployed for a sales demonstration, which could easily become a live production environment running live paying customers. With Release, your environments are not limited by even the sky above or the ground below!

Photo by Carlos Esteves on Unsplash