Helping SMBs get paid across borders, and grow their businesses
Challenge: help business customers get paid to their existing account details, with as little friction as possible, so they can shift more high-value, one-off payments to Wise and save money.
Solution: a Request Money feature, that helps businesses get paid by sharing account details in context. Wise generates a unique URL which contains all the information payers need to make a local / international bank transfer. The feature was implemented across platforms - iOS, Android and Web - with silent launch to new customers in October 2021.
____________________________________________________________
Year: 2021
My role: Senior Product Designer
My contribution: problem definition, POC flows; user testing and synthesis; high-fidelity prototypes; MVP documentation and QA.
Team: Helin Akgül, Engineering Lead; Andrei Tognolo, Technical Lead; Antal Monori, Joseph Newman and Christie Davis, Snr Software Engineers (Android, Web and iOS); Ivan Marinkovic, Design Lead; Thi Pham, Snr Product Analyst; Sasha Povarov, Product Manager.
Product Director: James Bell
Request Money is a new Wise feature that enables businesses to request payments in multiple currencies - to be paid into their balances - by sharing their account details. These details allow users to bill “domestically” in another region. There are two sides to this experience:
1) The requestor / receiver creates a request with amount, invoice, optional due date or message. Wise generates a request link, which users can share via email or messaging app. The requestor can manage created requests within their account.
2) The payer receives the request link, with all the information they need to make a bank transfer.
Businesses account for a large percentage of Wise’s cross-currency volume. Amongst the biggest opportunities, we wanted to better solve the jobs of “getting paid”, and extend beyond provision of account details, as the method for receiving payments.
Our audience are SMBs: most of our businesses are small-scale companies or sole traders, who still invoice their clients manually. The value we could bring was dependent on how businesses are run (i.e. larger businesses already use robust invoicing tools that are fully automated), but for small businesses, who have strong relationships with their payers, these tools feel impersonal.
Prior research: quantitative and qualitative data suggested that we could make receiving money to bank details easier for customers. From customer interviews, bank transfer was the most common method used. “Better invoicing” was the number three new feature request for businesses, and 58% of surveyed customers said they’d find an invoicing tool very useful.
Our JTBD for businesses was: “Getting my invoices paid within the payment terms agreed upfront and on time”. Our design question was: how might we help businesses get paid to their account with as little friction as possible, so they can shift more high-value, one-off payments to Wise, and save money?
The end-customer we focused on were payers of high-value, one-off payments, because these were the ones costing more fees for our businesses; as opposed to customers with high conversion and low costs (e.g. e-commerce platforms) which don’t usually use bank transfers as payment method.
We already offer integrations with services like Xero, which handle things like invoicing, and we didn’t intend to become a full invoicing tool. Wise wanted to become the bridge between businesses and payers, a tool that provides control over their communications with customers, and enables businesses to receive money - at lower costs - directly into their multi-currency account.
The flow presented in this case-study is the final version that we took into development, after several rounds of user testing with both requestors & payers, and MVP scoping. Our initial release didn’t tackle the full E2E request experience (i.e. providing status updates, chasing payments / sending reminders) due to technical constraints and added complexity. Instead, we focused on solving for the first and second milestones in the journey, to validate the feature and learn from usage.
Through user feedback we learned that requestors don’t usually know their payer’s setup (which account they’ll use to make the payment), so we provide both sets of account details (for payments inside and outside a given country).
During testing we also corroborated the importance of trust: sharing a link that is descriptive enough (verbally and visually) to convey legitimacy; and the need to make it as easy and efficient as possible to create a request, while retaining a personal touch.
Increased receiving capabilities come with additional complexities, such as risk management. For this MVP, we deliberately left a few aspects out of the experience such as:
1) Merchant branding and verification, due to increased impersonation risk. 2) Entry point from “contacts” (solving for this involves restructuring the recipients’ area and overall IA. 3) Checkout experience (a substantially more complex model than requesting money to bank details, requiring collaboration with a different team within the Receive tribe). 4) Managing functionality, which is limited (users can see a list of ‘active’ vs ‘expired’ requests, access each link or cancel requests; but not receive status updates or send reminders due to limitations related to linking a request with a specific payment accurately).
Amongst other parallel tasks, I designed and proposed a new component to our Design System’s team: the file upload input below. The existing in-product component wasn’t well suited for a mobile form nor optimised for consistent cross-platform integration.
This work not only helped us ship the Request Money flow faster, but also served other teams such as Dynamic Forms, with multiple product journeys across the Wise app.
Payers receive a request link (i.e. via email or private message) directly from the Business. The URL is a web page containing the payment information. In order to make the bank transfer, end-users need to open their banking platform and use the details provided.
For this MVP we don’t allow a signup or “login-to-pay” option, due to the added friction (for non-Wise users, creating an account to pay would entail a verification flow). For Wise users, the payment method would be the existing peer-to-peer send money flow - via email / phone number, which isn’t tailored for businesses. Nevertheless, users can pay using the Wise app, as they would with any other transfer.
Our KPIs were: a) 15% of customers (Q3 cohort of newly signed up businesses) receiving money to account details, adopt Request Money; b) Reduce 50% of time from first account details allocation to first payment on international bank transfers (versus existing customers); c) Achieve 20% long-term adoption for established customers, upon rollout.
We wanted to equality track health metrics such as: reducing the number of CS contacts (difficulty of using bank details), customer feedback / NPS, and monthly retention rate.
Impact:
• Within a month of silent beta, we saw ~2,000 users per day setting up requests, and were able to track 250-300 successful requests / day across borders.
• Request Money proved to be successful when solving customer needs, and data analytics provided us with invaluable insights that validated the international use-case.
• Following the MVP for businesses, the feature was streamlined for personal customers and officially released across the Wise app.
Our long-term goal is to close the loop in the request lifecycle for monitoring and status (e.g. paid / overdue notifications); facilitate integration with invoice management capabilities; and allow for branded, fully customised requests.