Case 03
Billing platform
Billing ecosystem · Internal perspective
The project started as a request to replace one retiring billing form.
It ended as the foundation for a scalable Billing Center.
The original request looked like a straightforward migration. Research revealed the form represented only a small piece of a fragmented billing ecosystem.
01 — The Brief
They asked us to replace a form.
A legacy billing adjustment form was being retired.
The initial expectation was recreating it inside Salesforce Experience Cloud.
At first, this looked like a migration project.
Assumed path
Legacy Form
Salesforce Form
Is replacing the form actually solving the problem?
02 — The Discovery
The form wasn't the product.
Research uncovered a much larger ecosystem than the brief suggested.
The domain around the form
- Invoices
- Invoice Lines
- Billing Adjustments
- Documents
- Approval workflows
- Audit history
- Multiple user roles
- Multiple billing systems
Form
The form was only one entry point into that ecosystem.
03 — OOUX Before UI
We modeled the business before designing the interface.
Before discussing screens or navigation, we identified the structure of the billing domain.
- Core business objects
- Key relationships
- Shared actions
- Role perspectives
This object model became the foundation for every design decision that followed.
OOUX Matrix
Objects before screens.
A conceptual model of the billing domain — enough to show how we thought, without exposing internal product detail.
Selected object
Adjustment
A request to change what was billed — the spine of the first release.
Connects to
Invoice · Approval · Document · Account
Used by
Service · Operations · Leadership
Actions
Create · Submit · Review
Related objects
04 — Enterprise Constraints
Good enterprise design is shaped by constraints.
Instead of hiding project limitations, we treated them as design inputs — the forces that shaped what the Billing Center could become.
Salesforce Experience Cloud
- Existing component limitations
- Security model
- Navigation constraints
Timeline
- Aggressive delivery schedule
- Progressive delivery
- Prioritization
Integrations
- Multiple billing systems
- Existing APIs
- Different ownership teams
- Shared experience
Strategy
Progressive disclosure
Show only what the decision needs now — reveal detail when judgment requires it.
Identity and reason first
Invoice selection second
Line-level detail on demand
Approval context at the moment of judgment
Strategy
Data-loading architecture
We intentionally avoided loading unnecessary information up front to keep the experience performant.
Lazy load large invoice sets
Fetch line items when selected
Retrieve documents on open
Query approval rules when thresholds apply
The final design was the result of thoughtful trade-offs — not unlimited freedom.
05 — Designing a Platform
We stopped designing a form.We designed a Billing Center.
Information architecture
Before
Account
Billing Form
After
Billing Center
- Invoices
- Invoice Lines
- Adjustments
- Documents
- Approvals
Organizing billing around shared business objects created a structure capable of supporting future capabilities.
Before
Legacy adjustment form
Request details, invoice lines, approvals, and history — all on one scroll.
Improved
Billing Center — New adjustment
06 — Collaboration
Great enterprise products are designed together.
The project progressed smoothly because the work was shared — not because a single team carried the design alone.
- 01
Extensive documentation prepared by Product
- 02
Workshops with every business area
- 03
SMEs validating assumptions
- 04
Continuous UX reviews
- 05
Engineering collaboration
- 06
Frequent stakeholder feedback
Collaboration wasn't a process layer on top of the work. It was one of the reasons the work moved.
07 — Built for Growth
The first release solved one problem.The architecture solved many future ones.
Although the first release focused on Billing Adjustments, the platform was intentionally designed to support future billing capabilities.
The current direction of the product is expanding this same foundation to integrate additional billing systems.
Because of the architecture we established:
- Navigation remains consistent
- Permissions scale naturally
- Object relationships remain valid
- New modules can be added without redesigning the experience
Expansion roadmap
Billing Adjustments
Invoices
Documents
Approvals
Additional Billing Systems
Future Billing Services
08 — The Outcome
We shipped more than the original request.
The initial request was to preserve one workflow.
The final solution created the foundation for an expandable billing platform — a scalable architecture, not a rebuilt form.
Instead of asking
Where do we put the next feature?
Future teams could ask
Does this belong inside the Billing Center?
That's a fundamentally different product conversation.
Final Reflection
Enterprise design isn't about removing constraints.
It's about understanding the business deeply enough that those constraints become part of the architecture rather than compromises at the end.
The biggest success of this project wasn't replacing a form.
It was creating a foundation that future billing products can continue building on.