Seat pricing charges for headcount, not for the work people do.
Per-seat pricing is simple for a vendor to sell and for a buyer to budget at the start. It becomes a problem as a business grows, because every new hire who needs to see anything in the system becomes another seat. The fee grows with headcount, even when most of the new people use a small part of the product occasionally.
The pattern is common in field operations, multi-location businesses, and firms with many part-time or seasonal staff. A technician who checks one schedule, a location manager who approves a few requests, and a contractor who uploads documents may each need a full seat. The business pays the same for them as for the people who work in the system constantly.
Seat costs also shape behavior in ways that cost money elsewhere. Teams share logins, which weakens security and removes the audit trail. Managers ask colleagues to look things up instead of getting access. Information is copied into spreadsheets and emails so people without seats can see it. Each workaround saves a license fee and adds risk or staff time.
Audit every seat by how it is actually used.
Export the user list and the login activity from the product’s admin console. Group users into those who work in the system most of the time, those who use it occasionally for a specific task, those who only view information, and those who have not logged in recently. Most businesses find that the last group is larger than they expected.
For each group, write down the task they perform. Occasional users often do one thing: approve a request, check a status, enter time, or upload a document. Viewers usually need a report or a single screen. This task list is more useful than the user count, because it shows what each person needs rather than what the license happens to allow.
Remove seats for people who have left or no longer need access, and set a routine for doing so whenever someone changes role. That alone may reduce the renewal. It also establishes a baseline of genuine use, which becomes the starting point for the negotiation and for any comparison with an alternative product or a replacement.
Negotiate the pricing model, not only the price per seat.
Ask the vendor what lighter roles exist. Many products offer view-only, approver, or limited users at a lower price, and some do not advertise them. Moving occasional users to those roles may cut the cost without changing how anyone works. Confirm that each role still allows the specific task the person performs before moving anyone to it.
Where the business is growing, ask for pricing that reflects that growth: seat prices that fall as volume rises, pricing by location or by volume of work rather than by person, or a cap on increases at renewal. Ask how seats are counted, whether inactive users count, and whether seats can be reduced during the term or only at renewal.
Put every agreed change in the signed order form, and have your counsel review the terms before signing. Pricing concessions made in a sales conversation are reliable only once they are in the contract. Record the terms on the renewal calendar so the next negotiation starts from what was agreed rather than from the vendor’s standard price list.
Give occasional users a focused tool instead of a full seat.
When many people need one task, a focused application built around that task can replace their seats. A technician app that shows the schedule and records completed work, an approval screen for managers, or a portal where contractors upload documents can each read from and write to the main system through its API, leaving full seats for the people who need the whole product.
This approach depends on the vendor’s API and terms. Check that the API supports the records and actions the focused tool needs, and that the contract allows integration users or service accounts to act for people without seats. Some agreements restrict this, and some price API access separately. Your counsel should confirm the terms before anything is built around them.
A focused tool also tends to be easier for occasional users. They see only the task they perform, on the device they use, without training on a product built for full-time users. That improves adoption and data quality, and it removes the temptation to share logins. Meanwhile, the core product keeps running the work it does well for the people who use it most.
Decide when the seat model means the product should be replaced.
Sometimes right-sizing and negotiation are enough, and the product remains the right choice. Replacement becomes worth considering when the seat fee keeps rising after the audit, when most users need only a narrow part of the product, and when the work that matters most is specific to how the business operates and the product handles it poorly.
Compare the options on total cost as the business grows, not at current headcount. Estimate the seat cost at the size the business plans to reach, the cost of a focused tool plus a smaller seat count, and the cost of replacing the product in phases, including maintenance. Include the staff time spent on workarounds today, since that cost continues under every option that keeps them.
Baybloom builds focused tools for occasional users and, where the comparison supports it, replaces vendor systems in phases while the subscription keeps running. The first step is the same in every case: a clear picture of who uses the product and for what. With that picture in hand, the right answer for the business is usually easy to see.
Put it into practice
Talk through the project you are considering.
Bring the workflow, the systems around it, and the questions you need to resolve. We can help define a useful next step.
Discuss your project