Canadian Basic Account

Bill.com International Expansion

Project Overview

Bill.com is an American business-to-business payment platform. It provides a platform for companies to pay and receive money electronically. This project aims to first expand the bill.com platform overseas for the first time, starting with the basic account that only receives payments.

Project Background

This one year project builds on the existing basic account product to cater to Canadian business needs when receiving payment from US payers.
My Role

I am working collaboratively with PM to fulfill business needs, with the risk & legal team to satisfy foreign legal requirements, with the dev team on various emerging needs during deployment.
Tools Used

Figma, remote user research, usability testing.
Design Challenge

Understand and design for a foreign marketplace.

Why are we building this?

Background on KPI

Bill.com monetizes its international payments in two ways: Charging a flat fee for US dollar (USD) payments and a percentage mark-up for its foreign currency payments. The foreign currency (FX) payment makes up roughly 25% of the international total payment volume (TPV) but accounts for 90% of the revenue. So naturally, the percentage of FX payment is a critical KPI when looking at the overall success of the international payment product.

In 2020, we launched a product that allows US payers to invite their foreign vendors to enter their bank information and the currency they like to receive. By doing so, we saw a significant increase in FX payment TPV (See below).

By launching this product, we learned two things: 1. We need to build stronger relationships with the foreign vendors as they will choose to receive their currency given a choice. 2. We need to find out why almost half of them still prefer to receive USD.

How will this project help our KPI

With the data from our previous project, we learned that bill.com needs to give the foreign vendor our platform to manage their receivable preferences. Bill.com currently has a basic account product (see below) that enables US-based vendors to send invoices and manage their receivable preferences. Therefore, it makes business sense to customize our existing product to serve foreign vendors.

Discovery

Find out who are we designing for

To understand who we are designing for, we decide to perform user research on Canadian vendors. We want to answer these two main questions: 1. what are the feature gaps that the current US basic account product has when serving Canadian vendors. 2. Why Canadian vendors choose to receive USD payments.

To determine who we should include, we took a closer look into our database. We found that even though half of the vendors choose to receive in their local currency. More businesses choose to receive USD compares to individuals.

We launched two rounds of user interviews. The first one helped us to find out Canadian vendors' receivable workflow. The second one looks specifically into why businesses lean towards USD funds, and here are the four key findings we found:

Ideation

Invoicing & follow ups

We heard from Canadian vendors that send, track, and follow up invoices with their US customers is challenging. They don't have visibility into when or if their invoice has been received or processed. Luckily, Bill.com domestic basic account already has a mature system allowing vendors to generate, send, track and reconcile invoices. We then decided for MVP just to add essential features like currency conversion to fill the feature gaps.

Multi-currency conversion

Learning for the research, we understand that Canadian business needs a capability to:
1. park their payment till a favorable exchange rate
2. partially convert their USD payment to CAD funds
3. paying out to their overseas vendors in USD
To satisfy these needs. We decided to build a balance feature where users' payments will go into their bill.com account instead of directly to their bank account.

Iteration

Multi-currency balance wiget

To place this multi-currency balance in our existing UI. We have identified that the dashboard is the best place. It is the landing page after the user logs in. After communicating with the team that owns the dashboard, we identified the style and location constraints for this feature (see below).  I started designing within the constraints provided.

For round 1 (see below), we put heavy visual emphasis on users' multi-currency balance and folded the current exchange rate into a link. During usability testing, users constantly ask us about what exchange rate it is using, giving us feedback on how they would like to see how the exchange rate is doing.

So for round 2 (see below), We down-level the multi-currency balance and up-level the exchange rate information. The historical data on the exchange rate to USD helps them determine if now is a good time to convert their funds.

Balance withdraw

After the users get paid, we hypothesized the most would like to withdraw their funds. For those who don't care for waiting on a favorable rate, we decide to build an auto-withdraw feature, so users don't need to log in to bill.com every time they get paid. For those who manage their balance more granularly. We need to give them all the options we could provide.

For round 1 (see above), we give users all the information and the control they need. We are showing the total amount they have equivalent in their currency and the balances in separate currencies. Where they want to withdraw from and how much. Because we allow converting USD to CAD but not the other way around, this withdrawal flow has a lot of complexity.

For round 2 (see above), we simplified the screens by breaking them into two steps. We then eliminated the complex dependency by forking the currency options early in the flow.

End-to-end design

This project is far more complex than these two workflows we dived in above(see below). There are the whole system of things we worked through: We have to redesign onboarding to fit the Canadian vendor mental model, Asking all business entities to upload their beneficial ownership information to comply with Canadian anti-money laundry law; communicate with the US payer on how this feature will benefit their vendors; create a new transaction history of the account balance and distinguish that from the existing records of payments, map out unhappy paths such as what happens when a withdraw fail, and what happens if that failed payment is on auto withdraw, FTU experience, etc., etc.

Impact

We have launched the MVP version of the Canadian basic account in June. Since then, we have received a lot of positive data indicating that it is moving our KPI on FX TPV as long as other key metrics. However, we also are seeing something that we need to continue research and develop.

What is doing good

Comparing to the existing US basic product, we see a similar adoption rate among the Canadian vendors. In terms of the TPV of FX payment. It exceeded our expectations, but this may not scale once this feature gains more audience.

What needs more attention

When we entered the Canadian market, we didn't know what to expect when we need to ask business entities their ownership information; now, less than half of them are providing the required information. This is a big gap we need to address soon. Another phenomenon we have observed is the amount cumulating in the user's balance. It is more significant than we anticipated, and we want to understand more after we have enough data to indicate any patterns.

Back to Home