Billing Profiles: Simplifying complex multi-entity payments
Year
2025
Role
Lead Product Designer
Type
Product Design
Company
TLDR;
Core challenge
Our legacy billing system relied on a rigid 1:1 model with one card per account, which failed to support enterprise customers needing to split costs across departments and regions. We migrated to a platform that unlocked multi-entity payments, but its data model exposed raw backend mechanics directly to users. Our challenge was to hide this technical complexity and give customers an intuitive way to manage who pays and where invoices go.
Solution
Designed and launched Billing Profiles to simplify cross-regional billing, giving organisations full control to set up payment methods, assign entities, and route payments seamlessly.
Impact
Stood up the feature from 0-1
Designed and launched the complete billing profiles experience from initial concept to full rollout across the console.
High enterprise adoption
Over 60% of multi-team accounts set up two or more distinct billing profiles within the first two months of release.
Reduced the complexity around Billing
Replaced exposed ledger IDs and technical jargon with clear, intuitive labels.
Console’s billing system didn’t reflect
how enterprise customers are structured
Console Connect’s mid-to-large enterprise customers often have multiple teams with different billing needs.
They needed to pay for services across legal entities, regional cost centres and currencies, using different payment methods. However, Console Connect’s billing system only supported one legal entity, contact and payment method per organisation.
This made onboarding, purchasing and invoice reconciliation more difficult. Some customers had to use third-party software to manage their billing, adding complexity to the process.
Problem Statement
Enterprise customers didn’t have the infrastructure in Console Connect’s portal to effectively manage their billing needs, preventing them from self-serving and in some cases, from onboarding to the platform at all.
For complex or ambiguous projects I start with a brief for myself. It makes me say what I know, what I don’t, and what success looks like.
Brief.md
View Brief
I've created my own skill that allows me to map context in Figma appropriately. This creates the following outline for doc and asks be appropriate questions at the right time.
We understood the problem,
but not the motivations of the customer
We didn't have enough information on the customer, so leveraging the relationship our UXR Dave had built with Presales, I decided to run interviews across our user segment using BDMs & proxy users via Lyssna.
Research Question
What is the customer experience of Console Connect users regarding the credit assessment process, payment methods, and management of different cost centres when using the platform?
Insights
Synthesising these data points through thematic and semantic mapping, we realised there's 4 key insights that we needed to keep front of mind.
Global companies bill to local legal entities for tax, currency, geopolitical, or governance reasons
Business units and regional offices often need to purchase and be billed independently
Invoices frequently go to the wrong person because the platform doesn't prompt for a dedicated billing contact
Customers strongly prefer a single invoice across services; multiple invoices increase admin overhead and make reconciliation harder
Downstream consequences
Some large customers cannot onboard at all because multi-entity billing isn't supported.
BDMs manually manage billing changes that should be self-service.
Invoices sent to the wrong contact cause missed payments and support escalations.
The credit assessment process is slow and opaque, creating a barrier at the point customers are ready to buy.
Insight
"The customer finally decided to buy something. He's ready to go... They've got two ports, it's $1000 a month. If they don't pay us for three months, it's not a big deal." — BDM
How do other companies,
solve this issue?
Desktop research
Enterprise customers expect a parent account with nested sub-accounts or cost centres, as seen in Microsoft, Equinix, and IBM — Console Connect's flat single-entity model doesn't support this.
Billing on IBM and Megaport is access role-controlled; network engineers placing orders shouldn't have the same authority as finance to change billing entities or payment terms.
Platforms like Azure and Stripe set the expectation that the payment processor is identified on card forms as a trust signal.
Enterprise participants require a PO number field on invoices before payment can be processed internally.
Customers expect billing to live in a central account dashboard, not scattered across product pages — and for portal access to precede the invoice email, not follow it.
Following my brief I mapped the problem, outcome, assumptions, questions and constraints directly to my brief template.
From there I create OSTs and roughly estimate solutions, assumptions and HMWs. In this case I worked directly with the Product Owner/SME to map these out.
When designing our solution we always had our constraints top of mind.
Now we understood,
it was time to test our solutions
The outcome of this work was the billing profiles feature — a self-service billing management experience built to support the needs identified through research.
Working with a remote team & managing feedback
We managed feedback with the global team through async workshops. During these workshops we asked developers, SMEs and Product Owners to comment on specific parts of the new journey.
Engineering & external pushback
Throughout this process, a key concern was the friction in the credit card onboarding experience. With 60+ customers already on credit card, and Finance having recently agreed to a $5k spend threshold before credit assessment is required, a significant volume of new customers were expected to onboard via credit card when billing profiles launched. The experience needed to support that at scale.
Usability testing
We managed feedback with the global team through async workshops. During these workshops we asked developers, SMEs and Product Owners to comment on specific parts of the new journey.
