This is a Tuesday in a dispatch office where four services run. Not one company, but composed from the protocols of our customer projects: order capture from mail and PDF, customer portal without an API, arrival notices from telematics, freight invoice intake. The times are typical, the events are real.
The mailbox received 38 orders overnight. The capture service read them, checked them against the customer master and created 31 in the TMS. Seven sit in the review list: two unknown loading points, three dates without a time, one PDF without a reference, one customer with two spellings in the master.
The dispatcher opens the review list, not the mailbox. Seven decisions, original and proposal side by side. Twelve minutes. Before, it was 38 orders to retype, a good two hours.
The portal agent ran at 07:00: logged in, checked 412 open orders, confirmed 409, put three on the review list because the quantity was above tolerance. The dispatcher looks at the three, calls one customer and confirms two by hand. Ten minutes. (Tuesday is a quiet day at this customer. Corrections come on Wednesdays, up to 1,600 changes.)
The time the dispatcher was hired for. Shift tours, assign drivers, negotiate a time slot with a customer. In the background the arrival service reads the telematics every 15 minutes. At 08:45 it notifies the first customer that the truck is 30 minutes from the dock. The dispatcher sees the notice in his list and calls nobody.
The watchdog reports: the invoice service ran at 10:30, had 22 invoices in the inbox and booked zero. Error text: access to the TMS refused. The dispatcher reads the error text, nothing more. He calls IT, which changed the service's password that morning. At 11:05 the service runs again, 22 invoices are matched to orders, 19 booked, three on the review list for deviations above the threshold.
Before, nobody would have noticed. The service would have been green, and the invoices would have waited until Thursday.
A customer calls: "Where is my shipment?" The dispatcher looks at the arrival list. Notified at 11:25, dock informed. He tells the customer and asks in passing whether the notice arrived. It went to the dock, not to purchasing. One entry in the master, so from tomorrow the notice goes to both.
After lunch, three new review cases from the capture service, all from the same customer with an unknown article number. The dispatcher does not book them by hand. He calls the customer: the numbers come from a new catalog. The master gets extended, and from tomorrow the service reads them itself. That is the work that never happened before, because retyping ate the time.
The portal agent runs a second time and reports an unknown portal message: "Your password expires in three days." The language model read it and classified it as a hint, not an error. The agent carried on and put the hint on the review list. The dispatcher forwards it to IT. Without the model, the run would have aborted.
Before leaving, the dispatcher opens the day's protocol: four services, nine runs, 38 orders, 412 portal orders, 22 invoices, 14 arrival notices, one outage of 35 minutes, 13 review cases, all done. He reads it in a minute. On Monday, management gets the same numbers as a weekly mail.
The dispatcher retyped no order, operated no portal by hand, asked no driver about an arrival. He made 13 decisions, fixed an outage in 35 minutes and removed two master-data errors that would otherwise have come back every day. The services read, checked and reported. The rules they follow, he wrote down himself.
A caveat: the numbers are composed from several companies to show a typical day. In no single company do exactly these four services run with exactly these volumes. What is real: the events, the review cases and the alarm at 10:40, which we have experienced in similar form.
What does your Tuesday look like at 06:30? Tell me the first task of the day in your dispatch office. I will tell you which service would take it over. Ask for a process check: 30 minutes, no sales pitch.
