Per-Request vs. Per-User Pricing: Why We Changed How Everstep Is Priced

Field Note #09: The Wrong Unit of Measure

The per-user pricing model that punished the right behavior

When we first launched Everstep, we charged per user. It's the default in SaaS workflow management software. Every tool you've ever paid for probably does it. A seat is a simple unit. It's easy to explain, easy to invoice, and easy to project.

There was just one problem: it made the tool more expensive the more people benefited from it.

Think about how a workflow tool actually works. You have a small ops team — maybe three or four people — who spend their days processing requests, coordinating handoffs, and keeping work moving. They're active users every single day. But for a ticket to move through the system, it often needs a comment from a manager, an approval from finance, or a sign-off from someone in a department that submits one request a month. Those people are participants. They're part of the process. But they're not power users.

Under per-user pricing, every one of them is a seat. You pay the same rate for the person who processes fifty requests a week as for the director who logs in twice a month to approve something. And when you want to give the whole company visibility into the status of their own requests? That's more seats.

The result: teams restricted access to keep costs down. They gave the tool only to the people who absolutely had to use it. Which meant fewer eyes on the work, fewer people accountable, and less of the visibility the tool was supposed to create.

We were pricing against our own purpose.

What workflow management software is actually selling

The value Everstep delivers isn't proportional to how many accounts exist in the system. It's proportional to how much work the system processes. A team of ten that runs three hundred requests a month gets more out of Everstep than a team of fifty that runs twenty. The work is the unit of value. Not the headcount.

Once we recognized that, per-user pricing for a request-based workflow tool felt like charging a shipping company by the number of employees instead of the number of packages. It's measuring the wrong thing entirely.

The right pricing model doesn't just reflect how you charge. It reflects what you believe the tool is actually doing for you.

Why per-request pricing fits the way teams actually work

Every organization has a core group of people who live in the workflow tool and a much larger group who touch it occasionally. IT processes tickets. But it's the whole company that submits them. Ops coordinates the work. But every department that depends on ops needs access to see where their request stands.

When you charge per user, you're forcing teams to make a choice: either pay for full participation across the organization, or create a two-tier system where only some people have access. Both options are bad. The first makes the workflow management software expensive to scale. The second undermines the visibility that makes structured workflows worth having in the first place.

Per-request pricing removes that tradeoff entirely. You can add every manager, every stakeholder, every occasional approver without the cost jumping every time someone new needs to be looped in. The meter runs on the work, not on the roster.

The honest alignment between cost and value

There's something else that per-request pricing gets right, and it's less about operations and more about honesty.

When your costs scale with your usage, you're paying for value delivered. A month where you processed two hundred requests cost more than a month where you processed fifty. That's fair. It reflects what the tool actually did for you. There's no awkward conversation about seats that nobody used, or teams that went quiet for a quarter but still appeared on the invoice.

Conversely, in the early days of using Everstep, request volume is lower. You're setting up services, training your teams, figuring out your workflows. Your costs should be lower too. You shouldn't be penalized for seats during onboarding just because you planned ahead and created accounts for everyone.

Per-request pricing lets the cost grow with the value. That's the alignment we were looking for when we made the switch.

It turns out we're not alone in thinking this way. OpenView Partners, one of the leading voices on SaaS pricing strategy, put it well:

"When vendors introduce a usage-based pricing model, they're sending an incredible message to customers that they stand behind their products and truly believe customers are going to be successful. In fact, they very literally won't get paid if a customer isn't adopting the product."

That's the commitment we made when we switched. If Everstep isn't helping your team process more work, your bill reflects that. We think that's how it should be.

What didn't change

Switching from per-user to per-request pricing didn't change what Everstep does or who it's built for. Teams still get unlimited users. Every person who needs visibility into the work can have it. The core ops teams, the occasional approvers, the managers checking in from time to time — they all belong in the system, and the pricing model no longer argues otherwise.

What changed is what the tiers are actually measuring: the volume of work flowing through the system. The teams processing the most requests are the ones getting the most out of the tool. It's only right that the cost reflects that.

A better unit of measure for SaaS workflow pricing

Every pricing decision is a statement about what you think you're selling. Per-user pricing says: we're selling access. Per-request pricing says: we're selling throughput.

Everstep isn't a gated directory. It's a system for getting work done and making that work visible. The value isn't in who has a login. It's in how much work moves through cleanly, with clear ownership, visible progress, and no handoffs falling through the cracks.

That's what we're charging for. And it's the only unit that actually makes sense.