Self-serve enterprise billing designed to protect paying campaigns.
The companion surface to organization management. Enterprises don't pay one card for everything—they budget per office, region, and campaign. Billing had to model that: pooled balances, billing groups, per-account caps, transfers, and a disbursement flow that turns one big commitment into a clear allocation—with spend legible from the org down to a single automation.
See business context
Read design system
Built with a PM and a Staff Designer; org-level payment actions designed closely with engineering.
Executive summary
Billing was the hardest surface in org management—money, permissions, and live automations colliding at once. I designed the flows: billing groups, payment access and caps, transfers and disbursement, in-flow access requests, and spend analytics—with engineering on the org-level payment actions. It reuses the org study's backbone: nested hierarchy, permission that inherits down, and no structural change without first showing what it breaks.
My roleDesigned the billing & spend flows; org-level payment actions built closely with engineering (with a PM and a Staff Designer)
OutcomeDesigned in-product caps, payment access, and disbursement so admins can manage money across the org with clear safeguards
ProcessAI used from the same Markdown specs as the design system
At a glance
Billing sat on 75% of revenue—so it had to be safe to hand over.
~75%of revenue in the 3 enterprise accounts this served
95live automations per account that a payment problem could interrupt
~$2Mpotential revenue from a prospect that named org billing as a requirement to join
~$158Koverspend across 3 incidents caps & budgets are built to prevent
14payment-issue tickets that halted live automations this year
1–3 days → minsfund transfers & balance purchases, designed for self-service (was a CS/eng ticket)
The problem
Billing sat on the money itself—3 enterprise accounts behind ~75% of revenue, each running 95 live automations that a payment issue could interrupt. It had already cost real money: 14 tickets this year were payment issues that halted automations, plus ~$158K in overspend across three incidents. A ~$2M prospect named org billing as a requirement to join.
What I did
Designed the billing & spend flows—billing groups, payment access & caps, transfers & disbursement, in-flow access requests, and spend analytics—on the org backbone: nested hierarchy, inherited permission, and no structural change without first showing what it breaks. With a PM, a Staff Designer, and engineering on the payment actions.
The outcome
Caps and budgets are designed to prevent repeat overspend. The shipped flow makes transfers and balance purchases self-serve in the product; the projected 1½- and 3-minute task times are click-level estimates to validate with live accounts. Org billing also addresses a stated prospect requirement.
Main UX
The whole money surface in one view.
Total org balance and enterprise volume commitment up top; each billing group shows its accounts, payment access, monthly caps, balances, and pending access requests—transfer and purchase inline.
Billing Management — the whole money surface in one view
The question that changed the project
Why does an enterprise have to email us—and wait 1–3 days—just to move their own money?
Billing looked like a payments screen. The more I studied the flow, the less that held up. The real problem was trust and permissions: how do you let a customer move real money across their own teams—without us in the loop, and without one payment slip pausing a live campaign?
So I reframed it. We weren't designing a place to pay. We were designing how an organization routes, caps, and protects money it's actively spending.
Expected vs. actual money-move journey
Expected
1
The org moves its own money
An enterprise should be able to shift budget between its own teams the moment it needs to—no ticket, no middleman.
2
Guardrails they set themselves
Admins cap what each account spends and route methods by function, so budgets hold without asking us to intervene.
3
Protect spend continuity
The model is designed to reduce the chance that a payment issue interrupts a live, paying campaign, while making its impact visible before a change is committed.
Reality
1
They email us to move money
Every transfer or balance purchase routed through Customer Success and engineering—high-level access on real money, by hand.
2
1–3 day turnaround
A support ticket, triage, a dev or director-level lead, then a wait—while the customer's budget sat where they didn't want it.
3
Overspend and stalls
With no self-serve guardrails, budgets blew—~$158K across three incidents—and 14 payment-issue tickets halted live automations this year.
Why billing was hardest
Money is where permissions, structure, and live campaigns all collide.
A template edit affects designs. A billing change affects money that's actively being spent. An enterprise pre-funds a volume commitment, splits it across billing groups, caps each account, and points specific automations at specific payment methods. Change any of that carelessly and a running campaign loses its funding and pauses—so the design had to make every consequence visible before an admin commits.
The other half was legibility: a CFO wants the whole org's spend; a regional admin should see only theirs. The same hierarchy and permission rules from org management do that work here—applied to dollars, not roles.
Discovery
The demand was specific—and it came from the accounts that carry the revenue.
The three enterprise clients behind roughly 75% of company revenue asked to manage their own org instead of routing every change through us—and a prospect we're pursuing (~$2M in potential revenue if it signs) named org billing as a requirement to join. Our PM and CS team ran the interviews; I worked from their findings, the logged requests, and support tickets.
- 13 Fund transfers between teams
- 2 Payment-method routing by function (automation, single order, mailing-list)
- 2 Aggregated payment history & receipts for the org
Logged from the three enterprise accounts—each request previously brokered by CS on a 1–3 day turnaround. Three of the four accounts (counting the incoming prospect) explicitly asked for billing aggregation.
Signal
What the data showed
Live automations that can't pause
The three enterprise accounts each run 95 active automations. A payment problem doesn't just annoy—it stops revenue. 14 support tickets this year were payment issues that halted some of those automations.
Overspend that already happened
With no way to set their own limits, budgets got blown—three times this year, ~$158K in unintended spend. Customers wanted guardrails as much as access.
The decision this forced
The two facts pulled opposite ways. The overspend argued for hard limits everywhere; the un-pausable automations argued against any cap that could halt a paying campaign. So caps stayed optional guardrails, not mandatory—the real protection is structural: multiple billing groups, each with multiple payment methods, so one declined card can't take down a campaign.
What that reframed: not just "let enterprises pay themselves," but "let them route, cap, and protect money so a payment issue can't stop a live campaign—and nobody overspends by accident."
The billing model
Pooled balance at the top, billing groups underneath, caps at the edge.
The org holds a total balance and, for enterprises, a monthly volume commitment. Admins create billing groups—often per campaign or region—nest groups inside them, attach one or more payment methods, and set how much each account can spend.
Two things kept deliberately separate: who spends (the org tree) and what pays (the funding source). An Account points to a Billing Account, so one funding source can serve many.
Who spends
OrganizationTotal balance · volume commitment
↓
Billing groupPer region / campaign · nestable
↓
AccountMonthly cap (≤ group budget)
funded by
→
one funds many
What pays
Billing AccountHolds payment methods & rules
↓
Payment methodsCard · bank · invoice
The model decision · the version I didn't build
Why a separate Billing Account—not payment methods bolted onto each team.
The obvious first model was a 1:1 binding: a team is its payment. Each Group or Team would carry its own cards, and money would live on the team—fast to build, so we considered it first. But it couldn't represent how enterprises actually pay, so I split funding into its own object.
Rejected vs. shipped
Rejected — payment on the team (1:1)
Payment methods sit directly on each Group or Team; the team and its money are the same object.
A team can pay only one way, and a funding source can't be shared across teams.
Finance can't separate who spent from what paid—so receipts and tax don't reconcile.
Shipped — a Billing Account as its own entity
A Billing Account holds the payment methods and rules; any number of org Accounts point to it.
Spending ("who") and funding ("what pays") become separate objects that reference each other.
One funding source can serve many accounts—and per-account limits draw against it.
One source, many accounts
A shared card or credit line is entered once on the Billing Account and reused, instead of re-adding it to every team.
Routing by function
Because payment is its own object, an Account chooses which method covers which work—one card for automations, another for single orders, another for a mailing list.
Reconciles for finance
Enterprises run different legal entities or banks by state. Anchoring money to the paying entity keeps history, receipts, and tax clean—and a change in one place updates every Account at once.
The extra object is worth it: at five levels of nesting, editing payment on every team is exactly where costly mistakes—and paused campaigns—come from. Separating funding from spending removes that whole class of failure.
Refinement
Every money action, self-serve.
Setting up a group, moving money, protecting a live campaign, reading spend—one billing surface, seen from different jobs. Filter by what you need to do, then click any screen to open it full-size.
Designing within real constraints
Where the platform pushed back, the interface pushed forward.
Money runs on systems with hard limits—Stripe, fund verification, settlement. Each pushback became a decision, with a visible trade-off and a path forward.
Question
Trade-off
Decision
Future
Should caps be mandatory?
Hard caps stop overspend but could halt a paying campaign.
Optional guardrails plus structural redundancy—multiple billing groups × multiple payment methods—so one declined card can't take down a live campaign.
AI-suggested caps from an account's past spend.
How do you change a payment method?
Stripe won't let a saved card's number be edited in place.
Make adding effortless; every "change" is really add a new method and repoint the automation—so the limit becomes a fast path, not a wall.
Broaden supported credential types.
When are new funds spendable?
Show funds instantly, but they aren't verified yet.
Balance and receipt show at once but sit in "Pending verification," unspendable until they clear—nobody spends money that isn't confirmed.
Clearer settlement-time estimates.
Is a commitment a balance?
One number is simpler but misleading.
Show the volume commitment and the spendable balance as two distinct figures, so "committed $100k" is never mistaken for "$100k I can spend right now."
—
Three principles run under all of it
Prevent, don't undo—money moves are effectively irreversible, so the UI shows every affected automation before a delete or transfer commits. Make invalid states impossible—a cap can't be set above its group's budget, with remaining balance shown live. Offer only what a role can do—money actions split into tabs by permission, so requests don't fail.
AI in the process
AI-READY SYSTEM
AI prototyped billing states from the shared Figma system—keeping drafts aligned with the product.
Billing has a lot of states—empty groups, capped accounts, pending requests, in-use methods, split allocations. The key move: AI drafted those states from the design system's own components and our shared Markdown (.md) specs—the same components and voice-and-tone docs behind the Figma system. So the states stayed aligned with that system instead of becoming one-off mocks. (These ran as HTML prototypes; the coded React version came later, on my own, after I was let go—that's the design-system case study.)
That freed the team for the flows that carried real risk—the money-moving and destructive ones. I'm usually the one bringing AI into the workflow—testing Figma Make, Codex, Claude's design tooling, and MCP, pushing them past production output into usability, research, and discovery, then documenting what works. On the org and billing surfaces I taught the approach to our Staff Designer and we learned it together; our Senior PM built three of his own prototypes from the same specs. Still a workflow we're refining.
Read the design system case study →component-specs.md
One source of truth
Components, tokens, and rules authored once in the Figma system—so every AI-drafted billing state used the real components, not a one-off mock that would drift from that source of truth.
validations-branches.md
States & logic
Relevancy checks, validations, conditional branches, and state flows—empty, capped, pending-verification, in-use, split allocation—drafted with AI from the same specs behind the design system.
ux-copy.md
First-draft copy
A machine-readable voice-and-tone reference produced first-draft UX copy for each billing state that already sounded like the product—so the AI passes stayed aligned with the Figma system.
The same system made accessibility a spec, not a cleanup.
A money screen is the worst place for an inaccessible control—and permission-and-spend screens are exactly where it gets skipped. Because the rules live in the design system, it was a constraint from the start; billing met WCAG 2.1 AA. (Ratios sampled from the shipped LettrLabs UI.)
Contrast
13.6:1 primary text AAA
16.1:1 nav on dark AAA
7.2:1 muted text AA
4.8:1 button label AA
Built in
Keyboard-operable
Visible focus
Never color alone
Errors tied to the field
Screen-reader checked
What changed · before & after
From a multi-day support path to an in-product money action.
The old paths ran through LettrLabs. admin panel and backend. The shipped model brings the same actions into the product; task-time estimates and adoption remain launch measures.
Money action
Before — email & wait
After — self-serve
01Transfer funds between teams
Email CS → triage → tag a dev or director → transfer in the internal panel → wait 1–3 days.
Blocked · 1–3 daysOpen the Org Admin Panel, pick billing group from → to, confirm.
Self-serve · ~1½ min02Purchase balance
Email the CTO / Director of Sales → discuss → Stripe link → pay → charges settle → available in 1–3 days.
Waiting · 1–3 daysManage Balance → Purchase Balance → pay by card, bank, or Stripe invoice; shows at once, spendable once verified.
Self-serve · ~3 min03Route payment by function
Ask us to point specific automations at a specific card—by hand, on the backend.
DependentPer-account method routing set in the billing group—one card for automations, another for orders.
In control04Protect a live campaign
A failed or removed card silently pauses the automations it funded—found out after the fact.
At riskDelete names the affected automations and gates on swap-or-pause first, behind a delete delay.
Protected05Reconcile spend
Request aggregated history and receipts through a support ticket.
ManualRoll-ups by team and type at any level, with exportable itemized receipts and invoices.
LegibleBacking the time claim
A rough keystroke-level (KLM) model of the shipped transfer flow—point, select the "from" group, select the "to" group, enter an amount, confirm—totals roughly 15–20 seconds of active interaction using the standard KLM operator times (Card, Moran & Newell, The Psychology of Human-Computer Interaction, 1983). Add the admin's own thinking—verifying the amount and double-checking balances—and the whole task lands around 1½ minutes end to end, versus a 1–3 day CS turnaround. (I enumerated the KLM operators with AI to sanity-check the cost before build.) It's a click-level estimate, not a stopwatch—actual completion times will be validated in Hotjar once enterprise accounts are live.
Outcome
A billing model designed for safer self-management.
The product outcome is a clearer in-product path for money moves on a revenue-critical surface. Adoption, completion time, and ticket reduction are the post-launch measures.
01 / SELF-SERVE · PROJECTED
Minutes, not days
The shipped flows put budgets, caps, transfers, and balance purchases in-product. The projected task model estimates transfers at ~1½ minutes and a purchase submission at ~3 minutes, versus 1–3 business-day CS requests (purchased funds then clear in 1–2 days). All three enterprise accounts are expected to self-manage billing at launch; the estimate needs validation with live accounts.
02 / REVENUE · PROJECTED
Built for the base—and on the next deal's must-have list
These flows serve the three accounts behind ~75% of revenue—and the prospect we're pursuing, ~$2M in potential revenue if it signs, named org billing as a requirement to join (three of four accounts explicitly asked for billing aggregation). A named requirement, not a nice-to-have.
03 / SAFETY
A pattern that protects revenue
Multiple billing groups and payment methods are designed to reduce single-payment-failure risk across the 95 live automations each account runs. Budgets and caps address the failure pattern behind 14 payment-issue tickets and ~$158K across three incidents; their impact is a post-launch measure.
04 / VISIBILITY
Spend leaders can trust
Roll-ups by team and type with exportable receipts and invoices gave finance one legible view—covering the aggregated payment-history requests that were part of the demand—instead of a support ticket.
05 / DESIGN SYSTEM
0 → 45 components, 3 md specs
The billing surface drew from a Figma design system taken from 0 to 45 components with 3 Markdown spec files—the same components and specs AI prototyped from—cutting roughly ~30% off design time (internal estimate) and keeping drafts aligned with the Figma system.
06 / SCALE
17 requests, addressed at the model level
The 17 logged self-management requests are addressed structurally rather than one by one—so the same billing model can support the 95 automations per account as the enterprise base grows.
Reflection
Billing is where I'd keep simplifying.
Billing carried the most states and the highest stakes, and it shows: some flows—disbursement, resolving affected automations before a delete—are powerful but still ask a lot of the admin. If I revisited it, I'd collapse the multi-step money moves into fewer, clearer decisions while keeping every consequence visible. The model underneath is the part I'd keep.
With more time, I'd let AI pre-suggest budgets and caps from an account's past spend, so setup starts from a sensible default instead of a blank field. I'd also push analytics deeper—surfacing budget vs. ROI so admins see where to allocate more, turning billing data into a business tool, not just a ledger.
"Anyone can draw a transfer dialog. The real work was the model underneath it—pooled money, scoped access, and safeguards designed to protect a paying campaign from avoidable funding interruptions."