Everything you need to know to drastically improve your SaaS onboarding completion rates It is the end of 2021 and I’m leading the Growth Team for a B2B2E company (E=employees) in an HRTech SaaS. We are deciding to tackle a well-known growth challenge — improving the product’s onboarding. Any growth PM runs into this challenge at some point or another so here’s what worked for us. This is how we were able to increase E2E completion rates by over 19% and at the same time improve data contribution significantly: TL;DR — here’s the formula: Test and improve copy. Use autosuggestions for form fields where you can. Make it configurable. Reduce clutter and unnecessary inputs. Think about measurements and critical data from the get-go. Optimization and testing. The underlying assumptions we worked with were: Our holy grail is activation, which is “apply” for an opportunity (we are a talent marketplace :) ). More on that in a future post. As a B2B2E, every feature in our product has two kinds of stakeholders — the end-users, and our clients. This is also true for the onboarding: We want our users to be activated, our clients want to get to know their employees better. These two goals aren’t the same, and there is a clear tradeoff to manage. Our design is constrained by our business’s strong selling points, and what sales had sold in the demo. This is not uncommon for B2B / B2B2E / B2B2C companies. Start with the end goal in mind: What are you optimizing for? Completion rates? Data contribution? Be specific. “We want to get as much data about users as we can” is not specific. Say you are working on an Insure-tech product, a good version would be more like: “Our model uses street address as one of the most important parameters and therefore it is key to get this data point during onboarding when users have high intent”. When it comes to completion rates — when we researched (and huge kudos to our designers Maayan Yudovitch and Omri Dvir for extensive research), we noticed a pattern — there is probably a pretty low correlation between the total number of screens/modals and completion rates. Remember this rule of thumb: it is not about the number of screens / steps, but about the friction in every one of those. reverse engineer the current onboarding to key data points. Takeaway: We took the existing onboarding experience and went through each one of the data fields and asked ourselves — does this info would lead to higher activation rates? How so? Result: We ended up cutting more than 30% of the original data inputs we’d had. 2. Copy and Localization . Since the onboarding is the first handshake a user would have with the product, it is all the more important to check whether your copy is in-line with best practices: You’d be surprised how far copy will go Users aren’t looking for features, they are looking for value. When finalizing copy ask yourselves — What’s in it for the user: what’s in it for them? Why would they care? Make sure that a language-picker, if you have one, comes first. If you go as far as letting users use their language — let them use it from the get-go. We hired a UX writer and redid the copy throughout. We asked ourselves Qs like: what is the average age of our users? How can we use the page’s title to create a hook? How can we cut # of words in half? Action: higher comprehension, higher completion rates. Results: 3. Configurability and Optimization When we wanted to A/B-test the old version for the onboarding we couldn’t since many things were hard-coded. This time we planned to build everything configurable such that we can test pretty much whatever we want going forward. This is a great piece about testing challenges you might want to check. we’ve done 2 things to prepare the ground for testing: Action: Dynamic infra — we built the infra to play with screen order. Simple JSON file and we can play with it. We listed our most desired tests and built with those in mind. Try to think in advance which tests you would want to run so you can inform your team and build accordingly. Pro-tip for PMs: Results: We can run any experiment we might want. Huge kudos here to Eitan Avgil, Netser Reuveni, Aviv Boaz, Liron Frieman, Gal Tubi and Nir Ben Yair!for thinking on this in advance and building the necessary infra. 4. Friction Minimization with autosuggestions A handy rule of thumb: The more demanding a data field is to fill in, the easier the fill-in pattern should be. We noticed that autocomplete works like magic. And it works for others as well. Users much prefer to click one time rather than type a couple of words — that’s not surprising, and nevertheless, if you read this article there’s a high chance that the product you are working on doesn’t leverage autosuggestions. This is probably the critical factor that led to more and higher-quality data. : Takeaway We collected within the first 72 hours more data than the entire year before. 5. Data and measurement This might sound obvious, but bear with me and you’d be surprised. The older version was built a while back, a couple of years ago, and the metrics didn’t change since then (we use internal KPIs, not rocket science at all, but the details are beside the point). It is super useful to think in advance about top metrics and key KPIs you’d want to measure so you can plan your events accordingly. This will allow you to have a war-room / launch room shortly after the launch (more on that in a future post ;) ). sit with your BI / Data Engineering and map events accordingly. That is often a step missed and it is too important to fall between the cracks. Huge thanks to Netser Reuveni here. Actions: : Results We measured key KPIs from day 1, with full flexibility to measure granular data points anywhere in the user flow. If this kind of content interests you, read more , and follow me . For product leadership content listen on here on Twitter https://www.productfm.com/ Good resources on onboarding and activaiton: Improve activation with those tips: https://userpilot.com/blog/improve-user-activation/ Also published here.
