The Moving Parts of a UBB Transition

For most SLG companies, usage-based billing starts as a pricing decision. In practice, it behaves like an organization change.

UBB is the right strategic move for teams trying to keep up with the AI era. It aligns revenue with actual product value and gives you room to experiment. But the moment you switch from static contracts to metered usage, the impact runs through every part of the business, not just the pricing page. The rest of the series will take each part in turn and go deeper on what needs to change to make UBB work, not just in theory but in your actual systems and workflows.

When you change your monetization model, you are also changing:

• How compensation and commission work for sales
• How contract structures are designed, negotiated, and handed off
• How often invoices get questioned, disputed, or rewritten
• How much engineering time is spent keeping billing alive instead of shipping product
• How forecasting and predictability actually function for finance and rev ops

This post is the roadmap for that shift. It walks through where UBB creates new friction for sales, CS, finance, engineering, and rev ops, and groups those issues into a simple framework you can reference as you plan your own transition.

The comp problem

When comp structures built for committed ARR meet a usage-based motion, reps are stuck having to adapt to the mechanics of the new model, which don't cleanly map into their methods to hit targets the way they used to.

• Quota pressure meets variable deals: Usage-based contracts tend to start smaller and expand over time, which means the upfront commit looks lower than a traditional subscription deal. For a rep measured on ARR at close, that's a real problem that doesn't have an easy workaround.
• Pricing variability creates friction in the sales conversation: When pricing shifts with usage, reps have to explain a model that's harder to make concrete for a buyer. Without the right tools and talking points, that conversation often stalls or gets simplified in ways that don't serve the customer later.
• Contract restructuring mid-motion: As companies rework deal structures to fit a usage-based model, reps are often selling under terms that are still being figured out. The goalposts move, and quota attainment becomes harder to predict for everyone.
• Misalignment compounds over time: The longer comp structures lag behind the new model, the more the sales motion drifts. Reps optimize for what gets them paid, and if the system hasn't caught up, that optimization works against the transition.

The spreadsheet that never goes away

In an SLG world, enterprise deals come loaded with negotiated terms: custom tiers, minimums, credits, overages, and contract structures that no two customers share. When billing can't express that natively, finance inherits the gap and fills it with spreadsheets.

• Manual translation: Negotiated tiers, minimums, drawdowns, and one-off credits all have to be translated by hand into billing logic at month-end, a process that's entirely dependent on whoever built the spreadsheet understanding the original contract intent. At Stytch, one person on the BizOps spent a full business day every month doing exactly this: translating bespoke contracts into invoices manually, where changing a single plan meant another layer of spreadsheet logic to remember and reconcile.
• Clarity tax: Reps optimize contracts to close deals, not to be reconciled later, which means the most strategically important accounts are often the hardest to bill accurately and the most likely to generate disputes.
• Wrong timing: The reconciliation work lands at the end of month, exactly when finance is already under pressure to close the books, creating a recurring bottleneck that never fully resolves.
• No ceiling: As more strategic accounts land, the spreadsheet burden scales with them. There's no natural point at which this gets easier without a system change.

When CS inherits the billing conversation

The first usage-based invoice is a moment of truth. If it doesn't match the customer's mental model, CS inherits the fallout.

• Flying blind: Without real-time usage visibility, CS improvises: pulling exports, building ad hoc spreadsheets, and scheduling calls to walk through line items manually, often without confidence that the numbers they're presenting are complete or current.
• Eroding trust: When bills swing month to month and the reasoning behind the variance is opaque, customers stop trusting the model. Supabase saw this firsthand: invoices were confusing enough that they drove a steady stream of support tickets every month, with customers opening cases just to understand what they'd been charged for. That erosion is hard to reverse and tends to surface at renewal.
• Misplaced cost: The root cause usually starts upstream in how pricing is sold, but CS pays the operational cost at every renewal cycle, absorbing work that was never part of the job description.
• Opportunity cost: Every hour a CS team spends walking a customer through an invoice is an hour not spent deepening the relationship, identifying expansion opportunities, or getting ahead of churn risk.

Engineering drag: pricing changes become a backlog, not a lever

Every pricing nuance the system can't handle becomes an engineering ticket, and over time, monetization work crowds out product work.

• Code for every edge case: Custom contract logic that can't be configured in the billing stack requires code, not clicks, which means every new deal structure creates a dependency on engineering capacity that product and finance can't see or plan around.
• Compounding backlog: Pricing edge cases, retroactive fixes, and manual corrections pile up faster than they get resolved, and the team that owns the backlog is the same team the rest of the company is waiting on for product work.
• Hidden cost: Replit calculated that building a homegrown usage billing system would cost them a product launch and require engineers to maintain it indefinitely. Most SLG companies face the same tradeoff, even when nobody has done the math explicitly.
• Velocity tax: Every sprint absorbed by billing maintenance is a sprint not spent building toward product differentiation, and in a competitive market that tradeoff has a real cost.

Forecasting in the dark

For rev ops teams that have spent years modeling predictable subscription revenue, usage-based billing doesn't just change the inputs. It changes the entire logic of how revenue is understood and projected.

• Fixed subscription forecasting doesn't translate: In a subscription model, revenue is largely known: contract value, term length, renewal date. Rev ops teams built their entire forecasting infrastructure around those signals. Usage-based revenue doesn't close that way, and the models that worked before produce unreliable outputs when applied to a motion they weren't designed for.
• Expansion becomes harder to see coming: In a subscription world, expansion shows up as an upsell or a renewal uplift, both of which have clear signals and timelines. With usage-based billing, expansion happens gradually and continuously, often without a discrete event that rev ops can track in the CRM. By the time the growth is visible, the opportunity to get ahead of it has already passed.
• The right signals don't live in the right places: Leading indicators like usage growth rate, credit burn velocity, and product adoption depth are the metrics that actually predict expansion and churn in a usage-based model. Most of that data lives outside the CRM, in billing systems, data warehouses, or product analytics tools that rev ops doesn't have clean access to. LaunchDarkly found that self-serve usage could take up to eight hours to appear in their systems, meaning forecasts were built on lagging data rather than real-time behavior.
• Unreliable models erode confidence: When the forecast is consistently off, even in the right direction, leadership loses confidence in the model and rev ops loses credibility. That dynamic is hard to recover from, and it tends to get worse before anyone names the root cause.

What "ready for UBB" actually looks like

Usage-based billing is the right move for most SLG companies, and the ones who get it right see better retention, expansion, and stronger customer trust. The difference between companies that grow with UBB and those that just cope with it comes down to whether they treat it as a pricing tweak or a system change.

The ones who get it right do three things well. They map custom, SLG-style contracts cleanly into billing logic without manual reconciliation. They give every team, sales, CS, finance, engineering, and rev ops, shared and trustworthy usage and billing data. And they run finance workflows that scale without adding headcount every time revenue grows.

Orb was built specifically for the complexity of how SLG companies sell: bespoke contracts, real-time usage visibility, and revenue data every team can trust. If you're weighing the switch or working through the friction of a transition already in progress, see how Orb approaches sales-led growth.

Stay tuned for the rest of the series, covering how SLG companies can make usage-based billing work across every layer of the organization.