Traffic Control Dispatch Software: A Buyer's Guide

Most traffic control companies buy operations software twice. The first time they buy a general field-service platform because it is what came up in search, spend six months bending it around equipment rentals and daily tickets, and give up. The second time they buy something narrower with a much clearer idea of what they actually needed.

This is an attempt to skip the first purchase. It covers what makes traffic control operationally different from the field-service model most software assumes, which requirements are genuinely non-negotiable, and how to run an evaluation that survives contact with your crews.

A disclosure so you can weight this correctly: Traffic OS is our product, built for this industry. The evaluation framework below is one we would be comfortable being held to, including where it points at things we do not do.

Why the general platforms fit badly

Field-service software is overwhelmingly built around one shape of work: a technician drives to a customer, diagnoses something, performs a repair, and collects payment. HVAC, plumbing, electrical, appliance repair. The data model reflects it — a job has a customer, a technician, a service performed, and an invoice.

Traffic control is a different shape in at least five ways.

The unit of work is a crew plus devices, not a technician. A job might need two flaggers, a truck, forty cones, six Type II barricades, and an arrow board. Software that models "assigned technician" as a single field is already fighting you.

Equipment stays on site and accrues charges. Devices are deployed for days or weeks and often bill as rentals. This is the single biggest structural mismatch. Repair-visit software treats parts as consumed at the visit; traffic control equipment is a rented asset with a location, a deployment date, a return date, and revenue accruing the whole time. Companies that force this into a repair-visit model end up tracking equipment in a parallel spreadsheet, which means the two never agree.

Documentation ties to an agency-approved plan. The job has an external technical document governing how it must be built, and an external authority that can stop the work. There is no equivalent in residential HVAC.

The daily ticket is the billing document. For a large share of traffic control work, payment depends on a signed field ticket showing crew, hours, equipment, and location. Not an invoice generated in the office — a document signed on site, often by someone from the prime contractor or the agency.

Work is frequently multi-day, multi-phase, and recurring. Lane closures run in phases. Setups change between day and night. Barricade rentals renew monthly. "One visit, one invoice" does not describe it.

You can force a general platform through all five. Companies do. The result is usually the software plus two spreadsheets plus a paper ticket book, which is more overhead than paper alone.

The requirements that are actually non-negotiable

Here is what to hold firm on, in rough order of how much damage a gap causes.

Field-signed daily tickets, GPS and time stamped

This is the one. For most traffic control companies the daily ticket does three jobs at once: it is the billing document, the compliance record, and the dispute evidence.

The test is not whether the software can produce a ticket. It is whether a foreman can complete one faster than writing it on paper, in a truck, in weather, possibly wearing gloves, possibly with poor signal. If it is slower, crews will keep using paper, the tickets will be entered late or not at all, and every downstream capability you bought is now running on incomplete data.

Ask specifically: how many taps to complete a routine ticket, what happens to a signature captured offline, and whether the ticket can be produced as a PDF that an agency will accept without reformatting.

Why this matters beyond billing: the same record is your evidence of what was set up and when. That is the gap most companies carry silently. The plan lives in a PDF, the setup lives in a foreman's memory, and the only durable artifact is paper in a truck. When a claim surfaces months later there is nothing to reconstruct from — and claims do surface, because the underlying risk is real. The Work Zone Safety Information Clearinghouse records 850 work zone fatalities in 763 fatal crashes in 2024, and non-fatal incidents and property damage events are far more numerous and are not captured in any national dataset at all.

Equipment and inventory that understands deployment

Devices have a location, a status, and often a rental clock. Multi-yard companies need to know what is where without calling the yard.

The questions that separate real capability from a checkbox: can equipment be assigned to a job and tracked as deployed rather than consumed; can a rental accrue and renew automatically; can you see what is on a site right now; and can you reconcile what went out against what came back, which is where equipment losses actually get caught.

Companies that cannot answer the last one lose devices continuously and discover it at inventory time, by which point attribution is impossible.

Dispatch that shows crew, equipment, and credentials together

A dispatcher assigning tomorrow's work needs three things on one screen: who is available, what equipment is free, and whether the people being assigned hold the credentials that job requires.

That third item is the one usually missing, and it is a compliance exposure. Flagger credentials expire, and acceptance rules differ by agency. If the dispatcher has to open a second system to check, they will check when they remember. If a job can be staffed with an expired credential without the system objecting, eventually it will be — and the exposure is real, because OSHA's construction standard at 29 CFR 1926.201(a) requires that flagging and flagger warning garments conform to Part 6 of the MUTCD, and agencies commonly want documented proof of training as evidence of that conformance.

GPS time clock tied to jobs

Labor is the dominant cost. Time that is not attributed to a job cannot be job-costed, and a company that cannot job-cost cannot tell profitable work from unprofitable work — it can only see whether the month was good.

Tying clock events to a job and a location also resolves the most common billing argument, which is not fraud but ambiguity about arrival and departure times.

Quotes and invoices that survive the trip

Traffic control quoting has structure a generic quote builder handles poorly: recurring rentals alongside one-time mobilization, crew rates by classification, per-device pricing, and jobs that extend. Look for a quote that becomes a job without re-entry, and a job that becomes an invoice pulling from actual tickets rather than from the original estimate.

Accounting and payment integration

QuickBooks Online is the common denominator for companies of this size. Card payment matters more than people expect, because it shortens the collection cycle on the smaller commercial jobs that would otherwise sit in receivables.

The question to ask is what actually syncs — customers, invoices, payments, items — and in which direction. "Integrates with QuickBooks" covers an enormous range of actual behavior.

A customer portal, if you do commercial or municipal work

Repeat clients asking for job status and copies of tickets is a real support load. A portal converts a phone call into a self-service lookup, and it also functions as a quiet trust signal — a client who can see the documentation is a client less likely to dispute it.

The compliance requirements your software has to serve

It is easy to evaluate operations software purely on convenience — how fast a ticket is, how clean the dispatch board looks. That undersells what the system is actually for. In this industry the records your software holds are the records two different authorities may eventually ask to see, which means the compliance side should be an explicit evaluation criterion rather than an afterthought.

Two documents define the floor.

The traffic control side is Part 6 of the Manual on Uniform Traffic Control Devices, covering temporary traffic control. The current national edition is the MUTCD 11th Edition, published by FHWA in December 2023 and now carrying Revision 1 dated December 2025, with Part 6 published in full at no cost. Section numbering shifted from the 2009 edition, so any internal template still citing 2009-era sections is citing sections that have moved — worth checking if your software carries plan templates or checklist content.

The occupational side is 29 CFR Part 1926 Subpart G, which incorporates that manual by reference and makes conformance enforceable against the employer. OSHA collects its guidance on a highway work zones topic page. The practical consequence is that a single field setup can be judged by the roadway agency against the approved plan and by OSHA against the manual, with different enforcement consequences — and "the agency inspector signed off" is not a defense on the worker-protection side.

Requirements also vary by state, county, and city. States adopt their own manual versions and agencies layer permit conditions on top, so nothing here substitutes for the requirements of the authority having jurisdiction over a specific roadway.

Why this belongs in a software evaluation: the exposure is not theoretical. FHWA reports 891 work zone fatalities in 2022 and 963 in 2021, with the crash-type breakdown showing speeding as a factor in 281 of 821 fatal crashes and rear-end collisions in 174 of them in 2022. On the worker side, the same source records 94 highway construction worker occupational fatalities in 2022 and 108 in 2021, drawn from the Census of Fatal Occupational Injuries published by BLS.

Those numbers describe fatalities only. Injuries, property damage, and near misses are far more common and appear in no national dataset at all — which means the only record of them that will ever exist for your company is the one your own system captures.

So the concrete evaluation questions are: can the system show what was set up, when, and by whom, for a job that ran eighteen months ago? Can it show that the people assigned held current credentials on the day they worked? Can it produce that as a document an agency or an attorney will accept, without someone reconstructing it from memory? A platform that handles dispatch beautifully and cannot answer those three is solving the easier half of the problem.

Pricing structure, and the incentive it creates

Most software in this category is priced per user per month. That is worth thinking about structurally rather than just arithmetically.

Traffic control headcount is seasonal and field-heavy. A company with twenty office and full-time staff might run sixty people in peak season. Under per-user pricing, every additional field person has a marginal cost attached to giving them access.

The predictable consequence: companies limit who gets access. Crews share a login. Field staff are left off the system and their foreman enters everything after the fact. Both of those destroy exactly the field data the system exists to collect — and they do it invisibly, because the software still works, it is just being fed reconstructed information.

Flat-tier pricing removes that incentive. Everyone gets access because access is free at the margin, and the field data is captured by the people who were actually there.

Traffic OS is priced in flat tiers at $499, $949, and $1,499 per month for this reason. Details are on the pricing page.

When comparing, model both structures at peak-season headcount, not today's. And when you evaluate a competitor's pricing, read it off their own public pricing page and note the date you looked — vendor pricing changes, and a number repeated from a blog post is a number you cannot defend in a board meeting. Where a competitor does not publish pricing, the honest characterization is that they do not document it publicly, not that it is expensive.

We maintain comparison pages for the platforms that come up most often in these evaluations, including ServiceTitan and Jobber. They are written to be usable by someone who ends up choosing the other product.

Questions vendors would rather you not ask

What happens with no cell signal? Work zones are frequently in places with poor coverage. Ask whether the field app queues offline and syncs later, or simply fails. Then ask what happens to a signature captured offline. This is the question that most often reveals the difference between a mobile web page and a real field application.

Who owns the data, and how do we get all of it out? Not a report — a complete export of jobs, tickets, customers, equipment history, and attachments, in a usable format, without a fee. A vendor that cannot answer this cleanly is describing a switching cost.

What does implementation actually require from us? In hours of your staff's time, not in vendor-side effort. Data migration, configuration, and training are real costs that never appear on a pricing page.

Has the field app been used by crews doing this work? Not field service generally. This work. Ask what specifically was changed because traffic control crews asked for it.

What is on the roadmap that we would need? And separately: what have you decided not to build? A vendor with no answer to the second question is telling you they will say yes to anything, which is not reassuring.

Be skeptical of any vendor claiming uptime figures or service levels without a published status page or a contractual document behind them, including us — if a number is not written down somewhere you can point at, treat it as marketing.

Running an evaluation that survives your crews

The most common way this goes wrong: the office staff evaluate software in a conference room, choose it on features, and discover after purchase that the crews will not use it.

A structure that avoids that:

Write down your five hardest requirements before you see a demo. Anchor on them. Demos are optimized to be impressive, and it is remarkably easy to leave one enthusiastic about capabilities you will never use.

Put a foreman in the evaluation. Not to approve — to try. Have them complete a daily ticket on a phone, outdoors, and time it. Compare honestly against the paper ticket book.

Run real jobs through a trial. A handful of actual jobs from quote through ticket through invoice will surface more than any demo. Include a multi-day job with equipment on site, since that is where general platforms break.

Test the ugly cases. A job that extends. A change order mid-week. Equipment that comes back short. A ticket signed by someone whose name is not in the system. These are the ordinary situations that determine whether the software is workable.

Ask what the office actually stops doing. If nobody's manual work disappears, the software is an additional system rather than a replacement, and the total workload just went up.

What to expect realistically

Some honest calibration.

Implementation takes longer than anyone plans, mostly because data cleanup takes longer. Your customer list and equipment inventory are messier than you think, and this is where you find out.

Adoption is a supervision problem, not a software problem. Crews adopt tools that make their day easier and route around tools that do not. If a foreman has to do the ticket twice — once in the app and once on paper because the office does not trust the app yet — they will stop doing it in the app within a week.

The first real benefit usually shows up in billing speed rather than in labor savings. Tickets that used to arrive Monday for work done Tuesday arrive the same evening, and the invoice goes out days earlier. That cash-cycle improvement is typically what pays for the software long before any efficiency gain does.

And nothing here makes a work zone safer by itself. The cones do not care what you run. What software can do is make the setup, the crew, and the equipment on a given day into a record — so that patterns become visible and disputes become answerable. That is a real benefit and a bounded one, and any vendor promising more than that, us included, is overselling.

If you want to see the ticket and dispatch flow on real screens rather than in screenshots, book a walkthrough. If you would rather read first, the features overview covers what is actually in the product.