What's broken about modern freight brokering

We’ve spent the last eighteen months talking to operators — shippers, brokers, 3PLs, dispatchers, ops managers, controllers, CFOs — about what their freight stack actually looks like and what they wish it looked like. The same five problems came up in every conversation.

1. The pricing layer is opaque on purpose

The traditional brokerage business model depends on the customer not knowing the carrier rate. That’s why you get a flat “all-in” price with no breakdown. That’s why your invoice shows fuel surcharge as a percentage but doesn’t cite the index. That’s why accessorial reweighs and reclasses get added without notice. The opacity is not a bug. It’s the moat.

The fix is structural: pass-through pricing with an itemized fee. You see the carrier rate, you see our fee, you decide. No mystery.

2. The TMS is a system of record, not a system of work

Most TMS platforms were designed in the 2000s to capture data after the fact — a digital filing cabinet for shipments, BOLs, and invoices. They’re terrible at the actual work: rate shopping, exception handling, claim management, carrier scorecarding. So operators end up with a TMS plus three other tools plus six spreadsheets plus a Slack channel.

The fix is a TMS that’s a system of work first, system of record second. Booking, tracking, claims, billing, all in one place, all programmable.

3. The data exists but doesn’t flow

Carriers know when your shipment is picked up. Carriers know when it’s damaged. Carriers know when it’s late. That information exists in carrier APIs and on carrier scorecards. It rarely makes it into your TMS in real time, never makes it into your customer’s portal in real time, and definitely never triggers the right exception workflow automatically.

The fix is event-driven plumbing. Every carrier callback becomes a webhook becomes a state transition becomes a notification becomes (when needed) a human task in the ops queue. No batch jobs. No 4 a.m. CSV imports.

4. Claims are a black hole

Industry estimate: 60 to 70% of cargo claims that should be approved get either denied, partially paid, or just abandoned because the paperwork is too painful. The OS&D report doesn’t make it from the dock worker to the broker to the carrier with the photos and the BOL and the inspection report intact. The claim sits. Eventually the customer eats it.

The fix is a claim workflow that captures the evidence at the dock — photos, signatures, OS&D codes — and then runs the carrier claim end to end with deadlines, escalations, and outcomes tracked. It should not take six weeks to find out a $400 claim got denied.

5. The buyer experience is from 2008

Most freight platforms were built for the carrier-facing dispatcher and bolted a customer portal on later. The portal is read-only, the rate request is a form that emails a human, and the “quote” arrives an hour later via reply-all. Modern shippers — especially those running e-commerce or DTC — expect software that behaves like Stripe: quote, book, track, manage all in self-service, with API parity.

The fix is treating the shipper as the primary user. Self-serve rate shop. Self-serve booking. Self-serve claims. API for everything. Account-team support for the things that actually need a human.

Why this is fixable now

The structural enablers showed up in the last 36 months:

• Most major LTL carriers now expose real APIs (some good, some bad, all there).
• Parcel APIs (USPS, UPS, FedEx) became reliable enough to build on without a fallback fax machine.
• LLMs let us extract structured data from the messy edges — BOLs, OS&D reports, customer emails — at a cost that finally pencils.
• Postgres got so good that “a single platform handling rate shop, booking, tracking, claims, and billing with sub-second queries on 50M shipments” is just a normal Tuesday now.

The pieces are on the table. The opportunity is to put them together with a fresh product mindset and ship faster than the incumbents can refactor. That’s the bet we’re making.