Per-User vs Flat-Tier Software Pricing for Traffic Control Companies

Software pricing structure looks like a procurement detail. In traffic control it is closer to an operational decision, because the structure you pick changes who ends up using the system — and therefore what data you have.

Why per-seat fits this industry badly

Per-user pricing is the default in business software, and for good reason. It fits companies where headcount is stable, roles are clearly defined, and most staff work at desks. A firm with forty employees who each need the CRM is a clean fit.

Traffic control is not that shape.

Headcount is seasonal. A company might carry twenty year-round staff and run sixty or more in peak season. Under per-seat pricing your software bill swings with the season, and the swing arrives precisely when cash is tightest because payroll is also peaking.

The workforce is overwhelmingly field-based. The people who most need to touch the system — foremen completing tickets, flaggers clocking in, drivers logging equipment — outnumber office staff several times over. In a repair-visit business the ratio is closer to even.

Turnover is real. Seasonal hiring means adding and removing users continuously. Some vendors prorate cleanly, some bill by the month regardless, and some make removal a support ticket. Ask.

The incentive it creates, which is the actual problem

The cost is not really the problem. The behavior is.

When every field user has a marginal cost, companies do what any rational operator does: they limit access. In practice that takes two forms, and both are quietly destructive.

Crews share a login. Now the GPS-stamped, signed ticket that was supposed to establish who was on site is signed by an account four people use. Attribution — the entire point of the record — is gone. When a dispute arrives and you need to show who was where, you have a timestamp and a location attached to a shared credential. There is also a straightforward security problem the first time someone leaves on bad terms.

Field staff are left off entirely and the foreman enters everything after the fact. This looks efficient and produces reconstructed data. Times are approximations, equipment counts are recalled rather than recorded, and the ticket is completed in a parking lot at the end of the day rather than on site. The system still works. It is just being fed memory.

This matters more in traffic control than in most industries, because the field record is not only a billing artifact — it is the evidence of what was set up and who was present. The underlying risk is real and well documented: the Work Zone Safety Information Clearinghouse records 850 work zone fatalities in 763 fatal crashes in 2024, and FHWA reports 94 highway construction worker occupational fatalities in 2022. Injuries, property damage, and near misses are far more common and appear in no national dataset, which means the only record that will ever exist of those is the one your own crews create. A pricing structure that discourages crews from creating it is a compliance decision wearing a procurement costume.

Both outcomes defeat the purpose of buying the software. And both are invisible on a dashboard — the tickets exist, the reports run, everything looks fine. You only discover the data was thin when you need it to answer a question about a specific job eighteen months ago.

Flat-tier pricing removes the incentive. When access costs nothing at the margin, everyone gets it, and the record is created by the people who were actually present.

How to model the comparison honestly

Three steps, and the first is where most comparisons go wrong.

Count at peak-season headcount, not today's. List everyone who would need access if access were free: office staff, dispatchers, foremen, flaggers, drivers, yard and inventory staff. If you evaluate software in February against February headcount, per-seat will look far better than it will be in August.

Ask what a "user" means to that vendor. Definitions vary more than you would expect. Some vendors distinguish full users from limited or field-only users at a lower rate. Some count anyone who logs in. Some charge for the customer portal. The answer materially changes the arithmetic.

Check the tier boundaries on flat pricing too. Flat-tier is not automatically cheaper — it is more predictable. A small company well under a tier's limits may pay more than it would per-seat. The advantage shows up as you grow, and as a bill that does not move when you hire.

Then compare total annual cost across a realistic season, not a monthly rate against a monthly rate.

What actually matters more than either

A caution against over-optimizing this. Pricing structure is worth understanding, and it is not the most important variable in the decision.

The most important variable is whether your crews will use the thing. A cheaper system that field staff route around produces no data and no benefit, and you will still be running the paper ticket book alongside it. A more expensive system that foremen genuinely find faster than paper pays for itself in billing speed alone — tickets that used to arrive Monday for work done Tuesday arrive the same evening, and invoices go out days earlier.

Put a foreman in the evaluation and have them complete a real ticket on a phone, outdoors, and time it against the paper version. That single test predicts more about the outcome than the pricing page does.

If you want the full evaluation framework, the dispatch software buyer's guide covers requirements, vendor questions, and how to structure a trial.

Where we land

Traffic OS is priced in flat tiers — $499, $949, and $1,499 per month — with no per-user charge, specifically because the per-seat incentive works against field data capture in this industry. Current details are on the pricing page.

That is a design choice with a tradeoff worth naming: a very small operation may find flat-tier pricing less attractive than a low seat count elsewhere. If that is you, the honest advice is to run the arithmetic at your own peak headcount rather than taking anyone's framing, including ours.

When you compare vendors, read pricing off each vendor's own public pricing page and note the date you looked. Pricing changes, and a figure repeated secondhand from a blog post is not something you can defend in a budget conversation. Where a vendor does not publish pricing publicly, the accurate description is that they do not document it, not that it is expensive.

If you would like to see what the field experience actually looks like before worrying about structure, book a walkthrough.