Insight from a recent pricing workshop

I ran a pricing workshop recently where we hit on an insight that changed the direction of the entire project. The company was evaluating user-based pricing, a model that seems straightforward on the surface but quickly reveals its limitations when you look at real customer data.

The setup

The company served two distinct customer segments, and their usage patterns could not have been more different.

Segment A: Many projects, few assets per project. These customers ran dozens of small projects simultaneously. Each project involved a handful of assets, but the sheer volume of projects meant they needed many users with access to the platform. Think of a consultancy managing numerous client projects at once.

Segment B: Fewer projects, many assets per project. These customers had a smaller number of large-scale projects, each involving hundreds or thousands of assets. They needed fewer users overall, but each user worked with significantly more data and required more platform capacity. Think of a large industrial operation with a small, specialized team.

The problem with user-based pricing

When we modeled user-based pricing against these two segments, the mismatch became obvious.

Segment A would pay significantly more because they had many users, even though their per-user resource consumption was relatively low. The price signal would tell them they are expensive customers, which was not true from a cost-to-serve perspective.

Segment B would pay relatively little because they had few users, even though their actual platform usage (in terms of data volume, processing, and storage) was substantially higher. They would be getting a bargain at the expense of Segment A.

In short, user-based pricing would overcharge the light users and undercharge the heavy users. That is a recipe for churn in Segment A and margin erosion in Segment B.

The workshop insight

The key insight that emerged was this: the right pricing metric should correlate with both the value the customer receives and the cost to serve them. User count correlated with neither in this case.

We explored several alternatives:

• Asset-based pricing aligned better with Segment B’s value perception but felt punitive to Segment A, who had many small projects with few assets each.
• Project-based pricing resonated with Segment A but did not capture the complexity and resource intensity of Segment B’s large projects.
• A hybrid model combining a base fee with a usage component tied to asset volume emerged as the most balanced approach. It gave Segment A a predictable base cost that reflected their project management value, while the asset-based component ensured Segment B paid fairly for their intensive usage.

The broader lesson

User-based pricing is popular because it is easy to understand and easy to implement. But “easy” is not the same as “right.” Before committing to any pricing metric, model it against your actual customer segments. Look at who overpays, who underpays, and whether the metric reflects the value you deliver.

In this case, spending two hours in a workshop with real data saved the company from launching a pricing model that would have driven away their most loyal segment within a year. That is time well spent.

Thinking about your pricing model? Let’s talk.