CRM for Traffic Control Companies: What to Track About Customers, Contacts and Bids

Ask a traffic control owner who their customers are and you will get a list of a dozen names. Ask who at each of those companies calls in the work, who signs the ticket on site, and who approves the invoice, and the answer is usually "it depends who you ask in my office."

That gap is what a CRM is for in this trade. This guide covers what a customer record needs to hold for a traffic control or barricade company, why sales-team CRMs fit poorly, and how the customer record should connect to quoting, dispatch and billing.

A different kind of customer

Most CRM software was designed around a sales funnel: many leads, a few of which become one-time buyers. Traffic control works the other way round.

Few accounts, many people. A mid-sized company may do most of its revenue with ten or twenty accounts. Each account has an estimator who asks for prices, project managers who schedule the work, superintendents and foremen who sign tickets, and an accounts payable clerk who decides when you are paid. Losing track of which person does what is how an invoice sits unapproved for six weeks.

Work repeats. The same paving contractor calls every week from April to November. The value of the relationship is in the pattern: what they usually need, which crew they like, what went wrong last time.

Prices are negotiated per account. A master agreement or rate sheet sets what each customer pays for a flagger hour, an arrow board day and a callout. See master service agreements and rate sheets. A quote built from the wrong rate sheet is an argument waiting to happen.

Roles overlap. A general contractor may be your customer on one project and a competitor's customer on the next. A city may be the permitting agency and the customer at once.

Public work has its own calendar. Agencies publish bid opportunities on fixed schedules. Federal opportunities are posted on SAM.gov, and state DOTs publish their own letting schedules, as TxDOT does on its contract letting page. The primes bidding those projects are the ones who will need traffic control prices before bid day.

A CRM that treats each of these as a "lead" with a "stage" misses what matters.

What the customer record needs to hold

Think of it as the file a new dispatcher would need to serve the account properly on their first day.

The account. Legal name, billing address, tax status, payment terms and credit limit. If you run a credit application process, the result belongs here. See credit applications and payment terms for traffic control customers.

Every contact, with a role. Name, mobile number, email and what they do: requests work, signs tickets, receives invoices, approves payment. One account with one contact field is not enough.

Rates and terms. The current rate sheet, minimum hours, standby and cancellation terms, and when the rates were last changed.

Compliance items. Their insurance requirements, vendor packet expiry dates, safety orientation requirements for your crews, and any site rules.

Quotes. Every quote sent, with amount, date, version and outcome.

Jobs. What you have done for them, where, with which crew.

Money. What they owe, how long they usually take to pay, and any disputes.

Notes. The things people otherwise carry in their heads: "always wants a call the night before," "superintendent will not sign after 3 p.m."

For agency customers, add the permit facts: notice periods, restricted hours, and who to call. Our post on multi-jurisdiction permit tracking covers that record.

The pipeline that actually exists

A traffic control company does have a sales pipeline. It just looks different from a software company's.

1. A request arrives. By phone, text or email, often with a plan sheet attached. Record it against the account and the contact on the day it comes in. Unrecorded requests are the ones that get quoted twice or not at all.
2. A quote goes out. With a version number. Customers change dates and scope, and "which quote did they accept" should never be a question. See quoting traffic control jobs faster.
3. It is accepted, declined or goes quiet. Record which. A quiet quote deserves one follow-up.
4. Accepted work becomes a job. Ideally without anyone retyping the customer, the address or the line items.
5. The job produces tickets, and tickets produce an invoice. Sent to the contact whose role is to receive it.

Stages 3 and 4 are where separate systems leak. If the quote lives in one tool and dispatch in another, somebody copies it across, and the rate or the start date changes in the copy.

Recording outcomes pays off over a season. The Small Business Administration's guidance on market research and competitive analysis makes the general case for knowing who buys from you and why. In this trade the practical version is a win rate by customer and by job type. Our post on tracking bid win rate explains what to do with it, and bid/no-bid decisions covers when to stop quoting an account that never buys.

Why generic CRMs fit badly

A stand-alone sales CRM can store accounts and contacts. The trouble starts at the edges.

• It does not know what a job is. There is no crew, no equipment, no ticket. The sale "closes" and the record ends just when the real work begins.
• It charges a full price per seat. The people who most need to see the customer record are dispatchers and crew leads, and paying a sales-seat price for each of them discourages giving them access. See per-user vs flat-tier pricing.
• It duplicates data. The customer exists in the CRM, in dispatch and in accounting, spelled three ways.
• Its reports answer the wrong questions. Lead conversion rates matter less here than days-to-pay and revenue per account.

Field service platforms include a customer module, but most were designed around a homeowner with one address and one phone number. Our comparisons with ServiceTitan and Jobber describe where that model strains for contractor-to-contractor work.

What to look for

If you are choosing a system, test it with one of your real accounts.

• Can one account hold many contacts with different roles?
• Can each account have its own rate sheet, and does a new quote pick it up automatically?
• Does a quote keep its versions after it is accepted?
• Does an accepted quote become a job without retyping?
• Can a dispatcher see the customer's notes and site contact from the job?
• Does the invoice go to the billing contact by default?
• Can the customer see their own tickets and invoices without calling you? See customer portals for traffic control companies.
• Can you export everything if you leave? See data ownership and export.

Traffic OS includes a CRM with multi-contact accounts, quotes with version tracking after acceptance, and a customer portal, inside the same system that handles dispatch, tickets and inventory. The feature list shows the whole set, and pricing is by flat monthly tier with seats included. That is the idea behind calling it a traffic management operating system: one record for the customer, from first call to final payment.

Getting started without a big project

You do not need to load ten years of history.

1. List your active accounts. The ones you have worked for in the past twelve months.
2. For each, write down the contacts and their roles. This is the step that pays first.
3. Attach the current rate sheet and terms.
4. Start recording every request and quote from today. Do not go back.
5. Review once a month. Which accounts are growing, which are slow to pay, which quotes went quiet.

Within one season you will know things about your customers that used to live in one person's phone. If that person takes another job, the company keeps the knowledge. Our guide to winning repeat traffic control work covers what to do with it.

To see multi-contact accounts and quote versions working with your own job types, book a walkthrough.