How Barricade Companies Track Which Devices Are on Which Job Site

Short answer: barricade and traffic control companies track devices by anchoring inventory to a deployment record — a job, a counted quantity, a placed-on date and a picked-up date — instead of to a warehouse quantity. Software built on that model (Traffic OS is one, priced in flat monthly tiers from $499 to $1,499 as of July 2026) can answer "what is at the Highway 287 closure right now" and "what did we never get back" from the same data. Systems built on warehouse quantities can answer neither.

The rest of this is why that distinction matters more in this trade than in almost any other, and what to check before you buy anything.

The question that exposes your current system

Ask whoever runs your yard: right now, without walking outside, how many Type III barricades are at the Loop 12 job?

There are roughly four answers, and they map neatly onto the four systems companies actually run.

"I'd have to call Danny." The inventory lives in a crew leader's head. This works at one or two crews and stops working the day Danny takes a week off.

"Let me open the spreadsheet." Someone maintains a deployment tab. The number is real but it is as of the last time someone updated it, which is usually the last time somebody asked.

"We have 200 barricades, and 140 are out." This is warehouse-quantity thinking. You know the aggregate. You cannot bill a specific customer for a specific device-day, and you cannot tell which of five open jobs is holding the sixty you need tomorrow morning.

"Twenty-two, placed March 4, phase two picks up Friday." That is the answer the business actually needs, and it only comes from a system where the device record and the job record are the same record.

Why this is harder in traffic control than in general rental

General equipment rental has a mature software category, and traffic control companies often try it first. It fits badly for reasons that are structural rather than cosmetic.

The unit is a mixed set, not an asset. A general rental system is built around a scissor lift: one serialized asset, one contract, one customer, out and back. A lane closure is forty drums, twelve Type II barricades, six signs on portable stands, one arrow board, and a hundred cones — deployed together, billed on different terms, retrieved in phases. Modeling that as forty-one separate contracts is technically possible and operationally absurd.

Devices move between jobs without coming home. Crews routinely pull devices off a finishing job straight to the next one. If your system can only record a return to the yard, every direct transfer either gets falsified as a return-and-redeploy or does not get recorded at all. Both corrupt the location data, and the second corrupts the billing.

Deployment duration is a regulated variable, not just a commercial one. The MUTCD defines work duration in five categories, and the device requirements change with them. Work occupying a location for more than 3 days is long-term stationary, while short duration is work that occupies a location up to 1 hour (Section 6N.01, 11th Edition). The manual is explicit about the consequence at the long end: "Since long-term operations extend into nighttime, retroreflective and/or illuminated devices shall be used in long-term stationary TTC zones." How long a device has been out is therefore simultaneously a billing fact and a compliance fact. Very little general rental software treats it as both.

Loss is continuous and diffuse. Cones get run over. Drums walk. Signs get taken. A general rental system built to expect one asset back from one customer has no concept of "we sent 120 cones and got 104 back, on a job that ran nine days across two crews."

The data model that works

The organizing idea is small: the atomic record is a deployment, not an item and not a job.

A deployment carries, at minimum:

• the job or site it belongs to
• the device type and the counted quantity (or the serial, for tracked assets)
• who placed it and when
• who retrieved it and when
• the billing basis — daily, weekly, monthly, or included in the job price
• condition notes and photos at pickup

Everything useful falls out of that one record.

Where is my stuff? Sum open deployments by site.

What is available Thursday? Owned quantity minus open deployments, minus deployments scheduled but not yet placed.

What do we bill? Placed-on to picked-up, on the deployment's billing basis. No one reconstructs it later.

What did we lose, and on whose job? Counted out minus counted back, attributable to a specific deployment with a specific crew and a specific date.

Is this device compliant for how it is being used? Duration is already on the record, so a deployment crossing into long-term stationary can be flagged before someone else flags it for you.

Notice what is absent: a separate "inventory module" that has to be reconciled with the job records. The reconciliation problem exists because the data was split in the first place.

Serialize the expensive things, count the cheap ones

The most common failed implementation is the one that tries to individually tag everything. A crew that has to scan 140 cones at 5:40 a.m. will stop scanning cones by the second week, and then the system's numbers are worse than the spreadsheet's because everyone still believes them.

A workable split:

Serialize and track individually: arrow boards, portable changeable message signs, portable traffic signals, AFAD trailers, attenuator trailers, light towers, generators — anything with a maintenance history, a compliance certification, or a replacement cost worth arguing about. These typically also need service records, and the serial is what those hang on.

Count in groups per deployment: cones, drums, tubular markers, vertical panels, Type I/II/III barricades, sign panels and stands. Track the type and the quantity on the deployment, not the identity of each unit.

Track by condition tier where it pays: some companies keep two pools of barricades — job-ready and needs-refurb — and move counts between them at pickup. That is usually enough granularity to manage refurbishment without individual identity.

The economic test is simple: individual tracking is worth it when knowing which specific unit changes a decision. For an arrow board it does — it has a service history and a certification. For a cone it does not.

Why crashworthiness makes the asset register a compliance record

There is a second reason to know exactly what devices you own, beyond knowing where they are.

Traffic control devices used on roads open to public travel are subject to crashworthiness requirements. The MUTCD states that "various Sections of the MUTCD require certain traffic control devices, their supports, and/or related appurtenances to be crashworthy," and that these provisions "apply to all streets, highways, and site roadways open to public travel" (Section 6A.04). The eligibility framework for that hardware — including the transition to the AASHTO Manual for Assessing Safety Hardware — is maintained in FHWA's roadside hardware policy memoranda and guidance.

The practical consequence for a rental fleet: devices of the same visible type can differ in eligibility depending on when they were made and to what standard they were tested. A yard that knows only "we have 200 barricades" cannot answer an agency's question about what it is deploying. A yard whose asset register carries acquisition date, manufacturer and test standard for the categories where that matters can answer it in a minute.

This is not an argument for tagging cones. It is an argument for the asset register being real for the categories where an agency, a prime contractor, or an insurer may eventually ask.

The pickup reconciliation is the whole ballgame for loss

Every rental-heavy company loses devices. The ones that manage it well are not the ones that lose fewer at first — they are the ones that find out immediately.

The mechanism is boring: count out, count back, at the moment of each.

A crew placing a deployment records the counted quantity as they place it. A crew retrieving records the counted quantity as they load. The delta is computed on the spot and shown to the person who just did the counting, while they are still standing at the site and can go look behind the guardrail.

Compare that to the common alternative — an annual or quarterly physical count. The count tells you that you are 340 cones and 26 drums short over the year. It tells you nothing about which jobs, which crews, which customers, or which sites are the problem, and it arrives far too late to charge anyone for it.

Two refinements worth building in:

Photograph damage at pickup, not at the yard. A photo taken at the site, timestamped and geotagged, is evidence attached to a specific job. The same damage discovered three days later in the yard is an argument.

Make partial pickups first-class. Phase-based work means devices come back in tranches. A system that only supports closing a deployment entirely will teach crews to record the final pickup and nothing before it, which destroys both your availability picture and your rental accuracy for weeks at a time.

What this is worth, and why it is not primarily about the devices

The recovered device cost is real but it is usually the smaller half. The larger half is billing.

For rental-heavy operations, the deployment record is the rental invoice's source data. When device tracking and billing are the same system, the invoice reflects what actually happened in the field. When they are separate — a yard spreadsheet plus an accounting package — the invoice reflects what someone remembered at month end, and the errors are asymmetric: you rarely over-bill by accident, because the customer catches those. You under-bill silently, forever.

The second-order cost is dispatch. A dispatcher who cannot trust the availability number pads every job, which means buying inventory to cover uncertainty rather than demand. That capital sits in the yard permanently.

And the third is scale. All of the human-memory approaches work at three crews. They fail at eight, and they fail in a specific way — the failure looks like "we need to hire another person in the office," when what is actually happening is that the coordination cost of untracked equipment has grown faster than the revenue.

What to test before you buy anything

Run these five against any product, including ours. They are chosen because they fail loudly on systems that model equipment as a warehouse quantity.

1. "Move 20 drums from Job A directly to Job B without returning to the yard." Watch whether this is one action or a fake return followed by a fake dispatch. If it is the fake pair, every direct transfer in your business will be a small lie in the data.

2. "Show me a job where we sent 120 cones and got back 104." Then ask where the 16 appear: as a loss on that job, as an inventory adjustment with no job attached, or nowhere. Only the first is useful.

3. "This closure has been out 40 days and bills monthly. Show me what has been invoiced and what is accrued but unbilled." Rental revenue recognition is where these systems are honest or are not.

4. "It is 5:30 a.m. and I need 40 Type II barricades today. What do I have and where is it?" Time how long it takes, and note whether the answer accounts for deployments scheduled for later today.

5. "Show me every deployment currently past 3 days at one location." This is the MUTCD long-term-stationary line. A system that cannot filter on deployment age is not modeling duration at all.

Where the stakes actually sit

It is worth remembering why the compliance side of this is not paperwork. Work zones remain a genuinely dangerous environment: FHWA's work zone statistics record 891 work zone fatalities in 2022, including 94 highway worker fatalities, down from 963 total and 108 worker fatalities the year prior. The National Work Zone Safety Information Clearinghouse puts the broader economic burden at roughly $41 billion in comprehensive societal crash costs in work zones for 2024, alongside an estimated $8.6 billion in user delay costs.

Knowing what devices you own, what condition they are in, and how long they have been deployed is not an accounting nicety in that context. It is the difference between a work zone built the way it was designed and one built out of whatever was on the truck.

OSHA's own construction rule points the same direction by pointing outward: 29 CFR 1926.201(a) requires that flagger signaling "conform to Part 6 of the MUTCD," and OSHA's highway work zones page sends employers to the MUTCD for sign, barricade and flagging requirements generally. Your equipment records are how you demonstrate you did.

A note on editions, because it will bite someone

The MUTCD is currently in its 11th Edition, effective January 18, 2024, with Revision 1 effective March 5, 2026. The 11th Edition renumbered Part 6: high-visibility apparel, for instance, is Section 6C.05 in the 11th Edition, while much published guidance still cites the 2009 Edition's 6D.03. Meanwhile OSHA's construction standards incorporate an earlier MUTCD edition by reference.

None of that changes what you should do in the field. It changes what a citation in your own documents should say. If your internal procedures reference MUTCD sections by number, they need an edition stamp next to them, and they need reviewing against the edition your state has actually adopted. Requirements vary by state, county and city, and the authority having jurisdiction is the one whose answer counts.

Starting from where you are

If you are on spreadsheets today, do not begin by tagging assets. Begin by making deployments two-sided: nothing goes out without a counted quantity and a job, and nothing is closed without a counted return. That single discipline produces most of the value, and it works on paper for a few weeks while you decide what to buy.

Then look at what your current tooling can and cannot express. If the equipment side of your operation lives in a spreadsheet alongside dispatch, the migration path off spreadsheets is worth reading before you shop, and the rental-specific requirement set is laid out in the barricade rental management software guide. If you are still setting rates for the devices themselves, that is a separate exercise covered in traffic control device rental rates.

Traffic OS models exactly the deployment record described above, and prices in flat monthly tiers rather than per user — which matters when the people who need to record a count are seasonal field staff. If you want to run the five tests above against real data, bring your worst reconciliation to a walkthrough. The broader evaluation framework, including the parts where general platforms are the right answer, is in the dispatch software buyer's guide.