Automating shipment status inquiries so dispatch can get back to planning

A tracking portal answers one question well: what status does the transport management system show right now? A customer who emails anyway is asking something the status field can't answer. "In transit" doesn't tell a site manager whether the cable drums will arrive before the electricians knock off at two. That question lands on a dispatcher's desk, and it is the one worth automating. If you want to automate shipment status inquiries, start with the emails your portal doesn't stop.

Answering by hand looks simple. The dispatcher drops the route plan, finds the order in the TMS, looks up the truck in telematics, works out the remaining stops and types a reply. Each one takes a few minutes, and they arrive while dispatch should be planning tomorrow's routes.

What an agent needs to automate shipment status inquiries

The agent reads what the dispatcher reads: the inbox, the orders, routes and stop sequences in the TMS, and vehicle positions from telematics. It also needs the house rules that today live in people's heads. How wide a delivery window do you give customers? How late does a load have to be before a person picks up the phone? What do you say about loads a subcontractor is carrying?

The walkthrough below is a constructed example of how we would build such an agent. It does not describe a client project.

Walkthrough: an email at 9:12

Say a freight forwarder in the Ruhr area runs groupage and part loads, some on its own trucks with telematics on board and some through subcontractors without it. At 9:12 a buyer at an electrical wholesaler writes: "Is order 4471 still arriving today? We need the cable drums on the Dortmund site by 2 pm."

Find the shipment

The agent first classifies the email as a status inquiry rather than a new order or a complaint. This time the order number is right there in the text. Often it isn't. Customers write "yesterday's delivery" or quote their own PO number, so the agent searches by sender, date and reference. If several shipments match, the draft reply asks which one is meant. It doesn't pick one.

Put the picture together

The TMS says: loaded at 6:40, route 12, stop 7 of 11. Telematics shows the truck has just finished stop 5 in Bochum. From the stop sequence and drive times the agent estimates arrival between 11 am and noon. This forwarder never quotes an exact minute, only a one-hour window, and that rule sits in the agent instead of depending on who happens to be on shift.

Decide whether it can answer alone

The deadline is 2 pm, the window closes at noon, and the truck is the forwarder's own with live position data. Under this forwarder's rules the agent may reply by itself. Where you draw that line is up to you. You can start by approving every reply and relax the rule once the drafts prove reliable.

Reply in the thread

"Order 4471 is on the truck and should reach the Dortmund site between 11 am and noon." The reply goes into the same thread with the order number in the subject line, and the agent notes in the TMS that the inquiry was answered and which window it gave. If the customer rings an hour later, whoever picks up can see what was promised without searching again.

When it doesn't fit

Same email, but the truck has been stuck on the A40 for 25 minutes and the estimate has slipped to 2 to 3 pm. Now the agent sends nothing. It puts the case on the dispatch list with window, cause and customer deadline side by side and suggests two options: move stop 7 up, or warn the customer now. The dispatcher decides. The searching is already done and the customer message is drafted.

Subcontractor loads

Without telematics the agent only knows the last reported status, so it won't make up an arrival time. It sends the subcontractor a short query and holds the customer draft until the answer comes back.

Then tell customers before they ask

Once the replies hold up, turn the flow around. The agent keeps comparing estimated arrivals with the windows customers were promised. When a shipment drifts out of its window, it writes to the customer before the customer writes to you. Each of those messages is one inquiry that never happens, and the customer hears about the delay from you instead of having to chase it.

What we sort out beforehand

We need read access to the TMS, the telematics interface, the inbox and one person from dispatch who knows the house rules. Whether vehicle position data needs the works council involved is something we settle together up front. We bring the data processing agreement with us.

The build itself is short. An agent like this is set up in one to two days, and we test it the same week on real inquiries from your inbox. After that a maintenance agent, included in the fixed price, watches it run. It notices, for example, when a telematics update changes the format of the position data. The only ongoing cost is AI model usage, billed to you directly by the provider.

Our advice: start with your own trucks

Begin with email inquiries about shipments on your own vehicles, where telematics data exists. Those cases most often have a clear answer, and you soon see how many the agent closes without a dispatcher. Subcontractor loads and early delay warnings can follow as a second stage. For the same approach applied to incoming orders, see our example on order entry for a freight forwarder.

Sophera Consulting builds status inquiry agents at a fixed price with no subscription, connected to your TMS and telematics. In the free automation check we work out which inquiries the agent should take on first and which access we need for that.