Onboarding is often introduced as a process of introducing a tool or service to someone. This is partially true, but I think onboarding is mostly about helping people new to your service achieve their (service-relevant) goals. This is the same approach good sales people use: they know that being at the service of customers will result in that customer buying.
Most onboarding today (circa 2018) takes one of two approaches, and both of these approaches aim at helping customers navigate their way around a product:
These approaches both (generally) fail to address the true problems the customer came to solve. Both have their place, such as announcing a new feature or demonstrating new navigation, but are rarely useful in showing value to brand new users who are trying to accomplish a few basic goals.
Onboarding approaches that work focus on solving the problems the of customers. At a practical-level, this means helping the customer experience core product value with your service early and oftenin their customer journey (see also: Brian Balfour on SaaS product growth).
Our company provides an on-call solution for ops, devops and development teams. This means that it monitors any number of external monitoring tools (like New Relic, Datadog, Icinga, and 100+ more) and alerts “on-call” users if their monitoring tools are sending out alerts. It additionally has a workflow function for those alerts (known in-aggregate as “incidents”), and 2-way chat integrations with tools like Slack.
We knew that our trial experience was poor compared to our competitors. This came not only from internal sources, but from trial abandonment feedback — people didn’t know what to do once they were in our app, didn’t know where to go, and wasn’t sure what to do next.
We mapped out our funnel to identify where users were falling off. Like many conversion funnels, it had several gaps both at the beginning of the trial and throughout the experience.
What we did know is that we were losing about 15% of our users before they ever got through the front door.
Once they did get in, about 20% would ultimately become a customer. This is actually an excellent paid conversion stat, but keep in mind that we had a well-staffed (and frankly amazing) sales and support team.
The best place to start when trying to fix a flow like this is to map out the flow, preferably some place public. It’s also helpful to map competitor registration and onboarding flows. This provides a visualization of the entire flow for the team, and make comparisons between the competitor approaches.
Another benefit of this approach is that the flow is visible to people outside of the product team. This is a great way to setup conversations with other teams in the company who work directly with customers. Making the work visible also spurs ad-hoc discussions with people you may not have considered in the research process.
Most product teams are focused on new feature development within an existing product and customers. This means that they primarily address shortcomings within the product to reduce problems for current customers, but don’t spend much time deeply explore why people buy their product in the first place. This is a genuine shame, because why someone buys (or doesn’t buy) your product can provide a wealth of data about their motivations.
We first gathered qualitative data by speaking separately with our sales team and support teams.
Sales works with customers on the front-end: they first get in touch with customers when they signup or request a demo, work with them through the trial process, and continue to keep in touch with them after they close the sale. Support/ops helps customers setup their account, integrate the their existing tools, and setup their schedule.
Sales and support/ops taught us not only why people bought our product, but likely factors for success, and where they stumbled along the way:
Sales and ops also mentioned that people had a number of “aha!” moments at a few specific points in their new trial experience:
We combined this with sales conversion data from our data team. This provided context for the qualitative data from sales and support:
Because our customers could potentially have a number of "jobs to be done" to be successful, we had to consider onboarding for a number of different paths AND a single path (if the person was responsible for all jobs-to-be-done).
One approach many desginers take when designing for personas is to have people self-identify with these roles and path them accordingly (e.g., "Are you a developer?" "Are you a manager"). This approach has shortcomings in that it may prevent someone who works across roles to complete these tasks.
For these reasons, we decided on an adaptive onboarding approach which allowed someone of the tasks (if they were working with a team) or all of them.
We focused on three major "a-ha" moments:
Decreasing the amount of work someone has to do to experience value chiefly means remove our extensive registration process. At the beginning of the project, it was a nine-step process from our home page to register and see the app for the first time. Once you were in the app, it still required you to perform a non-arbitrary amount of configuration just to get an alert via text message, with almost no assistance.
We began by removed the necessity for email verification, which could be completed later. We stripped out what unnecessary fields (like job title) and combined others (first name and last name) from the registration. This removed four steps from the process, and required no context switch to email.
We then focused on getting the customer moments of success sooner. After registration, the first thing the user must do is enter their phone number to send a test notification, which accomplishes three things:
We then ask them to invite their team. This is a common practice on many apps, although controversial because it might be presumptuous before they experienced the app. But our research showed that an overwhelming number of people tour the trial with their team, which may be confused of a few different roles. Given this information, the step to invite made sense.
From our research with sales and support, we learned that regardless of persona or role, the new users will want to see what a test alert looks like. This makes sense since alerts are a core part of their on-call experience. We toyed around with the idea of an “alert sandbox” where someone could fire a common type of alert and respond to it. We talked to sales and support about this, who mentioned that this might not capture the experience we expected: new customers were not just testing our system’s format of alerts, but how quickly they received it. They wanted to experience the round-trip of the alert from their monitoring system.
To accomplish the round-trip nature of alert testing, we presented a call-to-action with a curl command which would fire a test alert into our REST endpoint. Why a curl command? Because it allows us to simulate the round-trip nature of alerts without the messy wiring of their particular monitor tool. They can experience the round-trip nature of an alert by using their computer as an analogue for their alert system.
After receiving their first alert, there are a number of paths they might want to follow depending on their role. If they are an a technical user (such as on-call operators, devops, and developer), they might want to configure their integrations. If their job is that of a manager, they likely want to get their on-call staff on a schedule.
We also provide an intercom prompt with personal help for scheduling and integrations, the two important tasks within our app. This prompt includes a “getting started” link to our knowledge base if they want to do this without our help.
Lastly, we present a status bar at the top of the screen with a countdown to their trial expiring and associated buy and demo buttons. As the trial clock ticks down to a few days before the trial ends, our the demo calls to action changes to “extend trial”. This requires a phone call with sales, which benefits us because it reengages the customer in a direct way (if you join on a Hangout with a salesperson, you’re much more likely to convert).
The status bar also contains a progress indicator showing what they need to do next in the app to complete their trial. It shows whatever next step they need to take in the app, and provides a menu with all of the necessary steps to complete their setup.
Lifecycle emails are simply event-driven emails that are sent to prospects at specific points in their customer journey. The effect is that they can "re-engage" customers at specific points in the onboarding process. For apps which require configuration, lifecycle emails have a of provable track record for improving conversion rates..
We knew that ~40% never re-engaged with our platform off after 10 hours, so we sent a "Welcome" email from the CEO with an invitation to get help and provide feedback. Our Sales team also sent a manual follow-up for a demo within about 48 hours if they were considered a "qualified lead".
All of our messaging which required response were written in plaintext. We did this because the plaintext format results in much higher response rates than those HTML formatted.