The "Request a demo" process on your website

A few weeks ago I witnessed a controversy: the world of video games is changing the business model from the traditional model of "buying a video game", based on a single payment, to a "subscription" model, based on recurring payments.

However, this trend had already been noticeable in professional software (and also, for a long time now, in video games with significant online development), where the Software as a Service (SaaS) concept is the most common form of commercialization of these applications.

For example, a few years ago it was normal to have your billing program installed on your computer, while now, that program is in the cloud, accessible from any device and anywhere in the world.

If you are a company that markets applications under the SaaS model and offer demos to your potential customers, this is of interest to you.

Attract customers to your SaaS from your website

Most companies that offer SaaS subscriptions use two ways to attract customers to their application from their website:

• Free trial
• Product demo

or a combination of both.

Free trials are usually limited in time, and if they are not, then they will be limited in functionality.

It is very common for companies that offer both possibilities to prioritize the free trial over the demo, as a faster way to get a registered user and not simply a lead.

But in this case we are going to refer to product demos, a topic that is closely related to another one I have already discussed: landing pages.

Why do I like demos?

Although, when I need to evaluate a SaaS for my work I usually use both, on certain occasions I prefer demos to free trials, especially if the SaaS has a certain complexity.

A demo is usually a more or less standardized tour of the main features of an application, in which a person serves as a guide. And that's where the difference is made. Let's say that no two needs are the same and the fact of attending a demo guided by a person offers me several advantages.

On the one hand, it allows me to get to know the application in an orderly way because, when I use free trials, it is often not so easy to understand how it works, even with the documentation. On the other hand, it allows me to ask certain questions that are specific to my requirements and to better assess the usefulness of the application for my specific case.

The process of requesting a demo on the website

Normally, a process of scheduling a demo starts with a "click to action" (CTA), a button with a "Request a demo" type message that will appear in different parts of the website.

This button redirects to a landing page that usually contains a text and a form. Once the form is filled in and submitted, the user is directed to a schedule page, where a set of dates and times for the demo are proposed. Finally, once these details have been selected, the meeting is confirmed and there is usually a redirect to a confirmation or thank you page.

In some cases, the agenda page is displayed before the landing page containing the form.

In this process some emails will be generated: at least one for the person who has scheduled the demo and one for the person who has to perform the demo.

Most common errors in web development in relation to this process

Let's take a look at three of the most common errors that occur on websites that offer demos of their applications.

Unsuitable CTA

In some websites we find CTAs that are not appropriate, either because they are not obvious (this usually happens in sites that prefer to offer a free trial rather than a demo) or because the message is not clear.

On ActiveCampaign's website we clearly see that they prefer to direct their visitors to the free trial (1) rather than to request a demo (2).

Deliverect is a company that offers a SaaS dedicated to food delivery. The CTA, although well visible, contains a text that says "Get Started" and that is the one that leads to the Request a demo page. Most users will understand that Get Started refers more to a free trial or subscription to the service than to schedule a demo.

Forms with excessive data request

The landing page to which the user is taken after interacting with the CTA will contain a form. Obviously, the more data you obtain from a user, the better you can prepare a demo and even customize certain parts of it.

However, the more data you ask for in a form, the fewer submissions you are going to get. As we mentioned in the article on landing pages, you should only ask for data that is strictly necessary to manage the demo request.

The same will be true for the day and time selection form. Air360

You also have to consider that many users may visit the website from a mobile device, a device from which it is more difficult to fill out a complex form.

Lack of relevant information to decide if or when I want a demo

In many cases we find that the landing page used to capture user data lacks relevant information about the demo. Thus, we find that the duration of the demo, the program to be followed or the benefits of the demo are not fixed.

This OneTrust demo request landing page does not offer any information that would help me decide whether or not it is worth scheduling the meeting.

In this other case, the date and time selection form appears before the landing page, but neither landing page offers any information about the demo.

Some success factors for successful scheduling of demos

We have already seen some of the most common failures in the process of requesting a demo. Now we will see some best practices to optimize this procedure.

Know your potential audience: Not all people, even those interested in your product or service, are willing to attend a demo. Focus your efforts on analyzing the characteristics and needs of those who are and define the whole procedure, including the staging during the demo, oriented to satisfy their demands.

Maintain consistency throughout the entire procedure and be clear in your messages: There is a gulf between a CTA that says "Start now" and one that says "Request a demo". On the other hand, it is important to tell the user where they are in the procedure and how many steps are left to finish. And, of course, keep those signs of identity that give homogeneity to the process.

Reduce the number of form fields: During a demo it is very easy to get information about a visitor through direct, person-to-person questions. Therefore, it is not necessary to collect excessive information in the demo request form, which will increase the submission rate.

Provide relevant information regarding the demo: A demo requires dedication on the part of the user and, consequently, before scheduling it, he/she should have an idea of whether attending the demo will be useful to him/her. Consequently, a brief text explaining what the demo consists of and what the benefits of attending it are, will facilitate the decision to request it. Likewise, knowing how long the demo lasts is very important to establish the best date and time.

Support your argumentation with testimonials: If you already have relevant clients, include their testimonials or, at least, their logos, as part of the argumentation mentioned in the previous point.

Use personalization or ABM (Account Based Marketing) techniques to generate personalized messages: Nowadays it is possible to conditionally vary the contents of a landing page depending on the person who visits it, in order to empathize more easily and quickly with that person. This can be very useful to personalize all phases of the process.

Conclusions

Many websites that market applications under Software as a Service (SaaS) models offer the possibility of requesting a demo as a step prior to contracting.

The procedure to schedule a demo is complex and requires several steps. These steps must be carefully designed, always taking into account the profile and characteristics of the potential customer.

Making use of good practices, many of them based simply on common sense, can lead to a higher number of demo requests and a higher likelihood of converting prospects into customers.