What should a freight brokerage CRM track?
A freight brokerage CRM should track the relationship, not just the activity: every shipper as a parent company with its plants and locations underneath, its lanes, spot quotes and contract bids in separate pipelines, the quote history, and load data from the TMS on the account. Carriers and RFPs need their own records too.
Most brokerage CRMs I walk into are activity logs. Calls, emails, a note that says "left VM." Reps are told to log everything, and the CRM still can't answer the questions the CEO actually asks. Which shippers are growing? Which ones are going quiet? Where did we lose the bid, and to what rate?
Here's the line I use with every logistics client, and I stole it from a whiteboard session at Worldwide Logistics (WWL): the CRM shows effort. The TMS shows outcomes. A good brokerage CRM puts both on the same screen.
The common advice is "get your reps to log more." That's backwards. Reps in freight are busy covering loads and putting out fires. If the CRM only works when they type, it will always be behind. The fix is a data model that matches how freight is actually sold, plus the outcome data your TMS already has.
What records does a freight brokerage CRM need?
A brokerage CRM needs six kinds of records: shipper companies, their locations, the people, lanes, quotes and carriers. Each one answers a different question, and when any of them is missing, reps fill the gap with spreadsheets and inboxes.
When we walked through the sales process at WWL, the gaps were familiar. The old CRM was Microsoft Dynamics with manual logging. There was no parent and child structure, so a shipper with five distribution centers showed up as five unrelated companies, or as one record that hid four of them. There was no log of past quotes. And the contact data reps were buying was only 50 to 60% accurate, so reps spent about 30% of their time vetting contacts instead of selling.
Here's the structure we use now:
- Shipper (parent company). The account a rep owns and the level where revenue potential lives.
- Locations (plants, distribution centers, warehouses). Each one is a child of the parent. This is where shipper IDs from the TMS attach, and it's how reps see that a customer just opened a new site.
- Contacts. Tied to the location they actually ship from, not just the parent.
- Lanes. Origin, destination, mode and typical volume. Lanes are what you actually sell.
- Quotes and bids. Spot quotes and contract bids, each in their own pipeline (more on that below), with every revision kept.
- Carriers. A separate object with the carrier's DOT number as the unique ID, so the same carrier is never entered twice.
On this page
A brokerage CRM pulls scattered freight data onto one account
Where it lives today
- TMS: loads, lanes and shipper IDs
- Inboxes: RFPs and quotes
- Spreadsheets: rates and contacts
- Carrier records and DOT numbers
One brokerage CRM
- Shipper (parent company)
- Locations, each with its shipper ID
- Contacts by location
- Lanes
- Spot quotes and contract bids
- Carriers keyed on DOT number
Summaries from the TMS, not every load
What people see
- Volume trend per shipper
- Locations not yet won
- Quote history and win rate
- An alert when a shipper goes quiet
The parent and child piece matters more than people expect. At WWL, mapping it meant matching 1,219 shipper IDs from the TMS to the right parent companies. It's the difference between a rep saying "we do some business with them" and a rep saying, for example, "we move freight for four of their six plants, and here are the two we don't."
Should spot quotes and contract bids live in the same pipeline?
No. Spot quotes and contract bids are different sales motions, so they need two pipelines. A spot quote is won or lost in hours on price and capacity. A contract bid is an RFP that runs for weeks, with rounds, an award and a start date.
Put them in one pipeline and two bad things happen. Your forecast mixes a same-day spot load with a year-long contract award, so the number means nothing. And the stages never fit either motion, so reps stop moving deals and the pipeline goes stale.
Spot quotes and contract bids are two different sales motions
| Question | Spot quote | Contract bid |
|---|---|---|
| What wins it | Price and capacity today | Rates, service and the relationship |
| How long it runs | Hours | Weeks, in rounds |
| Stages | Requested, quoted, booked or lost | RFP received, rounds, award, start date |
| What to keep | Rate, lane, outcome and reason lost | RFP file, round feedback, award file |
| Forecast use | Run rate by shipper and lane | Awarded volume and start dates |
Contract bids also need a home for the RFP itself. On WWL's carrier sourcing team, RFP details lived in distribution lists, personal inboxes and desk visits, and the team asked for the same round one feedback four times. When the RFP, its rounds, the award file and the feedback all sit on the bid record, nobody has to ask again. The CRM sends the alert instead of a person walking over.
How do you get TMS data into the CRM without building a second TMS?
Bring summaries, not every load. The CRM should show each shipper's loads, trends, mode and volume over time, keyed on the shipper ID, so a rep can see the shape of the relationship. The TMS stays the system that runs freight.
Two rules keep this sane:
- Start with a sample. At WWL we analyzed a 14 to 30 day sample of TMS data before designing anything. It showed which fields were reliable, which shipper IDs mapped cleanly and which numbers reps would actually use.
- Key everything on the shipper ID. Names change, get misspelled and get abbreviated. IDs don't. When the ID lives on the location record, every load lands on the right account automatically.
Then the CRM can answer outcome questions. Which accounts are shipping less than last quarter? Which lanes grew? Which shippers quote often but rarely book? None of that needs a rep to type anything.
The same structure fixes back office pain too. At WWL, credit checks were being copied by hand across D&B, the CRM and the TMS. We moved onboarding to trigger at the Verbal Commit stage, so credit and setup start the moment sales knows the deal is real.
How do you know which shipper is about to go quiet?
You watch the outcome data and alert on it. When a shipper's volume drops, or replies slow down, the CRM should tell the account owner before the revenue is gone, not after the quarterly review.
This is where AI earns its keep. WWL's daily AI digest goes to about 153 users and surfaces $10K to $100K of freight a day that needs attention before it escalates. Median customer reply time went from 9.32 to 6.27 business minutes, measured with a custom timer on email replies, because "we're fast" isn't a number. The full story is in the WWL case study.
None of that works on a CRM that only knows about phone calls. The digest is only as good as the data model under it.
What should you leave out of the CRM?
Leave out history nobody will use. When you move to a new CRM, migrate active accounts, open deals and the relationships reps rely on, and archive the rest where it can be searched.
When WWL left Dynamics, the activity export was, in their words, atrocious. Only about 20% of accounts had any logged emails at all. Migrating all of it would have built what we call a digital graveyard: thousands of old records that make search slower and reports wrong. Instead, we archived the history, migrated active deals and had reps re-associate the email threads that were still live.
Also leave out fields nobody owns. Every field should have a reason, a source and a person or system that keeps it current. If you can't name all three, it doesn't go in.
What goes wrong when brokerages set up a CRM?
The same four mistakes show up again and again:
- Copying the old system. Moving from a transactional tool to a relationship CRM field by field brings the old problems along. Redesign around shippers, lanes and quotes instead.
- One pipeline for everything. Spot and contract in one funnel makes the forecast useless.
- No IDs. Without shipper IDs and DOT numbers as keys, duplicates creep in and TMS data never lines up.
- Asking reps to do the integration. If a rep has to copy load data from the TMS into the CRM, it won't happen. Connect the systems, then train people on the result.
Frequently asked questions
Can we do this in Salesforce or Dynamics instead of switching CRMs?
Yes. The data model matters more than the brand of CRM. Parent and child accounts, separate pipelines for spot and contract work, a carrier object keyed on DOT number and TMS summaries keyed on shipper ID can all be built in Salesforce, Dynamics or HubSpot. Switch only if your current CRM can't support the model or your team has stopped using it.
Do carriers belong in the same CRM as shippers?
Usually, yes, as their own object. Carrier sourcing and capacity teams need the same things sales does: a clean record, history, and alerts when something changes. Keeping carriers in the CRM, keyed on DOT number, lets you see which carriers cover your top lanes and stops the same carrier being entered several times by different people.
How much TMS data should we bring into the CRM?
Bring the summaries reps and leaders use to make decisions: loads, volume trends, mode and lanes per shipper and location. Leave individual load execution in the TMS. Start with a short sample of real data to see which fields are reliable, then decide. More data isn't better if nobody trusts it.
Our contact data is wrong half the time. What do we do about it?
Stop asking reps to fix it by hand. When a large share of purchased contacts are wrong, reps quietly spend their week vetting instead of selling. Enrich and validate contacts before they reach the rep, tie each contact to the location it ships from, and flag records that fail validation instead of loading them.
Sources
- Worldwide Logistics (WWL) sales walkthrough, TMS discovery, shipper architecture, carrier sourcing and Dynamics migration sessions, 2025 to 2026: contact accuracy of 50 to 60%, about 30% of rep time spent vetting, 1,219 shipper IDs mapped, the 14 to 30 day TMS sample and the 20% of accounts with logged emails.
- WWL case study and the WWL AI briefing story: digest reach of about 153 users, reply times from 9.32 to 6.27 business minutes and $10K to $100K of freight a day surfaced.
- RevOps Shop discovery work with logistics companies including 3PLs, brokers and forwarders, 2026.