Your customers do not want a tracking link, they want to stop calling you

Every transport office knows the call. A customer wants to know where their shipment is. Someone opens the dispatch board, finds the run, reads the last status, decides it is too old to repeat out loud, rings the driver, and rings the customer back. How long that takes depends entirely on whether the driver can answer the phone from where he happens to be standing.

The reflex answer is a tracking link. A tracking link is not wrong — it is just an answer to a smaller question than the one being asked.

The call is four questions in one coat

When a customer rings about a shipment, they are asking one of four things, and which one depends on where in the job they are:

• Where is it, and will it be there today? The one everybody builds for.
• Did it arrive, and who signed for it? Asked afterwards, usually because their own customer is now asking them.
• Can I have the paperwork? A delivery note, a photo of the pallet, a signed consignment note — needed to close their file or to settle a claim.
• What is this going to cost, and have you invoiced it? Asked by a different person in the same company, often on a different day.

A tracking map answers the first question and none of the other three. So the calls do not stop; they change shape. Instead of where is it you get can you send me the POD from Tuesday, which is a worse call: it takes longer, it lands on someone in accounts rather than dispatch, and it usually arrives well after the event, when nobody remembers the load.

Count them before you buy anything

The case for a portal is not a feature argument. It is arithmetic you can do yourself, this week, with a notepad next to the phone.

For five working days, tally every inbound call and email that exists only because a customer cannot see something you already know. Mark each one with which of the four questions it was, and roughly how long it took to close — including the part where you rang the driver, and the part where you came back to your desk and found your place again.

At the end of the week you have two numbers: how many, and how long. Multiply out to a month. That is the real budget for a customer portal, and it is usually larger than the software costs, because it is not counted anywhere today. It hides inside a dispatcher’s day and gets described as being busy.

Two things the tally tells you that matter more than the total:

• Which customers make the calls. It is almost never evenly spread. A handful of accounts generate most of it, and those are the accounts to onboard first.
• Which question dominates. If most of your traffic is the fourth kind — prices and invoices — then a tracking map will not move your number at all, and you would be buying the wrong thing.

What a portal has to contain to actually kill the call

The failure mode of customer portals is partial coverage. A portal that answers three questions out of four does not remove three quarters of the calls; it removes rather fewer, because the customer learns that the portal sometimes has the answer while the phone always does. A habit is only replaced by something reliably complete.

The minimum that changes behaviour:

• Booking. The customer places the order themselves, in the same place they will later look for it. This is also the cleanest data you will ever get, because the person who knows the address is the one typing it.
• Status, with an honest time. Not a moving dot for its own sake — the current state, the expected time, and a visible timestamp for when that was last true. An ETA shown without its age is a promise you did not mean to make; more on that in honest ETA communication.
• Proof of delivery, downloadable. Signature, photos, failed-delivery reason, timestamp — as a file the customer can attach to their own claim without asking you for it. This is the highest-value item on the list, because manually answering it is the most expensive of the four calls, and it is the one that keeps paper PODs slowing your invoicing.
• Invoices, and the documents behind them. The invoice, and the shipments it covers, in one place. Accounts departments ring about mismatches, and a portal that shows the line together with its consignment note settles most of those before the phone is picked up — which is also what makes invoicing on the delivery day survive contact with the customer.
• One login for all of it. This is not a nicety. A portal for tracking, a mail attachment for PODs and a third system for invoices is three habits to learn, so the customer keeps the single habit they already have, which is your phone number.

What a portal will not fix, and one thing it makes worse

The honest trade-offs, because they are the reason portals get bought and then sit unused.

It exposes your data quality. A portal is a mirror. If statuses are updated at the end of the shift rather than at the stop, the customer can now see that — and a portal showing yesterday’s position produces a call with an edge to it, which is worse than the neutral call you had before. Fix status capture in the driver app first, or launch both together.

It adds a support surface. Logins, password resets, the contact who left and whose account nobody removed, the new colleague who needs adding. It is a small load, but it is not zero, and it lands on the same people whose time you were trying to buy back.

It will not convert everybody. Some customers are one person who prefers ringing, and will go on ringing. That is fine. The arithmetic works on the majority, not on everyone — so measure success against the tally you took before, not against an adoption percentage.

Scoping is the part that has to be right. A customer must see their own bookings, their own documents and their own invoices, and nothing else, ever. One leak across two customers is a commercial incident that no amount of saved dispatcher time offsets. When evaluating, ask precisely how access is scoped — per customer organisation, resolved on the server, with no way for a caller to name somebody else’s data — and treat a vague answer as a no.

Start narrow

The portal that works is usually the one launched to four accounts, not the one launched to everybody at once. Take the accounts at the top of your tally, sit with them once after a month, and note which of the four questions they still ring about. That list is your roadmap, and it is more accurate than any feature comparison you will read.

Where navichain stands

navichain includes the customer portal on every plan. Customers book and track their own shipments on web or in the app, and get documents, proof of delivery and invoices self-serve, with notifications scoped to their own organisation and any goods you hold in custody for them visible to them and nobody else; larger customers can integrate directly with API keys instead. It is not a separate module or an Enterprise upgrade — every plan runs the full platform, and plans differ only by scale. The platform page shows what is inside, solutions how it fits different operations, and pricing what it costs.