Skip to main content
All guides

Field service operations

Per-seat pricing is why your team shares a login

A pricing model is an operating model decision, and almost nobody evaluates it that way at purchase. This is what per-seat licensing does to a field operation.

Updated March 16, 2026 · 8 min read

The short answer

  • When access costs money per person per month, somebody has to decide which people do not get access, and that decision is made on price rather than on workflow.
  • The people cut from the licence list are usually field staff, who are also the people generating the data everyone downstream depends on.
  • Shared credentials, proxy data entry, and a missing audit trail are the predictable consequences, and they are security, compliance, and usually contractual problems.
  • The licence saving is a visible line item and the resulting data quality loss is not, which is why per-seat pricing rarely gets challenged in a business case.
  • Evaluate seat pricing by counting everyone who touches the workflow, not everyone you currently intend to give a login.

Software is usually evaluated on features, with pricing treated as a separate, later negotiation. That order is backwards for operational systems. A per-user price is not only a cost structure; it is a rule about who is allowed to participate in the work. Most of the damage from per-seat licensing is not the invoice. It is the operating model that grows around the invoice.

A price per person is a rule about who participates

The mechanism is simple and entirely rational at each step. A platform charges a monthly fee per named user. Someone owns that line in the budget. When the number of people who could use the system exceeds the number the budget comfortably supports, that person does the obvious thing: they rank users by how clearly each one justifies the cost. Office staff are easy to justify because they sit in the system all day. Occasional users are harder. Seasonal and part-time staff are harder still. The list gets trimmed until the number works.

No one in that sequence makes a bad decision. But the aggregate result is that a commercial model, chosen by a supplier for their own revenue reasons, has quietly determined which of your employees can record their own work. That is an operating decision, and it was made without anyone framing it as one.

The people who get cut are the ones generating the data

In a field service business, the trimming almost always lands in the same place. Technicians, installers, drivers, and subcontractors are numerous, individually low-usage, and physically distant from the people making the licensing decision. They are also the origin of nearly every fact the business runs on: what was found on site, what was replaced, how long it took, what the customer approved, what still needs to be scheduled. Cutting their access does not remove the need for that information. It just moves the point at which the information enters the system.

  • Job status, which now arrives by phone call or text rather than from the job record
  • Parts and materials used, reconstructed later from memory or a paper ticket
  • Time on site, which becomes an estimate instead of a timestamp
  • Customer approvals and change requests, captured in a photo of a signed page or not at all
  • Follow-up work identified on site, which depends on someone remembering to relay it
  • Site conditions and asset history, which stop accumulating because nobody has a place to put them

What happens after the seats are cut

The work still has to be done, so the organization routes around the constraint. Three patterns show up almost universally, and they compound.

Shared credentials

A crew gets one login. It is written on a whiteboard in the shop, saved on a tablet in a truck, or forwarded in a group message. This is an understandable response to a real constraint, and it is also a genuine problem: it breaks the link between an action and a person, it survives departures because nobody rotates it, and in most agreements it is an explicit breach of the licence terms. It is not a clever workaround. It is an unmanaged risk the business has taken on to reduce a subscription line.

One person entering data on behalf of five

More often, a dispatcher or coordinator becomes the human interface to the system. Five technicians call in, and one person types. That role is now a bottleneck, a single point of failure, and a translation layer where detail is lost. It is also expensive: a full-time salary is frequently spent to avoid a licence cost a fraction of its size, and because it appears as headcount rather than software, nobody attributes it to the platform.

Delayed, degraded information

Data entered at the end of the day by someone who was not on site is both later and worse than data entered on site by the person who did the work. Invoicing slips. Scheduling decisions are made against a picture of the day that is several hours stale. Disputes about what was done and when cannot be settled from the record. Reporting built on top of this is confidently wrong, which is worse than obviously incomplete.

The seat decisions and what follows

Seat decisionShort-term savingOperational cost that follows
Technicians share a crew loginOne seat instead of four or five per crewNo per-person audit trail, credentials that outlive employment, and a licence-term breach the business is carrying knowingly
Field staff have no access; dispatch enters everythingDozens of seats removed from the subscriptionA coordinator role that exists only to retype information, plus a daily bottleneck when that person is out
Subcontractors are kept outside the systemZero seats for a variable workforceWork performed by subs is invisible until an invoice arrives, and reconciliation moves to a spreadsheet
Read-only viewers are dropped to save costSeats for managers, finance, and support staffReporting is exported and emailed, so decisions get made against snapshots that are already out of date
Seasonal and part-time staff are excludedNo seat cost during off-peak monthsThe busiest period is the one with the worst data capture, exactly when accuracy matters most
Common seat decisions and the operational cost that follows

Read the third column as the actual price of the second. In most operations we have looked at, the third column is larger, and it is paid in labor, rework, and decisions made on bad information rather than in a subscription invoice.

Why none of this appears in the business case

The licence saving is countable, attributable, and shows up in a system somebody reports on. Forty seats not purchased is a number you can put in a slide. The cost that replaces it is spread across a dozen accounts that nobody adds together: a coordinator's salary, overtime for evening data entry, invoices sent four days late, a written-off dispute, a warranty claim that could not be evidenced, and the slow erosion of confidence in the reports everyone still uses to make decisions.

There is a cultural cost too, and it is the one that lasts longest. A workforce that is not given access to the system they are expected to feed learns to treat that system as an obstacle rather than a tool. When the business eventually buys or builds something better, that attitude does not reset on its own. Adoption problems on the next platform are frequently inherited from the licensing decisions made on the last one.

Rigid workflows, poor mobile usability, per-user licensing, and fragile integrations slowed dispatch, delayed invoicing, and kept critical users out of the system. In the replacement, every technician, dispatcher, and manager can access what they need without seat-count tradeoffs.
From ERP to agility, an anonymized B-Team engagement in trades services

How to evaluate seat pricing before you sign

The evaluation error is counting the logins you plan to buy instead of the people the workflow touches. Do it the other way around.

  1. 1

    List every person who creates, changes, or needs to read information in the workflow. Include field staff, subcontractors, seasonal workers, back office, finance, and managers.

  2. 2

    Price the platform at that full number, at the vendor's list rate, with no assumed discount. That figure is the honest comparison point.

  3. 3

    Model the number again at your realistic peak headcount, not your current one. Seat costs scale with hiring, and growth is when the pressure to cut access is highest.

  4. 4

    Ask what happens at renewal. Confirm in writing whether per-seat rates are fixed, indexed, or reset at the vendor's discretion.

  5. 5

    Ask what a seat includes. Mobile access, API access, and reporting are sometimes priced as separate tiers, which changes the real per-person number.

  6. 6

    If the full-coverage figure is one you would not approve, treat that as a finding about the product's fit, not as a prompt to trim the user list.

Mitigations worth asking a vendor for

Plenty of vendors have workable answers here, and asking directly is a fast way to learn whether the product was designed with field operations in mind or only sold into them.

  • Tiered user types, where a field user costs materially less than a full administrative user
  • Read-only or viewer seats at low or no cost for managers and support staff who only consume information
  • Concurrent licensing for shift-based work, so a seat follows the shift rather than the person
  • Seasonal or flexible seat counts that can be adjusted mid-term without a renegotiation
  • A supported way to capture work from subcontractors and other external parties without a full licence each
  • Written confirmation of how named-user terms are enforced and audited, so you know what you are agreeing to

If a vendor has none of these and the answer is that everyone simply needs a full seat, that is a legitimate position for them to take. It just means the product's economics and your operating model do not match, and you should price the mismatch now rather than discover it in year two.

When the licensing model becomes the reason to leave

Most replacement decisions are justified on features, but a licensing model can be the deciding factor on its own. The threshold is reached when the pricing structure is shaping your operations against your judgement: when you are hiring people to work around access limits, when you cannot answer a basic question about who did what, or when improving your data quality would require a licence purchase you are not going to make.

At that point the constraint is structural. No configuration change, training program, or process improvement will fix it, because the limit is commercial rather than technical. The trades engagement referenced above reached exactly this point: the renewal cost was the trigger, but the reason not to renew was that the system's economics kept the people doing the work outside the system. The replacement was designed so that access is a permission question rather than a purchasing question, which is what made complete field capture possible.

Common questions

Is sharing a login ever acceptable?
It is understandable, but it is almost never acceptable. Shared credentials remove per-person attribution, survive staff departures, and in most software agreements they breach the named-user terms you signed. If cost is forcing the practice, the right move is to renegotiate the licensing or change the platform, not to normalize the shared account.
How do we estimate the real cost of excluding field staff?
Start with the labor: count the hours spent relaying, retyping, and reconciling information that the person who did the work could have entered once. Add the measurable delays, such as days between job completion and invoice, and the cost of disputes or warranty claims you could not evidence. That total is usually larger than the seats you avoided buying, and unlike the seats it is not visible on any single invoice.
What should we ask a vendor about per-user pricing during evaluation?
Ask for the price at full coverage of everyone who touches the workflow, not at the user count you were planning to buy. Then ask whether tiered, read-only, concurrent, or field-user pricing exists, whether mobile and API access are included in a seat, and how rates change at renewal. Get the answers in writing before the commercial conversation narrows to a discount.
Does moving to custom software remove seat costs entirely?
It removes per-user licensing, but not cost. You take on build, hosting, support, and ongoing change instead. The relevant difference is that those costs scale with usage and infrastructure rather than with headcount, so adding a technician is an operational decision rather than a budget negotiation.
Our vendor offered a discount on additional seats. Does that solve it?
It helps, and it is worth taking, but check the term. A discount that applies for the current contract period and resets at renewal leaves the same pressure in place a year or two later, usually at a point when migration is harder. Ask whether the discounted rate is contractually fixed for the seats you add, and what the price is if your headcount doubles.
How do we handle subcontractors who need to record work?
Ask the vendor specifically, because this is where per-seat models are weakest and where shared credentials most often appear. Some platforms support external or limited-access users at a lower rate; others expect a full seat per person, which is impractical for a variable workforce. If there is no supported answer, plan for a separate intake path with its own reconciliation rather than letting subcontractor work enter under someone else's account.

Want this applied to your operation?

The first conversation is a no-cost fit discussion about the problem, its importance, and the people involved. We respond within one business day.

Start a conversation