Forty emails asking the same question
Monday morning, and the inbox holds a familiar set of questions. Has the vessel left Shanghai? What is the new ETA at Southampton, because the warehouse needs to book labour? Has the container been discharged yet? Is the air shipment on the Tuesday flight or the Thursday one? Each answer means opening the carrier's website or the terminal portal, typing a container or airway bill number, reading the event list and writing a reply.
The operator who handles a busy importer might do this thirty times before lunch, and still miss the one shipment where the vessel has been delayed by five days, because nobody asked about that one.
The data exists, scattered across carriers
Every shipping line, airline and terminal publishes events. None of them publish them to your forwarding system on their own, and none of them tell your customer. The operator is the join between the carrier's data and the customer's question.
- Each carrier and terminal has its own website and reference format.
- Your forwarding system holds the job, but not the latest events unless someone types them.
- ETA changes happen quietly, and are only noticed when someone looks.
- Customers each want updates differently, and at different moments.
- Nobody watches for problems proactively, because answering questions fills the day.
What the status chasing costs
Operators are skilled people doing a lookup job. The time spent on routine status is time not spent on the bookings, documents and problems that need judgement. Importers who have to ask feel less looked after. And late news of a delay costs the customer real money, in warehouse labour booked for the wrong day or stock that runs out, which they remember when the next tender comes round.
The milestone tracking we build
- Each job's container numbers, bill of lading or airway bill numbers and booking references are read from your forwarding system as the job is created.
- Events are pulled from carriers and terminals through tracking APIs or a tracking data provider, covering departure, transhipment, arrival, discharge, customs status where published, and collection.
- Events are written back to the job in your forwarding system, so the record is current without typing.
- Rules you set spot changes that matter: ETA moved by more than a threshold, a missed transhipment, a container discharged but not collected, a flight offloaded.
- Customers get the updates they chose, by email or through a tracking page, and exceptions go to the operator with the event and the job side by side.
- Operators see a daily list of shipments needing attention, rather than every shipment.
| Question | Answered today by | With milestone tracking |
|---|---|---|
| Has it sailed? | Operator checks carrier site | Departure event sent to customer |
| What is the ETA now? | Operator looks it up | ETA change flagged and sent |
| Is it discharged? | Terminal portal lookup | Event on the job |
| Which shipments are in trouble? | Found when asked | Daily exception list |
How the day changes
Operators start the day with a short list of shipments that have changed, rather than an inbox of questions. Customers hear about a delayed vessel when it happens, which gives them time to rebook their warehouse or tell their own customers. The job record is always up to date, so anyone covering an account can answer a question in seconds. And the tracking history is kept, which helps when you talk to carriers about their performance on a lane.
If your forwarding system, for example CargoWise, already receives some carrier events, we build around that and fill the gaps, rather than duplicating it.
Does this sound like your operations desk?
- Operators answer status emails all morning.
- Customers hear about ETA changes late.
- Carrier websites are open in a dozen browser tabs.
- Events are typed into jobs by hand, or not at all.
- Delayed shipments are found when the customer asks.