A framework for creating a robust onboarding workflow

This post was originally published on the Wildbit blog.

Onboarding is a word that has been around for some time, but has seen increased usage in the world of SaaS in the last 10–15 years. Not surprisingly, this has corresponded with the advent and maturation of customer success as a discipline. And the two are related.

What is onboarding? It’s the process of getting someone up to speed so they can be as effective as possible and achieve success. And you usually want that to happen as quickly as possible. The term can refer to new hires for your own company (employee onboarding). But for most SaaS products, we use the term to describe the process of getting new customers acclimated to our service.

I’d like to share the framework for how we've created some of the onboarding campaigns here at Wildbit.

First things first

Before I talk about some of the activities involved in creating an onboarding campaign, I’d like to step back and talk about onboarding at a high level. There are a couple of important aspects to keep in mind.

First up is one of the most crucial aspects of customer success as a discipline. I hold to the idea that customer success is just that: a focus on the customer. That means I only want a customer to become engaged with our product because it makes their life better. And so I purposefully choose to work for companies where that is the case. I can feel good about helping someone be as engaged as possible with our products because we’re helping people solve real problems.

As Kathy Sierra puts it in Badass: Making Users Awesome:

People aren’t using the app because they like the app or they like you. They’re doing it because they like themselves. What are you doing to enable more of that?

Second, your onboarding is not the first step in guaranteeing the success of your customers. The fanciest, nicest looking, most clever onboarding campaigns cannot help people who do not need your product. If there is no problem that your customer is trying to solve or if your product focuses on the wrong problem, new customers are not going to stick around. Building a successful product starts with understanding your market and your ideal customer, having good marketing, and doing your best to find those people.

Once you have identified the right group of people to help, it’s important to remember that your onboarding should focus on them, not on you. Keep this in mind as you complete the activities below. You should focus on how your product helps the new customer solve their problem. The last thing we all want when we check out a new tool is to see a long list of features or messages that focus on the product or company behind it.

Last, it’s important to remember that anyone in your company can build these campaigns. The responsibility will fall on different shoulders at different companies, but the best onboarding examples are from companies who put the customer at the centre of their entire product development process. Designers, product managers, and customer success teams should all understand the vision of your product and the problem it solves well enough to guide someone new to a successful adoption.

Now, let’s dig into what’s involved.

The Framework

Now, there are many different ways to implement onboarding for a product. Different approaches will work better for some companies than others. I’ll discuss various options below, but remember that there is no one perfect way to do this. The best onboarding is flexible and iterative.

However, there are several exercises you can go through that will help you gain a better understanding of how to guide new customers to success.

Define your levels of engagement

The purpose here is create a tool that allows you to gauge how integrated your product is into someone’s business (again, we can feel good about this when we believe in the value we provide). Think of it in this sense: how hard would it be for someone to switch from your service to a competitor? The harder it is to switch would indicate a higher level of engagement with your product.

Let me illustrate with one of our products at Wildbit. Beanstalk is a development workflow platform where you can host, review, and deploy your code as a team. If someone signs up to Beanstalk, creates a new Git repository, then makes some commits and pushes them to Beanstalk, this would be a low level of engagement with our product. At this point, they could very easily sign up for a Bitbucket or GitHub account, switch the remote URL in their Git config, then push those same commits to their new remote repo in this other service.

But if they had pushed their commits to Beanstalk, then used our deployments feature to update their live website (instead of manually updating their site via FTP), suddenly they gained value they did not previously have. And it’s value they cannot get from some of our competitors. If using this feature becomes sticky and they then considered switching to a different service, they now have to replace the value they get from using ours. They are more engaged.

And that is what we want to outline here: it’s a tool for measuring how engaged people are with our service.

This is not a complicated process at all. Here’s how to create one:

list out the possible activities a user can perform with your product
group those activities into tiers (the number of tiers doesn’t really matter, but I keep it simple and stick to three)
each tier is a level of user engagement

You can then take these tiers and tie them into your user journey. I like to picture an ideal user journey, where someone goes from signup to highly engaged. I document what that journey might look like, and envision where the different activities would occur in that journey.

This does not need to be an precise measurement, but something that gives you a rough idea of how engaged your customers are. It should be flexible as the events themselves may change over time, being more or less important to your customers. But it should help you to identify your core features and what you want to focus on with your onboarding materials.

Identify your Wow moment

Once you have an idea of what an ideal user journey would look like for a highly engaged customer who is getting as much value from your product as possible, you want to identify the Wow moment. If you're familiar at all with onboarding, you may have heard of this term. There are a few other terms that get at the same idea (golden motion, day zero, MVE (minimum viable effort), TTFV (time to first value)). They are all focused on one thing: what is the quickest path to your customer’s success.

David Skok defines it this way:

Wow! is the moment in a free trial where your buyer suddenly sees the benefit they get from using your product, and says to themselves “Wow! This is great!”.

Whether your product has a free trial doesn’t matter. What matters is your new customer experiencing that moment when they realize that your product can make them better at what they do.

That is your Wow moment: when the new customer likes how your product makes them feel.

Now, it’s not always easy to identify where this moment takes place in your product. You may have to take a few guesses to find it. So you take your ideal user journey that you mapped to your levels of engagment, and you make another best guess: where is that Wow moment?

Again, I’ll use Beanstalk as an illustration. Commits are great, but deployments are where people realize the benefit of our product. All our longest tenured, biggest fans tell us that our deployments are what makes the difference when compared with other options they’d considered.

Pushing changes to a remote repo is a good first step, but as mentioned above, it’s easily replicable. But when an agency developer signs up for Beanstalk, then configures their workflow so that they can commit changes to their staging branch, push those changes to Beanstalk, then when those changes are automatically deployed to their staging environment and they can test seconds later …

That’s a Wow moment.

Map out the steps to Wow … in reverse

Once you have chosen a wow moment to guide people towards, start to identify the different steps required to get there. Take your ideal user journey you mapped out in step 1, then work backwards.

Lincoln Murphy describes it this way:

You create a plan to get here by identifying “initial success” and backing out from that goal while identifying success milestones along the way.

And don’t be afraid to go deep on this analysis. When you're very familiar with a process (like using your product), it’s easy to take things for granted. You will want to view your product from the perspective of someone seeing it for the very first time. Where you see 3 or 4 steps, someone unfamiliar with your product may see far more.

As Samuel Hulick points out in Mind the Gap, even the most simple processes involve more than we first think of. He uses the example of listing the steps to create a peanut butter & jelly sandwich (a seemingly simple procedure) . When his grade school teacher followed the instructions given by the students, the results were not as intended:

Our instructions created crappy sandwiches because they failed to bridge the gap between what seemed obvious to us and what actually happened in reality.

What seems obvious to you is not at all obvious to someone new to your product. And it’s important to remember that you're so familiar with your product that you may have trouble identifying all the steps involved with getting started using your product. As Hulick points out in his book The Elements of User Onboarding:

Ironically enough, your product’s first few impressions are SO make-or-break that you simply can’t afford to evaluate them as the expert that you now are — you have to try to forget everything you know and come in with a totally fresh perspective.

Beanstalk also provides a good example here. I mentioned above that getting started with Beanstalk involves making commits in a local repo, then pushing changes to the remote repo in Beanstalk. That sounds like a couple of simple steps. But for someone brand new to Git, it’s actually a complex process.

First, you have to log into Beanstalk and create a new repo. From there, you can open a command line interface (CLI) to take the next step (the words ‘command line’ are scary enough on their own for even some novice developers) with the following commands:

git clone https://accountname.git.beanstalkapp.com/gitreponame.git -o beanstalk
cd gitreponame
echo "This is my new project on Beanstalk." > README
git add README
git commit -m "My first commit."
git push beanstalk master

And this is just one way to get started. Our team has to be ready to support people in many different scenarios. And our onboarding has to do the same and get them started on the right foot.

Map out a list of touchpoints to get them there

Once you have identified your Wow moment and what you believe are the steps required for someone to experience that moment, you can start to create your onboarding materials. This is where there can be a wide variety in onboarding experiences. The type of content, the medium used, and the timing of messages can vary greatly from one product to the next. And that’s how it should be: different products have different audiences and different needs.

Let’s review some of the options.

Types of touchpoints

Email has long been the medium of choice for SaaS products sending onboarding messaging and information to new customers. But with the rise of the mobile web and modern browser technologies, in-app messages and SMS are popular as well.

What works best? It depends.

Context is the key for many messages you may want to send to a new customer. And in-app messages, when well designed, can be delivered at just the right time. However, when overused, they can distract the user from the job at hand and worse, annoy them.

Email is still a great option as it can deliver the required information, but allows the customer to process it at a time that suits them best. However, it’s vital to remember that most people in 2017 suffer from too much email. Your messages need to be well written in order to stand out (that’s an entire subject for its own blog post).

Touchpoint triggers

Another aspect of your touchpoints is how they are triggered. The two basic options are timing and behavioral.

Messages that are triggered by timing are the standard type that have been used for a long time. They are easy to set up and can deliver the basic information about your product that each new customer can benefit from. They may resemble a flow like this:

However, with the tools we have available today, it’s more valuable to build campaigns based on what you new customers do with your product (or do not do). These are behavioral (aka contextual) messages.

Again, using Beanstalk as an example, if a new customer has not pushed any commits to a repo in their account by 3 days after signing up, we send an email that is focused on helping them get to that point.

Over the past 12 months, this email has had a 43% open rate and, even better, a 12.5% conversion rate. There are so many examples in this category, it could also be a post all on its own. I will stick to pointing you to some great resources:

A solid onboarding campaign that provides real value to your customers will likely involve a combination of message types initiated by different triggers.

To get you started, we’ve provided a collection of resources for your use. It includes an onboarding checklist, a BPI & user journey template, a nurture path template, and some message samples. Enjoy!

There is a lot involved in setting up a robust onboarding workflow. However, it’s (obviously) worth your time and attention. The more people you can help achieve success earlier on, the better you’ll feel. And your business benefits.

Once you have something like the above in place, the next step is to validate and iterate.