How to Choose the Right Billable Metric for your Pricing Model

Usage-based pricing gives customers a way to pay directly in relation to the value they receive. For the teams designing the model, that approach starts with a deceptively simple question: Where does value come from in your product, and how will you map it to your events?

Usually, the decision starts with billable metrics: a unit that translates how customers receive value into a quantity your pricing model can measure and price. A billable metric turns that value into an observable unit of consumption, which could be for API calls, tokens, processed documents, completed workflows, storage, or credits. The pricing model can have a metric that customers can recognize, your finance team can forecast, and your billing system can calculate totals accurately.

However, choosing that unit can be a challenge unless properly considering each component, so it can create a stronger foundation for the rest of your model.

Why the billable metric matters

A billable metric’s place is at the intersection between product usage and revenue generated. The product generates activity, it creates value for the customer, and then translates it into a quantity for your pricing model.

At Orb, we describe the flow starting with events → metrics → prices → subscriptions → invoices. This metric also shapes a strong customer experience and helps answer questions like:

• What am I paying for?
• How does usage directly affect my bill?
• Can I estimate next month’s spend?
• What can I do to manage that spend?

A clear billable metric gives sales, customer success, and finance a consistent answer. A confusing one creates extra explanation work at every stage of the customer lifecycle.

The metric also carries economic weight. For AI and infrastructure products, usage often creates variable costs through model inference, compute, storage, bandwidth, or third-party services. A metric that reflects customer value while tracking cost exposure gives the business room to grow without allowing usage to outrun margin.

That makes metric selection a shared decision across product, finance, pricing, engineering, and go-to-market teams.

Step 1: Start with the value customers receive

Imagine a fake company, Acme Corp, as it launches an AI agent completing research workflows for enterprise teams. Acme already charges a platform subscription and it will be available as a metered capability to create a hybrid model.

The first step is to begin with the customer’s job. Asking questions like:

• What does the customer use the product to accomplish?
• Which action represents meaningful progress toward that outcome?
• What usage pattern tends to increase as the customer receives more value?
• Which unit would a buyer naturally use when describing the product internally?

This step keeps the conversation close to the product. A metric should represent something customers recognize as part of the service they are buying.

For Acme, “tasks completed” can connect directly to the work the agent performs. A customer can say, “We use the product to complete 4,000 research tasks each month.” That statement has a natural relationship to value. Tokens can be slightly different. They represent a real input into the system, yet many buyers will struggle to connect token volume to the business result they care about. Credits create a customer-friendly purchasing unit, although Acme would need to explain how credits map to different kinds of work.

Before deciding how to price it, writing down the value metric can be helpful. Connecting the unit you measure with the value is a strong initial beginning point.

Step 2: Map your cost exposure

List the costs that increase as usage grows. Depending on the product, that may include:

• Model inference or third-party API fees
• Compute time
• Storage and data transfer
• Human review or operational support
• Infrastructure capacity
• Transaction or processing fees

Then map each candidate metric to those costs. Considering internal COGS can be used as an economic guardrail, to understand whether the metric can support sustainable margins.

In the case of Acme, every completed task creates value for the customer. The cost of completing that task changes depending on the model the agent uses, the amount of context it processes, and the number of steps in the workflow. That gives Acme a few paths to evaluate:

• Charge per completed task and use model tier as a dimension.
• Charge in credits, with different credit amounts for different workflow types.
• Charge per token when token volume is highly visible and predictable for buyers.

Acme should compare the cost curve for each option. A task metric may be easier to sell. A token metric may track COGS more closely. A credit system may give Acme flexibility across several products. The right answer depends on the relationship between value, cost, and customer understanding.

Step 3: Test customer clarity

A buyer should be able to answer three questions:

• What counts as one unit?
• How many units will we use in a typical month?
• What happens when our usage changes?

This is where technical accuracy and customer clarity meet. “API calls” may work well for a developer platform because the customer already thinks in requests. “Documents processed” may work well for an AI extraction product because the unit maps to a visible workflow. “Compute hours” may be appropriate for infrastructure customers who plan around capacity.

Tokens can be a strong metric for API products and technical buyers. They become harder to explain when the customer thinks in finished outputs, completed tasks, or business outcomes.

Referring back to the Acme case, can test its three options with customers and internal teams:

• Ask a product leader to explain the metric in a roadmap review.
• Ask a sales representative to describe it during a pricing conversation.
• Ask a finance leader to forecast a monthly invoice.
• Ask a customer success manager to explain a usage spike.

The explanation should fit into a few sentences. The invoice should use the same language as the sales conversation.

Step 4: Check whether the metric can evolve

Your first metric will live alongside a changing product. New models will launch, product capabilities will expand, customers will use it in different ways, and cost structures will change. A strong metric that works today should also be able to be flexible enough for any change.

In Acme's case with their AI agent, the team should capture more information than the first price requires. Each usage event could include the workflow type, model, region, environment, input and output volume, completion status, and customer identifier.

Acme may begin by charging per completed workflow. Later, it may introduce different prices for standard and advanced models. The underlying event data can support that evolution when the relevant properties are captured from the beginning.

Step 5: Separate the primary metric from pricing dimensions

A primary metric answers: How much usage occurred?

A pricing dimension answers: Which characteristics should affect the rate?

Keeping those questions separate gives you more flexibility.

For example, a cloud infrastructure company might measure gigabytes stored and price differently by storage class and region. An AI company might measure completed generations and price differently by model family. A collaboration product might measure active seats and apply different rates by permission tier.

Dimensions should represent meaningful differences in value or cost. They also need to be present consistently in your usage data. Too many dimensions create operational work and customer confusion. High-cardinality fields can make pricing difficult to configure, explain, and maintain. The recommendation would be choosing dimensions that are stable, consistently present, and meaningful to the pricing strategy.

For Acme's use case, they could use:

• Primary metric: completed research workflows
• Dimension: standard or advanced model
• Dimension: production or test environment
• Optional dimension: workflow type

The team should add a dimension when it changes the economics or customer value of the service. A field belongs in the event schema for analysis when it may become useful later. Those decisions do not need to happen at the same time.

Step 6: Test the metric against real usage

A metric can sound right in a pricing meeting and behave very differently in production. Use historical usage to compare your candidates. Review the impact across:

• Customer segments
• Usage levels
• Product workflows
• Contract types
• High- and low-volume customers
• Typical and unusual usage patterns

Look for more than total revenue. Review bill distribution, gross margin, expansion potential, customer predictability, and the number of customers whose bills would change materially.

For Acme, they run three scenarios against six months of usage data:

• Per completed workflow
• Per 1,000 tokens
• Credit consumption with different rates for standard and advanced models

The task metric produces the clearest customer story. The token metric tracks Acme’s model costs closely, though it creates a larger education burden. The credit model gives Acme room to package several workflow types together, though customers need a clear way to understand credit burn. Acme chooses completed workflows as the primary metric, adds model tier as a dimension, and gives each customer an included monthly allocation. The team keeps the token and workflow data available for future analysis.

Step 7: Define the metric for every team

A metric becomes useful when every team understands the same definition. Documenting all features and properties can allow teams to have a practical way to turn a definition of a business into a solid calculation to be tested and reused. For Acme, the definition might read:

Completed research workflow: Count each production workflow that reaches a successful completion state and returns a final result to the customer. Retries count only when they create a new completed workflow. Test and failed workflows are excluded from customer billing.

Where metric decisions go sideways

A few patterns create problems repeatedly.

Choosing the easiest data point: The most available field may be convenient to calculate and disconnected from customer value. Start with the product behavior and confirm the data can support it.

Turning COGS into the public metric: COGS can change faster than the customer’s understanding of value. Use cost exposure to test the model’s economics, then choose a customer-facing unit that can carry the pricing conversation.

Mixing the metric with the price: “$0.05 per workflow” combines a quantity with a rate. The metric is workflows completed. The price is $0.05 per workflow. Keeping those concepts separate makes it easier to create different prices for different segments and plans.

Adding dimensions before the strategy needs them: Every new dimension adds configuration, testing, invoice detail, and customer education. Add dimensions when they reflect a meaningful difference in value or cost.

Skipping the historical test: A metric can look balanced at the average customer and create severe outliers at the edges. Test the full distribution before launch.

Treating the first metric as permanent: Products change. Pricing should have room to change with them. Preserve rich usage data, version definitions carefully, and create a path for reviewing the metric after launch.

Choose the unit that can carry the model

A billable metric gives your pricing model a way to connect product activity, customer value, cost exposure, and revenue growth.

Start with the value your customers recognize. Map the costs that scale behind the scenes. Test clarity, durability, dimensions, and historical behavior. Then define the metric in language every team can use.

For the use case on Acme, their final decision came from that full process. Completed workflows gave customers a clear unit to understand. The model tier accounted for meaningful cost differences. Rich event data gave the team room to refine the model as the agent evolved.

That is the standard to aim for: a metric customers can trust, a model the business can sustain, and a foundation that can grow with the product.

For the next step in the journey, read the guide to building your first usage-based pricing model, or explore Orb’s billing documentation to see how events, metrics, prices, plans, and invoices work together.

Talk to Orb about designing and launching a pricing model that can evolve with your business.