Paying per Seat or per Project: A Twelve-Month Cost Trace

A team of 22 spent 4,180 euros on per-seat software and 1,940 euros on per-project software in twelve months, and used the per-project tools more heavily. The cheaper model was also the better fit, which is not a coincidence the team understood at the time.

The company built internal tools for a logistics group. Its software spend was approved annually per department, with no line for unused seats.

The two models

Per-seat pricing charges for access. Per-project pricing charges for a container of work, with a cap on collaborators that is usually generous. A 22-person team with four or five active projects fits the second model naturally.

Seat pricing fits a team where everyone works on everything, which was not this team’s shape.

Where the seats went

Of 22 seats, an average of 15 were used in any given week. The seven unused seats belonged to people who needed access twice a quarter, usually to review something, and who could not be removed without a re-onboarding cost.

Seven seats at the annual rate came to 1,180 euros for access that was used about 56 times.

The project model in practice

Four projects ran concurrently and each cost a flat fee with unlimited viewers. Collaborators were capped at 12 per project, which suited the team because a project rarely involved more than nine people editing.

Two projects ended mid-year and the fee stopped, which is the main advantage of the model and the main reason finance liked it.

What the project model hid

Cross-project search required a separate view, which was a paid add-on. Without it, a question that spanned two projects required opening both and reading, which happened often enough to justify the add-on after two months.

The add-on cost 240 euros a year and was not in the original comparison, which is the ordinary way a pricing model hides its total.

The seat model’s hidden cost

Seat pricing made access a decision. Adding a reviewer for a fortnight required an approval, which took between one and four days. Three projects started late because a reviewer’s seat had not been provisioned.

Latency is a cost that appears in schedules rather than invoices, which is why it survives annual budget reviews.

What the team does now

New tools are evaluated on two questions: how many people need to read rather than write, and how often does the container of work start and end. If readers outnumber writers and work arrives in projects, the per-project model wins on both cost and friction.

The team also tracks seat utilisation monthly, which is a fifteen-minute report and the only thing that would have caught the seven-seat problem in month three instead of month twelve.

Twelve months later

Per-seat spend is down to 2,600 euros after removing four seats and switching one tool to the project model. Per-project spend is up slightly, because a fifth project started.

The report finance actually wanted

The department had no line for unused seats, so the seven-seat problem was invisible in the annual review. The team now produces a one-page utilisation table: seats bought, seats used in the last thirty days, and the cost per used seat. Three columns, no narrative.

That page is what changed the budget conversation. A total spend figure invites a percentage cut; a cost per used seat invites a decision about who needs access.

What the team would do differently

It would start every tool purchase with the reader-to-writer ratio, because that single number predicts which pricing model fits and how much access will go unused. It would also budget for the add-on that makes search work across containers, since that was the predictable omission.

Neither change requires negotiation with a vendor, which is why both were adopted within a month.

Four thousand one hundred and eighty euros once bought 22 seats, 15 of which were used. Two thousand six hundred now buys the access the team needs, and the difference went into a project model that stops charging when the work stops.