Billing Platform Integration
Redesigning a billing system for global use
About Billing Platform Integration
oVice combines Voice, Video, Virtual, and Office into an integrated platform.
Born in Japan out of the need to communicate in a remote world, oVice grew to encompass a devoted following in Japan, Korea, and Vietnam. With over 2,300 companies and approximately 1 million users, oVice was able to connect work, education, community, and events together via the web.
Because of the multitude of regions using oVice, we were tasked with a billing re-architecture to help organize payments. We needed to think of a dashboard where all payments and currencies could be easily viewed by both our clients and internal teams.
Team: Product Designer (Self), Head of Design, 2 Product Owners, 3 Engineers
Timeline: July 2022- Aug 2022 (Initial Design), Sept 2022- Feb 2023 (Iterating & Rollout)
Tools: Figma, Trello, Notion, Linear, Asana, Miro, Stripe, Slack
An example of the different billing costs and styles cross the USA, Japan, and Korea, many which were manually managed by Customer Success team members
The Problem
While most competitors to oVice gave a single url “space” and required payment per user, the business model of oVice required that a client pay for the size and quantity of “spaces” needed, while allowing as many members into the space as the space could hold. Not only were there differences in size and quantity, but also billing frequency allowing Single Use, Weekly, Monthly, or Yearly payments.
With Japan hosting the majority of clients, the Customer Success Team were run ragged with keeping track of “traditional” payment methods- mailing invoices and handling payments via bank transfer. There was also a stress point of the payment sign up flow, with users wanting to be able to pay quickly and easily without emailing support for help.
Approximate JP Billings Count:
2,464 space owners paying via Bank Transfer
2,469 space owners paying for One Time Deals
263 space owners with reoccurring payments using Credit Card (Stripe)
356 space owners with free Sponsorship deals (Education Discount)
928 space owners in a two week free trial
The Goal
The goal of this billing implementation was to create a Billing Dashboard and improve payment flows for both for our Customer Success team and oVice users. We would start first with integrating the Stripe API into a payment pages for MVP, which would improve billing within Japan and USA clients. We would focus further on a separate billing payment (Toss) for Korea.
With this dashboard, we hoped to reduce the workload of our CS members manually tracking payments, ensure our deals and profits were correctly reported, and soothe friction from oVice users having trouble paying for their spaces or encountering errors.
-
Many companies in Japan are still very manual, and felt more comfortable with direct bank transfers or checks only. There was also the added difficulty of clients using up their “company budget” for the year at one time, creating off-cycle payment plans (eg: paying 14 months at once).
-
oVice had a few high priority clients who would be under one company umbrella, but have multiple divisions (1 Company, 30 Divisions). We needed to make sure each division would be able to pay with their separate division budgets.
-
A part of the draw for new users was the promotion of 2 weeks free. For users committed to oVice, they could receive a discount for the services when signing up for longer subscription lengths. We were also working with multiple universities to trial oVice, who were on specialized payment plans.
Questions to Keep in Mind
Discovery and Analysis
Competitive Study, Stakeholder, and User Interviews:
With translation help, we spoke with our three major customer success teams in Korea, Japan, and Global (English) to understand their pain points with the billing cycles in place. We learned that the workflows of each team was very different, as it depended on the client types. Japan dealt with some large corporations that kept traditional payment methods, Korea dealt with a few corporations, but many medium sized “Chaebol” (Family Group Enterprise) customers, while the Global team dealt with many very small startups who oftentimes tried to convert their preferred payments into Yen rather than US Dollars to save.
Keeping this information in mind, we looked at a few competitors and researched how other companies managed their payments in B2B SaaS, direct competitors, and B2C.
Competitive Study Sampling: Sign Up flow to Payment
Discovery
Insight Summary
The majority of applications we reviewed all have one main goal: get the user into the application as quickly as possible. The only application that had a lead gen early on was “Teamflow”. This is something we considered moving into the user flow and wireframe stage.
Of the eight apps, seven showed all available plans on a separate pricing page. The app will either put user into the flow of the selected plan, or default to a free plan and then prompt to upgrade.
Billing is usually on the same domain. Only one competitor offered invoice pricing (Spatial Chat). However, Spatial chat had a large JP presence in their user base.
Billing structure is more complicated, (pay per user per session/ reduced costs with more users/ pay per time frame) structure, except for Kumospace.
Majority of direct competitors had an easy “Free Plan” for users with groups under 5.
B2C combined sign up and plan payment into the same flow. Something we decided would not be relevant for oVice.
B2B SaaS programs try and make the upgrade/payment structure simple and straight forward, with Hotjar being the most difficult to comprehend.
Companies using a Stripe integration have a watermark on their checkout screen that stripe is being used.
A lot of applications that we looked at offer information on the plans page about payment history, billing date, etc.
“We have two different stripe accounts (JP) or (USA), so we need to create corresponding customers to those accounts in Stripe. We need to know as early as possible in user and company onboarding flow what currency they will pay in to determine which stripe account to use. ”
“To help our JP users, we can continue Invoicing, but moving consistently to Stripe for payment instead of Moneyford or Freee. At least we would not have to make invoice separately each month.”
Process
Analysis
“Due to limitations, we can’t switch a user’s currency once selected. Some global users choose to pay in Yen because it’s cheaper for conversion ”
Discovery: User Interviews, Stakeholder (US/JP/KR) Interviews, Competitive Study
Analyze: Competitive Analysis, User Flows, Feature Brainstorm, Product Requirements
Prototype: Med-Fi/ Hi-Fi Wireframes, UI Screens, Flow Prototype
Test: Feedback Review, Iteration (In Progress)
Internal Stakeholder Interview Quotes
After speaking to stakeholders and users, we did a mini brainstorm to help us differentiate from our need to haves for our MVP versus nice to haves. This helped us map out what we needed for our user flows. For Full Brainstorm, Click Here.
Feature Brainstorm
Current vs Proposed User Flows for New & Existing Users
With the feature brainstorm, stakeholder interviews, and competitor study research done, we moved on to creating user flows, marking out the Current versus Proposed flows.
There were multiple user cases we had to account for- new users signing up from our website, existing users with some that needed to merge over to become paying customers, and Invoice users that were manual and not clearly traceable in online steps.
Some main issues with the current flows were that there was no way to see that a trial had expired and a user had entered “freemium” mode, where their minutes and usage of their space was limited. This information was added to the backlog of UX improvement projects.
There was also no history of receipts or account payments kept on oVice, but rather just in manual e-mailing, causing great frustration when users were billed twice without noticing.
Our proposed flow brought in some important features, such as an easy to use dashboard, a quick overview of all spaces under a specific admin, the cost of each space, and helping a user understand what space size was right for their needs.
Wireframes to Prototypes
Medium Fidelity Wireframes
After collaborating with Marketing and Sales teams on the new plan styles (Free, Single Event, Recurring), we were able to move forward. Wireframes were presented to our PM, stakeholders, and engineers. Below show a sampling of how billing would look like when viewing the dashboard view, new subscribers, payment history, stripe integration, Invoicing through Stripe, and Modals to entice users to credit card payment.
Stripe Integration page with Card Payment
Sample Receipt of Order Summary
Subscription Confirmation Screen
Billing information of floors and pricing
Space Size Information Dropdown
Subscription of Organization Information
User Payment History
Modal to persuade users to move to CC
Hi-Fi Screens and Prototype
With some feedback on the Med-Fi Wireframes, we were able to move on to Hi-Fi screens, and put together a quick prototype to review with our stakeholders and CS team members. The below prototype walks through a user who has trialed oVice for free, and has decided to move forward with a subscription with multiple space sizes and “floors” in a building for their team. The user then inputs their credit card information along with a promo code to finalize payment, and can then see their payment invoice receipt along with a payment history on their history dashboard.
Prototype of Trial User deciding to move forward to paying for a space
Figma Components for Animation
Space Plan selection
Edit Space Size for Payments
One time Event Space Billing
Billing Method Update
Billing Frequency Modal
Invoice popup to change to CC
Stripe Integration Payment
Invoice Billing Dashboard
Updated Space Payment
Stripe Generated Receipt
Space subscription ending
Billing Dashboard Via CC
Challenges and Learning Points
Challenges and Learning Points
Although we had worked together to create a Product Requirement Doc, scope creep was a serious problem throughout this project. Trying to solve a complex billing problem across multiple languages, currencies, and platforms needed to be broken down into chunks to adhere to the agile methodology through iterations.
Because a design system was not yet clearly defined, oVice as a platform looked very different depending on where the user was from. We worked on a couple iterations to ensure we could encapsulate oVice as a whole that could work well with each piece of oVice (Japan, Korea, Vietnam, Global).
We started the release of the Billing Platform to “Free Plan” users to find any bugs or issues, and slowly rolled out to small teams. We will be soon rolling out the process to our enterprise customers. This will be the start of trying to persuade customers in Asia to transition to credit card, and we will monitor the process as it goes along.
Thanks for scrolling through!
