Go back

Per-account vs. per-seat: what each model actually costs at scale

Per-seat and per-account pricing can look nearly identical at a ten-person pilot, close enough that the pricing model barely factors into an initial decision. The gap between them tends to widen considerably once a team scales past that early stage, which makes it worth understanding the actual mechanics of each model before assuming the difference won’t matter for your organization.

How per-seat pricing works

Per-seat pricing charges a fixed amount for every person with access to the platform, regardless of how much or how little that person actually uses it. A team of fifty people, each with an assigned seat, pays for fifty seats whether every person logs in daily or only a handful actually touch the tool in a given month. The model is simple to explain and predict, which is part of its appeal, but it ties cost directly to headcount rather than to actual usage.

How per-account pricing works

Per-account pricing, often built on a credit or usage-based system, ties cost to what’s actually produced, minutes of video, number of assets generated, rather than to how many people have a login. Under this model, adding team members who need occasional or light access doesn’t automatically increase cost, since the organization is paying for consumption rather than headcount.

Why the two models converge at a small team size

At a small team size, usage tends to be relatively concentrated among a handful of people who are also the ones with seats, so the practical difference between paying per-seat and paying per-account is often minor. This is exactly why the pricing model rarely gets serious scrutiny during an initial pilot or small-team rollout, the numbers simply aren’t far apart yet.

Why the gap widens as a team scales

As an organization grows, usage patterns tend to become more uneven rather than less. A larger organization typically has a smaller core group of frequent creators alongside a much larger group of occasional or light users, people who might need access for a handful of projects a year rather than daily use. Per-seat pricing charges the same for both groups, which means the total bill grows in lockstep with headcount even when actual usage grows far more modestly. Per-account pricing, by contrast, continues to track actual consumption, so the bill grows roughly in line with what’s actually being produced rather than how many people technically have access.

A concrete way to model the difference

Start with three numbers: your current or projected headcount that would need some level of access, a rough estimate of how much each user group, heavy versus occasional, would actually produce in a typical month, and the specific pricing terms for each model you’re comparing. Calculate per-seat cost as headcount multiplied by seat price. Calculate per-account cost based on projected usage against the relevant credit or usage tiers. Run this at your current size and again at a reasonably projected future size, since the comparison that matters most is how each model behaves as the organization grows, not just what it costs today.

Why video tools specifically tend to have uneven usage

Video production tools are a particularly good example of where usage is naturally uneven across a team. A dedicated content or enablement team might produce dozens of videos a month, while individual salespeople, support agents, or managers might only need to create a handful of personalized videos across an entire year. Per-seat pricing treats a daily power user and a once-a-year occasional user identically for billing purposes, which is exactly the mismatch that tends to make per-account pricing more cost-effective as this kind of tool spreads beyond its original core team.

What per-seat pricing does well, to be fair to it

Per-seat pricing isn’t inherently a worse model, it works well for software where usage genuinely is fairly even across every licensed user, a project management or communication tool that most people check daily, for instance. The mismatch specifically shows up for tools with naturally concentrated, uneven usage, which is a meaningfully different usage pattern than what per-seat pricing was originally designed to reflect.

Why broader access matters beyond just the cost calculation

Beyond the direct cost comparison, per-account pricing tends to remove a specific kind of internal friction: deciding whether a given person “deserves” a seat, weighing their expected usage against the incremental per-seat cost of adding them. Under usage-based pricing, adding someone who might use the tool only occasionally isn’t really a cost decision at all, which in practice tends to result in broader, more natural access across a team rather than access that’s artificially restricted by a per-seat cost calculation nobody wants to keep revisiting.

A worked example, in round numbers

Imagine two organizations, each with 100 people who need some level of access to a video platform. Organization A has usage concentrated among 15 frequent creators producing most of the content, with the remaining 85 people touching the tool only a few times a year for a personalized message or a quick update. Under a per-seat model charging a flat rate per person, both organizations with 100 seats pay the same amount regardless of this usage difference. Under a per-account, usage-based model, Organization A’s bill tracks much closer to what its 15 core creators are actually producing, since the 85 occasional users barely move the usage total even though they’re all counted as seats under the other model. This is the concrete shape of the gap that per-seat pricing misses.

Questions worth asking either way

Regardless of which model a vendor uses, ask specifically what counts toward cost: for per-seat pricing, confirm whether inactive or rarely used accounts still count as billed seats, since some vendors distinguish active from inactive seats while others don’t. For per-account pricing, confirm what happens as usage scales up past your current tier, and at what point cost increases meaningfully, so a growth in actual production doesn’t create a bill you didn’t anticipate.

Velo’s approach

Velo prices per account using a credit-based system, Free at 1,500 credits per month, Pro at $49 per month with 3,000 credits, Ultra at $200 per month with 30,000 credits, and custom Enterprise pricing with custom credits and seats, rather than charging per individual seat. This ties cost to actual production volume as a team and its usage grow, rather than penalizing broader access with a direct per-person cost increase every time someone new needs to touch the platform.

Revisit the model as your team’s usage actually evolves

Treat this comparison as something worth revisiting periodically rather than a calculation done once at signup. As your team’s composition shifts, more occasional users added, existing users’ habits changing, it’s worth rerunning the numbers to confirm the pricing model still fits how the organization actually uses the platform, rather than assuming the original analysis holds indefinitely as the team and its needs continue to change.

Try Velo for free · See how it works


About the author

Ritu Parakh is Growth Lead at Velo, the AI video messaging platform that turns a screen recording, a deck, or a URL into a polished, narrated video - and an editable written doc. She writes about video for demos, onboarding, training, and enablement. Connect on LinkedIn

Per-seat pricing charges based on the number of people with access. Per-account pricing charges based on actual usage, typically credits or minutes, regardless of how many people have a login.

Not automatically, but it tends to be cheaper for organizations where usage is uneven across users, a common pattern for tools like video production where a smaller group of frequent creators sits alongside many occasional users.

Per-account, using a credit-based system tied to actual usage rather than a fixed charge per team member.

Estimate how many people need some level of access, roughly how much each group would actually produce, and calculate what each pricing model costs at your current size and at a reasonably projected future size.

Bring the video layer to your product team