Problem
Upon analyzing the data related to payroll onboarding conversion, it was observed that the conversion rate drops significantly at various stages. In particular, the "Add people" step in the onboarding funnel witnesses a drastic drop of -61.5% of users. This indicates a potential bottleneck in the payroll onboarding process that needs to be addressed to improve overall conversion rates.
Revolut payroll onboarding conversion funnel data
Research
Fortunately, a user feedback survey was already integrated into the product, providing a natural starting point to investigate why so many users were dropping out at that stage of the funnel. The survey results revealed a clear correlation between the funnel conversion data and the challenges that the majority of users reported facing at that particular stage.
Problems indentified by the user feedback survey
In addition, I analyzed the free-form responses provided by users in the feedback survey to gain a deeper understanding of the underlying reasons behind the observed drop-off in the onboarding funnel.
Organised table of survey responses left by the payroll users
Analysis
After analyzing the survey results, I synthesized the data to create a clear map of the issues mentioned by users. While some survey responses were unclear about the exact problem during the "adding employees" step, I was able to develop three potential hypotheses that could help to explain the underlying reasons for the observed drop-off.
Synthesis of the research presented as a problem tree
One hypothesis for why users were unable to add employees was that they lacked the necessary permissions during the onboarding process. However, this hypothesis was quickly disproven by data indicating that 96% of users who completed onboarding had the required permissions. For the other identified issues, I developed potential solutions.
Problem-opportunity tree
One of the identified problems with "add people" step was the fact that payroll employees needed to have Revolut Business (RB) accounts. In the current product version, users can only add employees if they have an existing RB account or invite their employees to RB. However, survey results and conversations with payroll clients revealed that this was a major point of friction for users.
Although the "add people" step was the primary focus of the project, the team believed it was valuable to address other user-reported issues, given that the solutions appeared to be relatively straightforward.
Revolut onboarding flow
Revolut's payroll user onboarding process is comprised of six steps. In the "Adding people" step, users can manually add employees or import an FPS file, which is an HMRC file containing essential employee information. The primary objective of this onboarding process is to help users set up their payroll system efficiently so that they can begin using it right after.
Overivew of the Revolut's payroll onboarding flow
Benchmarking
I was curious to understand the onboarding experiences of other major payroll products. As such, I analyzed the onboarding processes of these products, with particular emphasis on the "add people" step.
Payroll onboarding user flows for Quickbooks and Sage
Payroll onboarding user flows for Gusto and Xero
After conducting a brief analysis of our competitors, I found that the majority of payroll companies had very similar onboarding steps. However, none of them had the same requirements for adding employees as Revolut.
Solution
While there were various issues with the existing onboarding process, the focus of this case study is solely on addressing the problem of users being unwilling to invite employees to Revolut Business (RB).
To solve this problem, the project manager and I agreed that allowing users to add employees without requiring them to open an RB account would significantly improve the onboarding conversion funnel.
Alternative solution options
Alternative solutions to decouple Revolut Business accounts from payroll
After examining the issue of decoupling payroll employees from Revolut Business (RB) accounts, I identified several potential solutions. To evaluate each of these solutions, I have laid out the logic flows of each of the proposed solutions, conducted a pros and cons analysis and presented the three best options to a team consisting of a project manager, lead engineer, and payroll specialist.
Option A
This option focuses on delivering the objective with the minimal changes to the current flow.
- On the “manual” flow, start with the RB team members list but allow non RB employees to be added.
- On the FPS flow, allow unmatched employees to be added as a new employees (without the need to match them).
Positives
- Similar to how the current model works, hence minimal changes.
- Efficient for cases when admin only adds current RB team members to payroll.
Negatives
- FPS imported unmatched users “add as a new employee” can be confusing & inefficient (scalability).
Option B
- On the “manual” flow, start with the empty payroll employees
- Allow two ways to populate payroll employee list i.e. adding individually and/or inviting from RB team members
- FPS imported unmatched employees will not need to be resolved, they will be auto added as a “non RB employee”
Positives
- Could be re-used for adding people on the payroll product itself.
- Better approach in terms of UX and efficiency for importing FPS with many non-RB employees.
Negatives
- Slightly less efficient for adding RB team members.
- Might lead to more issues of creating employees that are already RB team members.
Option C
- Unite FPS and “manual” flow.
- Start with the payroll employees list (will be empty initially for onboarding).
- Allow three different methods of adding employees.
Positives
- Allows for maximum flexibility e.g. can add employees through different channels all together.
Negatives
- How common is the scenario for admins to add on top of their FPS employees?
- Mix of statuses VS limited edit options (i.e. inability to edit matched team members through FPS).
- Potential issues with duplication of FPS and RB employees.
After discussing the strengths and weaknesses of each proposed solution, we collectively agreed that option B was the most effective solution while also being feasible in terms of engineering effort.
Together with the team we agreed to proceed with the option B
High-Fidelity Designs
Overview of complete experience, with different edge cases covered
After gaining confidence in the proposed solution, I proceeded to work on the high-fidelity designs. Since Revolut's Design System is comprehensive, I often bypass the wireframing stage and move directly to high-fidelity designs, which is a more efficient approach.
Key Screens
Due to the decoupling, some profile status cells had to be updated
Results
Following the handoff, the developers worked on several sprints to build the proposed solution. The majority of the work focused on back-end changes as the logic side required the most alterations.
After launching the new onboarding process, we measured the results and observed a remarkable improvement in the conversion rate.
- Before the changes, the drop rate at the 'add people' step was -61.5%. However, after the implementation of the changes, it decreased to -34.5%, representing a significant improvement.
- Additionally, the overall onboarding conversion rate was only 15.6% before the changes, but it increased to 26.3% after the implementation.
TOverall, this project was a success, as it achieved its objective of decoupling while also addressing users' pain points with additional solutions. It is worth noting that while our current conversion rate is below the typical 30-50% range for similar onboarding products, the Revolut team is committed to continuously monitoring the payroll onboarding conversion rate and implementing further changes to improve it.
