Give Shippers Somewhere to Look and They'll Stop Calling
Most 'where's my freight' calls aren't urgent. They're a customer with no other way to find out — and answering them is eating your dispatch day.
A dispatcher's morning: eleven calls before ten o'clock, nine of them asking where a truck is.
None of those calls change anything. The freight is where it is. The dispatcher looks at a screen, reads out a location, and hangs up. Then does it again.
Meanwhile the two calls that actually needed a human — a breakdown and a rejected load — waited.
The calls are a symptom
Customers do not call because they enjoy it. They call because you are the only interface. Their own boss asked, or their customer asked, and the only way to answer is to ring you.
Give them somewhere to look and most of that volume disappears. Not because customers become less anxious, but because the anxious ones can now resolve it themselves at 7am without involving you.
What a shipper portal actually needs
Much less than people assume. The failure mode is building a product when you needed a page.
Current status and location, at a useful granularity. "In transit, near Amarillo, ETA Phoenix Thursday 14:00" is enough. Nobody needs a live map with a moving truck icon, and building one is a large distraction.
Documents. BOL, POD, and the ability to download them. This alone kills a large share of inbound email, because the second most common request after "where is it" is "can you send me the POD."
Their loads, not all loads. A customer sees their own freight. This sounds obvious and is the thing most likely to be got wrong in a first build.
A history they can search. By reference number, PO number, date range. The customer's reference matters more than yours — they will search for their PO, not your load number.
Proactive notifications, not just a portal. Picked up, in transit, delivered, POD available. Email or text, triggered by the status change. The portal answers the unprompted question; notifications prevent it being asked.
That last point matters most. A portal alone still requires the customer to think of it. Notifications plus a portal is what actually reduces call volume.
What not to build first
Live map tracking. Expensive, and its value is mostly emotional. Status and ETA answer the real question.
Customer-facing booking. Sounds appealing, generates a queue of requests that need human review anyway, and is a much bigger build.
Anything requiring the customer to install something. They will not.
Accounts for every contact at every customer. Start with one login per customer and a shared reference lookup. Per-user accounts are a permissions project.
The version worth building first is a status page with documents and a reference search, plus notifications. That is a couple of weeks of work and it takes most of the calls away.
The part that decides whether it works
The data behind it has to be current, and that is not a portal problem — it is a dispatch discipline problem.
A portal showing a load as "in transit" that was delivered yesterday is worse than no portal. You have replaced a phone call with a customer who now distrusts your systems and calls anyway, having first wasted their own time.
Which means the portal is downstream of the driver workflow. If your PODs arrive by text on a Thursday, your portal is a Thursday portal. Get document capture from the cab working before you show customers anything.
What it does beyond call volume
It differentiates on accounts you would otherwise lose on price. Visibility is a real reason a shipper stays with a small carrier over a cheaper one, and it is one of the few reasons that does not cost you margin.
It shortens the payment cycle. A customer who can pull their own POD has one fewer reason to sit on an invoice.
It surfaces your own problems. The first month a portal is live is uncomfortable, because your customers can now see the loads with stale statuses. That is information you needed.
What to measure
- Inbound status calls and emails per week. The number the project exists to move.
- Portal logins per customer. A customer who never logs in is still calling, and is worth asking why.
- POD retrieval requests. Should drop sharply and immediately.
- Days sales outstanding. Usually improves once documents are self-service.
The honest caveat
Some customers will never use it. Large shippers with their own TMS want EDI or an API, not your login. Very small ones prefer to phone, and always will.
The portal is not for them. It is for the middle — the customers with enough volume to generate real call traffic and not enough systems of their own to demand integration. That is most of a small carrier's book, and it is where the eleven calls before ten o'clock are coming from.
We build the dispatch systems, document capture and customer visibility behind this for US carriers and freight brokerages. See how it fits together, or tell us what your customers ask for.