Most of the Pleo product was built for use on web. But more and more we wanted employees to use the mobile app for their day-to-day usage. We were sending mixed messages as you could only create your account on web.

We wanted to start employees off on the right foot, and help them to get the most value from Pleo. We were concerned with three main metrics. App downloads within 30 days of creating an account, adoption of core expense features (like per diems in Pleo), and the number of customer service tickets in the first 30 days.

We broke the project down into a few important chunks of work. This included: getting employees into the app, being able to fully create an account fully in-app, setup fundamental features, guided discovery and contextual discovery.

Given this piece of work was a completely new part of the product — we decided to focus on getting employees into the app, and being able to fully create an account in-app. Setting up the foundations. We wanted a solid functioning onboarding flow in place before we layered features or optimisations on top.

This meant initially we wouldn't diverge too far from the existing steps we have for onboarding on web.

Pleo is a business-to-business product. So for the context of this work — a business has signed up to use Pleo, but the next step is for the company to get their employees using Pleo and setup to make expenses. The journey starts with the company admin sending an email invite to their employees.

We came up against some challenges getting people from the invite email to downloading the app to continuing their signup process. At the point of accepting their invite the majority of people don't have the Pleo app installed.

Recent security changes in iOS 14 meant we couldn't store the details of the person signing up whilst they went to the app store to download the app. So when people arrived in the Pleo app we couldn't tell who they were, and that they came from an invite email.

This wasn't a problem with web onboarding — but we still believed onboarding entirely in-app was worth the tradeoff of an additional verification step. I worked closely with the product manager and engineering team to come up with a flow that was smooth, secure and also satisfied the recent requirements for strong customer authentication (SCA).

After a few iterations and releases we got to a well-performing baseline. The foundation was in place so we could gather valuable data, optimise the journey, and start to introduce other core features to the journey.