Dispatch is still a phone problem

Freight has spent a decade building APIs. Load boards have them. TMSs have them. Brokers have them. And the load still gets booked because a dispatcher called a broker, waited on hold, negotiated forty dollars, and wrote a number on a pad.

That gap is the whole business.

Why the phone wins#

The phone is not winning out of nostalgia. It wins because the information that decides a booking is not in the posting:

• Whether the shipper actually loads at 6am or at 11am
• Whether the broker will move on rate if you can commit right now
• Whether detention gets paid without a fight
• Whether this lane's receiver takes three hours to unload

None of that is a field. All of it is the difference between a load that pays and one that doesn't.

What that means for software#

If you accept that the call is where the work happens, the interesting problem stops being "how do we surface more loads" and becomes "how do we make one dispatcher able to have forty conversations."

Those are very different products. The first is a search box. The second has to hold context across calls, remember what a broker said last Tuesday, and know when a rate is worth pushing on.

The part nobody budgets for#

Every carrier we work with underestimates the same thing: how much of dispatch is re-dispatch. The load falls through. The driver runs out of hours. The receiver closes early. The original booking was maybe 30% of the work.

Automating the first call and leaving the other four is not much of a win. The system has to own the thread, not the transaction.

We stopped describing what we do as booking loads. We describe it as holding the conversation. It is a less impressive sentence and a much more accurate one.