Enterprise Billing

Billing was the hardest surface in org management. Money, permissions, and live automations all collided in one place. I designed the money-movement and spend flows: transfers and balance purchases, adding and removing payment methods, payment access and caps, in-flow access requests, and spend analytics. Our Staff Designer designed manage billing group and disbursement. Engineering worked with me on the org-level payment actions. It reuses the backbone from the org study, which is nested hierarchy, permission that inherits down, and no structural change without first showing what it breaks.

Total org balance and enterprise volume commitment sit up top. Each billing group shows its accounts, payment access, monthly caps, balances, and pending access requests. Transfer and purchase happen inline.

Discovery

Data

Tickets

Journey

Process

Money is where permissions collide

The demand was specific

Money flow: pooled balance

The org holds a total balance and, for enterprises, a monthly volume commitment. Admins create billing groups, often one per campaign or region, then nest groups inside them, attach one or more payment methods, and set how much each account can spend.

Product Strategy

Strategy: why a separate Billing Account

The obvious first model was a 1:1 binding where a team is its payment. Each Group or Team would carry its own cards and money would live on the team. It was fast to build, so we looked at it first. But it couldn't represent how enterprises actually pay, so I split funding out into its own object.

Features

Setting up a group, moving money, protecting a live campaign, reading spend. It's one billing surface seen from different jobs. Filter by what you need to do, then click any screen to open it full-size.

Set up Move money Protect Spend & receipts

Set up Billing groups, access & caps Grant an account the pooled group balance or a specific card, then set a monthly cap it can't exceed. Payments, Admins, Budgets, and Settings split into tabs by permission. Set up Assign group admins Choose who manages a billing group, meaning accounts, methods, invoices, and settings, so approvals route to the right level instead of back to us. Set up Per-account budgets Each account gets a Monthly Cap or No Limit, shown live against remaining balance, so an invalid cap above budget is impossible to set. Set up Route payment by function At the account level, each automation points to its own payment method. One card for automations, another for single orders, shown next to balance, total spent, and monthly cap. Move money Transfer between teams Move balance from one billing group or account to another, with a live Transfer Preview that reconciles both new balances before you confirm. 13 of the 17 logged requests were fund transfers. Move money Split a commitment Turn one big volume commitment into a clear allocation: charge-from / disburse-to, per-method sliders, and one-tap split-evenly, with live percentages so the total always reconciles. Move money Purchase balance Order more balance by card, bank, or Stripe invoice. A receipt is emailed and charges settle in 1 to 2 days, so added funds sit in Pending verification, unspendable until they clear. Move money Migrate an account Move an account to another group in guided steps: destination, automation routing, then per-method monthly limits. The move waits on the destination admins' approval. Protect Delete a method in use A method funding live automations can't just be removed. The dialog names every automation that depends on it and gates the delete behind swap-or-pause plus a delete delay. Prevent, don't undo. Protect In-flow access requests A team with no method requests access in-product, and an admin approves or rejects. No side-channel email, and a clear audit of who granted what. Spend & receipts Spend analytics Where the money's going, answered at org, group, or campaign level: spend rolled up by team and by type, with the same permission rule applied to dollars. Spend & receipts Itemized receipts Every charge resolves to a clean, itemized receipt with order, postage, mailing list, credits, and total paid, so finance can reconcile and export without leaving the product. Spend & receipts Billing overview See the enterprise commitment, balances, billing groups, and account access together. It's the operating surface for billing administration.

Draft idea: rejected vs shipped

Trade offs

Money runs on systems with hard limits like Stripe, fund verification, and settlement. Each pushback turned into a decision, with a trade-off you can see and a path forward.

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, and remaining balance shows live while you set it. Offer only what a role can do. Money actions split into tabs by permission, so requests don't fail.

AI workflow

Design system

Accessibility

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.)

Outcome

Before and after

The old paths ran through the LettrLabs admin panel and backend. The shipped model brings the same actions into the product. Task-time estimates and adoption are still launch measures.

Billing model result

The outcome is a clearer in-product path for money moves on a surface that carries the revenue. Adoption, completion time, and ticket reduction are the post-launch measures.

Reflection

Billing carried the most states and the highest stakes, and it shows. Some flows, like disbursement and resolving affected automations before a delete, are powerful but still ask a lot of the admin. If I went back to 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.

"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 funding interruptions that never had to happen."

Future update

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 the analytics deeper and show budget against ROI, so admins can see where to put more money. That turns billing data into a business tool rather than a ledger.