Per-Seat Pricing and the Occasional User Problem
Strategies for people who need your internal tool twice a month: shared forms, read-only views, request flows, seat rotation and negotiating.
Your new tool has twelve daily users and a list of thirty-five more who “just need to check something now and then”. The sales manager wants to see order status. The warehouse lead submits a request once a fortnight. The CFO looks at the dashboard at quarter end. At per-seat pricing, those thirty-five people would cost more than the twelve who actually run the process.
This is the occasional user problem, and it is the reason many migrations stall at the quote stage. The good news is that most occasional users do not need a seat. They need a way in.
Sort your users by what they actually do
Before you negotiate or redesign anything, list every person who might touch the tool and write down what they do with it. Not their job title, their action. You will usually find four groups:
| Group | What they do | Typical need |
|---|---|---|
| Operators | Create, edit and move records daily | Full seat |
| Contributors | Submit requests or data occasionally | A form |
| Viewers | Check status or read reports | A read-only view or a report |
| Approvers | Say yes or no to specific items | An approval link or notification |
Say you run this exercise for the forty-seven people above. Twelve are operators. Twenty are contributors, ten are viewers and five are approvers. Your seat problem just shrank from forty-seven to twelve, plus however you choose to serve the other thirty-five.
Be honest during this sort. People overstate their needs when asked “do you want access?” because nobody likes being left out. Ask “what will you do in the tool, and how often?” instead.
Contributors: give them a form
Most platforms let anyone submit a form without a paid seat. That covers the warehouse lead raising a request, the regional manager logging an incident, or a field technician submitting a timesheet.
A form is often better than a seat anyway. It shows only the fields that matter, it can enforce required information, and it cannot accidentally break someone else’s record. Forms Are the Front Door: Designing Intake Forms That Get Complete Information covers how to make them good.
The catch is follow-up. A contributor who submits a request will want to know what happened to it. Plan for that with an automatic confirmation that includes a reference number, and a status update sent when the request moves. That covers most of what they would have logged in to check.
Viewers: publish, do not invite
Viewers want answers, not access. The sales manager does not want to learn your tool; she wants to know whether order 4471 has shipped.
Options, roughly in order of preference:
- Read-only shared views. Many platforms let you publish a filtered view to people without seats, sometimes behind a password or restricted to your company’s sign-in. Check the permission controls carefully before sharing anything sensitive.
- Scheduled reports. A weekly summary delivered to inboxes or your chat tool answers recurring questions without any login at all.
- Embedded dashboards. If your company has an intranet or a team space, a live dashboard embedded there reaches viewers where they already are.
- Status lookups. A simple page where someone enters a reference number and sees the current state.
Reporting Without Exports: Getting Dashboards from Your New System explains why live views beat a monthly export, which tends to get edited and reforwarded until nobody trusts it.
Approvers: bring the decision to them
Approvers are often senior and impatient. Asking them to log in to approve a purchase request twice a month is how approvals end up stuck for a week.
Look for approval actions that work from a notification: a link that opens a single record with approve and reject buttons, or a reply in your chat tool. Some platforms allow this without a seat; others count anyone who takes an action as a user. Read the definitions in the pricing terms, because “user” can mean “anyone who logs in”, “anyone who edits” or “anyone listed in the directory”.
If approvers must have seats, at least make sure the approval step is one click away. Approvals Without Email Chains: Building a Request-and-Approve Process has a worked example.
When people really do need occasional seats
Some occasional users genuinely need to work inside the tool. The month-end accountant who reconciles records, or the auditor who reviews history once a quarter. A few approaches:
- Cheaper seat types. Many vendors offer viewer, commenter or “light” seats at a fraction of the full price. Ask even if the pricing page does not mention them.
- Seat rotation. Where the terms allow it, reassign a seat to whoever needs it that week. This works for small, predictable groups, but it creates admin work and can breach terms if done casually, so check first.
- A request flow. Instead of access, the occasional user asks an operator to make the change. This is fine if it happens monthly; it is a bottleneck if it happens daily.
Never solve this with a shared login. Everyone using the same account destroys your audit trail, breaks permissions and usually violates the vendor’s terms. It also means you cannot remove a leaver’s access without changing the password for everyone.
Negotiating with your user map in hand
Your sorted list is a negotiating asset. Vendors price on assumptions about how many people will use the product fully. Showing that you have twelve operators and thirty-five light users is a concrete basis for asking for a different arrangement.
Things worth asking for:
- Discounted or free viewer seats for a defined number of people
- Pricing based on active users per month rather than named users
- A seat count that is reviewed annually rather than billed the moment someone logs in
- A cap on price increases at renewal
Go in with alternatives. If you can show that another platform would handle your viewers at no extra cost, the conversation gets easier. Choosing an Internal Tool Platform: The Questions Vendors Won’t Answer for You covers more pricing traps to raise before you sign.
Where to start this week
- List everyone who might need the tool and write the action they will take and how often.
- Sort them into operators, contributors, viewers and approvers, and count each group.
- Read your platform’s definition of a billable user, and note which actions trigger a seat.
- Build one form and one read-only view for your largest non-operator group, and test them with two real people.