When it comes to increasing SaaS trial conversions, being able to experiment on the customer journey is key to getting your users to their "Aha!" moment.
There’s just one catch.
That experimentation usually requires involvement from your development team. And there’s the rub. How many times have you come up with an idea you want to implement and then the second thought you have is that you don’t have the developer resources to implement it?
This article will dive deep into how you can increase your SaaS trial conversions… without any developer involvement.
The Experiment Process
In a product-led growth approach, experimentation is the key to converting your customers.
Here’s a typical experimentation process:
- Track your customer journey in trial
- Establish baseline metrics and charts
- Identify friction points
- Hypothesize reasons for friction
- Design experiment
- Implement experiment
- View the test results of the experiment
- Choose the more successful version
- Rinse and repeat
But before you move forward with this experimentation process, take a breath and ask yourself whether there might be something that is holding you back from this approach. Here are some things to look out for:
- The bottleneck: There is one role in a startup that is constantly a bottleneck for forward movement. That’s the role of the software developer. It’s not because they’re bad at their job, but because they have way too much to do. There’s always a huge backlog of work to do for the developer. So, any new task that comes up needs to be reviewed in light of this backlog and prioritized accordingly.
- The business logic engulfment: In our efforts to move fast for startups, we’ve reverted back to engulfing our business logic into code. The irony is, in doing so we are actually slowing down the velocity of our startup because once again, we are relying on the developer to make any changes to our business rules.
- The analytics black hole: When it comes to analytics, it’s important to capture the full customer journey, and to the right level of granularity. The problem is, when people look at their analytics, they can’t see the forest for the trees. At the other end of the spectrum, I’m often amazed when I work with clients at just how little they’re tracking. They may have some broad strokes data like signups, but then it’s a vacuum of information when it comes to what people are and are not doing in their SaaS. Both of these scenarios can amount to the same problem: paralysis. Paralysis from too much data, from not enough data. And what’s more, most companies don’t leverage that data to give them insights into their customers or to tailor a personalized action to move their customer along the journey.
We all know the saying.
The definition of insanity is doing the same thing and expecting a different result.
So we need to break our current patterns.
Those three problems are some of the core issues that amount to your experimentation process not being a success within the timeframe you need it to be.
And if you can’t experiment or even implement the changes you think will move the needle, then you’ll stay in this insanity loop.
So how can we break these patterns to deploy our experimentation process? By following these two steps:
- Use the Customer Journey Optimization Toolkit
- Leverage the moment of Initial Value
1. Use the Customer Journey Optimization Toolkit
The one underlying principle of Customer Journey Optimization is empowering your non-technical team members to move fast and iterate without developer involvement. In so doing, your team members feel unencumbered when experimenting and iterating on their funnel initiatives.
The Customer Journey Optimization (CJO) toolkit helps you to reduce the cost of acquiring and retaining a customer. It removes business logic from code and puts it back in the hands of the people that make decisions about it.
The CJO methodology comprises of these 5 key components:
- The Customer Funnel
- Fit for Purpose Tools
- The Complete View of the Customer
Let’s break these down.
First, let’s look at the key principles
Principle 1: Connect fit-for-purpose tools together, integrated by Segment, a Customer Data Platform (CDP).
The key to CJO is being able to choose the best and most suitable tools for your business. The less attractive alternative is to choose one of those monolith applications that claim to do everything but don’t do anything very well.
So if we want to use the best of breed tools AND create a complete view of the customer in each of these tools, we need a mechanism to syndicate that customer data between all of these tools.
Principle 2: Customer data and actions should be available to all tools.
Principle 3: Components should be easily replaceable. For example, if you use Help Scout as your Help Desk software, it should be easily replaced by Zendesk without involving a developer.
Principle 4: Business rules should be changeable by the business, and not live in code.
Principle 5: Experiment and iterate with content. Those in-app walkthroughs, pop-ups, and tooltips won’t be right on day one. Instead of using developer-dependent, custom-built software to implement these, use off-the-shelf products that enable you to make changes easily.
Principle 6: Don't distract the developer. Developers should be focused on building the core product, not on converting customers.
Principle 7: Experiment with pricing plans. Pricing won’t be right on day one. It's going to evolve as your product does.
These principles help guide you through every other component of the CJO toolkit.
Now let’s look at the rest of the toolkit:
As you can see above, the tools you choose play a crucial role in liberating you from the developer backlog. They allow you to move fast and experiment without any developer involvement and help you track and activate the customer journey.
The Complete View of the Customer
So what do we mean by a complete view of the customer?
Every interaction we have with the customer, every interaction the systems we use have with the customer, and all the relevant attributes of a customer, make up this complete view of a customer.
These interactions and attributes have a number of sources:
- Your application is one source.
- Another source is your marketing automation tools. They'll send email events like sent, opened and clicked.
- Your in product activation tools will send you what onboarding flows the customer is presented and interacts with.
- And many more other tools will send various events.
Segment (or any other CDP you choose) will enable this data to be sent to all the other tools that are receiving customer data and events.
Each of those tools knows how to consume the information and bring it into their view of the customer or user.
The Customer Funnel
Our customer funnel is an 8-stage funnel that applies to any SaaS business. Its power is that it provides a framework and a common vocabulary for discussing what needs to be done.
Each of these stages has a goal and a set of tools and playbooks we can apply to them.
Each stage has specific goals, along with a set of tools and playbooks you can apply to them:
- Discovery : Get the user to discover your product.
- Familiarity: Get the user to sign up for a trial or purchase.
- Trial : Get the user to convert to a paying customer.
- Support : Educate the user and respond to questions and issues.
- Purchase : Support subscription & payment.
- Upsell: Encourage greater spend.
- Retain : Retain the customer longer.
- Refer : Get new customers from current customers and partners.
In this post, we're focusing on the trial phase and how to get the user to convert to a paying customer.
The final piece in our puzzle is playbooks.
Playbooks bring together all of the other pieces in our CJO toolkit together: the tools, principles, complete view of the customer, and the customer funnel.
A playbook maps out the interactions and events and how these pieces of information flow between tools and trigger various actions.
For the trial phase, we have these playbooks:
- Trial Sign Up Playbook
- Initial Value Playbook
- Trial Extension and Expiry Playbook
- Activation Playbook
- Land and Expand Playbook
Most of these playbooks, in ordinary circumstances, are usually implemented using one technique: software development.
But that was when you only had one tool in your toolbox.
The CJO methodology is about giving you more tools in your toolbox than what you have right now.
The tool you currently have is your developer, but we need to reframe our thinking next time we want to implement something.
Is code the best and only way to implement it?
To move to a place where you can move faster to implement your initiatives, we need to use other tools so we don’t have to wait on the developer backlog.
Let’s look at the Trial Sign Up Playbook as an example. The purpose of this Playbook is to get users to verify their email addresses so you can add them to an onboarding email drip campaign.
Example: The Trial Sign Up Playbook
It looks relatively simple from a diagram perspective, but its power lies in the ability to glean the right information for what's happening in your product and to own the email communications that are going out to experiment and iterate on them.
For example, when this task is executed entirely by a software developer through a tool like SendGrid, users click on that email, and then a single email is sent through SendGrid to welcome them to your app.
But what happens if users don’t verify their email?
If the developer hasn’t set it up correctly, no follow-up reminder email is triggered and you’ve just lost a customer.
But with a playbook, you become more aware of the marketing automation tools you’re using.
For example, by sending the user signup track event through Segment and into your marketing automation tool, you can add them to a multi-email drip campaign that continues to send the verification email, along with variations on that email until they do actually click on the link and verify their email address. You can test out different subject lines and email treatments if you choose as well.
In this playbook, you're sending two key track events to your analytics tool, which means you can capture where users are dropping off.
2. Leverage the moment of Initial Value
Next, we’re going to dive into a trial concept that plays a key role in converting free trial users into paying customers: Initial Value.
The point where your customers experience some value that relates to your product is called the Initial Value–or First Strike.
Different companies define different Initial Values:
- For Asana, it’s creating a new project with tasks successfully assigned to a team member.
- For Zoom, it can mean signing up, organizing, and holding the first Zoom conference.
- For Expensify, it is creating the first expense report approved for payment.
Getting users to this Initial Value requires these three key factors:
Curiosity : When users first sign up for a product, they have the curiosity to move through the onboarding process to reach the Initial Value.
Preconception : They come to the product with a preconception about the value they think the product provides, based on the marketing messages they've seen.
Problem : The users have a relevant problem they need to solve by using your SaaS tool.
All three of these factors need to align so your customers will reach the goal of Initial Value.
For example, if users have curiosity and a preconception, but no problem to solve, they'll walk away without adding their payment details.
If they have a problem and a preconception, but their curiosity runs out before they get to the Initial Value, they won't be a converting customer.
If they have a problem and are curious, but your solution fails to match their preconception of what your product does, you'll lose their trust.
When you're crafting your onboarding process, you need to keep all of these factors in mind.
So how can you go about getting users to experience this moment without the need for developer assistance? Let’s look at these three elements:
- The Initial Value ladder
- Value Gap
- Bump Events
1.The Initial Value Ladder
The steps that move from curiosity to the moment of Initial Value are called the Initial Value ladder.
This ladder has two key components :
- The curiosity component
- The setup component
In the curiosity step, your user will be clicking around and will be looking to validate their preconception about whether your tool can solve their problem.
They haven’t yet decided to commit to setting up your tool for their needs.
In a B2B environment, we often have multi-user SaaS products. The first user from the account is called “first user” and then other users from the same account are called “subsequent users” or “invited users.” Their onboarding journeys are often different, and that usually means that the subsequent users don’t have a setup component to their trial experience.
One thing you should consider is that because the subsequent user often doesn’t view the landing page marketing copy, you’ll need to introduce them to the product benefits from within the product and in your automation messages.
And when you set up your onboarding experience, you absolutely need to tailor the experience differently between these two roles.
Also, what you’ll notice from this diagram is that different SaaS tools can take different approaches to get the user to their "Aha!" moment.
If it’s the kind of tool that requires a lot of setup, then in order to extend the user’s curiosity period, you may need to leverage demo data to illustrate what they can achieve with your tool.
Amplitude, an analytics tool, does a great job of this by providing access to a lot of the charts they have set up using a B2B SaaS product called TeamChat.
Because the setup is non-trivial and it takes a considerable amount of time to get a volume of data established to create good charts, they use a demo to satisfy this curiosity factor.
So a user considering whether Amplitude is right for them will have satisfied their curiosity about what is possible. They will still need to figure out whether they are able to easily use the tool.
Other, more simple tools don’t require any demo data and can swing straight into setup mode.
So think about which path your tool takes and whether you can get your users to Initial Value before their curiosity runs out. If your tool takes a lot of time to setup, then you may want to switch to populating demo data on signup so you can extend their curiosity runway.
2. Value Gap
The value gap is the discrepancy between what a customer expects from the product and the value received in reality.
It can happen for many reasons, but here are some of the big ones:
- The product fails to provide adequate value.
- The prospect is the wrong fit for the product.
- The prospect doesn't understand the product's capabilities or how to use it.
- The prospect experiences something jarring or painful like confusion or dissatisfaction that changes their perception while using the product.
To bridge this value gap, you have to make changes to the product. But that's usually a rather long life cycle. So that’s why we use Bump Events.
3. Bump Events
There are two types of bumpers:
- Conversational bumpers
- Product bumpers
Any event that is triggered from these bumpers is considered a Bump Event. And you don't need a developer to implement them. More on this below.
Case Study: Trackbot
To show this in action, we’re going to look at the business Trackbot.
Trackbot generates test users and simulates your customer journey for those users into tools like Segment, allowing you to run test simulations in your analytics and marketing tools.
These are the key events within Trackbot that get users to the moment of Initial Value:
- Users sign up and update at least one event type that's been populated for them by default.
- They click on the "Start Generating" button, which performs validation on their configuration.
- If all is okay, the generation is triggered to be initiated, and that starts generating events for them.
To push the prospect back on course to achieve the Initial Value, Trackbot has these bump events:
- The checklist tutorial to get them started.
- Email link clicked, as part of the email nurture sequence.
- User pilot experience started.
All of these bump events use tools that can be managed by non-technical resources, which means they can be done without developer involvement.
To recap, developers are busy focusing on the product and rarely have time to help with experiments. The key is to integrate all of the data, choose the correct tools and create playbooks so you can implement experiments yourself.