This Wednesday one run stood out in our protocol. 5,255 orders checked. 1,602 quantities changed. Duration: 57 minutes. No human opened a portal. The Tuesday before, it was 2,051 orders and 550 changes. The difference did not come from the agent. It came from the customer. Wednesday is the day this logistics company corrects its order quantities.
That is the point of this post. A customer portal without API is not a technical obstacle. It is a process with a known interface: the screen. Whoever automates it saves more than clicks. He gets a protocol for the first time. It shows what happens in that portal every single day.
Forwarders know the pattern. We see it in almost every logistics project. The customer provides a portal. Orders are confirmed there. Quantity changes go through the same form. There is no API. Or it costs extra. Or it sits on the roadmap for the year after next. So someone logs in every morning.
The numbers are not new, but they are clear. In November 2025, Strategy& and the BVL surveyed 115 logistics providers. Germany, Austria and Switzerland. 96 percent have started their digital transformation. 10 percent manage to scale new technology. Two thirds rate their own maturity as low to medium.
The other side of the table looks similar. The Logistics Benchmark 2025 (Team Neusta, Netfederation) reviewed 54 large logistics companies. 55 percent offer a customer portal. Only 20 percent deliver real value in it, such as active alerts. Portals grow faster than interfaces. Whoever waits for the API waits for something the other side rarely builds.
In our conversations with dispatchers, one more layer comes up that no study covers: slot booking. Every delivery needs a time slot. The dispatcher books it in the warehouse operator's portal. Depending on the consignee that is Transporeon, Cargoclix or a home-grown portal. Each has its own login. One order, three portals, three passwords. (Three passwords that exactly one person knows. That is not a security problem. That is a holiday problem.)
For an agent, a portal is the same thing it is for a dispatcher. A login form, a list, a form, a button. The difference is in how you operate it.
This is how our confirmation agent is built, the one behind the numbers above:
First, it runs in its own browser profile on its own machine. The profile keeps the session. The agent does not log in on every run. When it has to, the login is its own step in the protocol.
Second, it addresses the portal through selectors, not coordinates. A button is called "Confirm" in the page code, not "position 812, 340". If the customer changes the layout, the agent still finds the button. If the customer renames the button, the step aborts, and that is exactly what it should do.
Third, it writes a protocol for every step. Login, list loaded, order 4711 opened, quantity 12 instead of 10 detected, change saved. Every line has a timestamp and a result. The metrics come from these lines: orders checked, changes booked, duration, errors.
Fourth, there is a review list with a reason. Sometimes the agent cannot confirm an order. The quantity is not plausible, or an article is missing. Then it does not silently set the order aside. It writes it to a list with the reason. Dispatch sees that list in the morning.
Fifth, everything runs through a monitor that knows every run. In eight weeks this agent made 39 runs, 35 of them clean. Four aborted. All four with the same error: the browser was closed during the run. The portal was not the problem. On all four days a second run went through cleanly. The monitor shows both with a timestamp, the abort and the second run.
This is where the agent differs from a macro. A macro clicks. An agent clicks, logs, knows when to stop, and tells you.
The saving is the smallest result. The manual work in the portal disappears every morning. Any managing director calculates that in two minutes.
More interesting is what the protocol lines contain. Take the logistics company with the 5,255 orders. Before the agent, nobody knew how the change rate moved across the week. Now it is clear: Wednesday 23 to 33 percent. Monday 11 to 16 percent. Thursday zero. Eight weeks, the same pattern every week. It sits in a table now. Dispatch can staff Wednesday differently. And sales can talk to the customer about the quality of first orders. With numbers instead of a feeling.
The same goes for the review list. Every reason in it is a data problem on the customer's side. Missing article numbers. Quantities without a unit. Addresses spelled differently in the two systems. Before, the dispatcher corrected all of that in his head and never wrote it down. Now every case has a date.
An honest caveat: this is our own operating data from a few projects, not a market study. The 30 percent on Wednesday apply to this one customer. Whether another portal looks similar, we only know once a protocol runs there.
Three cases where the browser agent is not the right answer.
First, portals with captchas or two-factor login via hardware token. A mail code can be read. A token in a drawer cannot.
Second, portals where the contract obliges the customer to operate them manually. Rare, but it exists, and it belongs on the table before the first run.
Third, the case where the API does exist and is affordable. Then the API is the better project. It delivers data instead of screens. The agent is the answer to "no interface". It does not replace an existing one.
A fourth point is not a break, but a condition. Without protocol and review list, a browser agent is a risk. It then confirms orders nobody checks. The error surfaces at the customer. We do not build the saving without the protocol.
A browser with its own profile. A script that uses selectors instead of images. A mailbox for login codes. A table for the protocol. A monitor that counts runs and alerts when they stop. None of this is exotic. The effort sits in the review list and the failure paths, not in the clicks.
Slot portals are the next step. One order, three platforms, one agent. It books the time slots and writes the confirmations into the TMS. The mechanics are the same. The difference: three operators change their interfaces there, not one.
Which portal costs your dispatch the most minutes per day? Tell me, I collect these cases.
