It was a Thursday afternoon in autumn when the dispatcher of a mid-sized freight forwarding company told me on the phone: “Mr. Buschick, we have a problem that sounds stupid, but it costs us money every single day.” He then described something so commonplace in the logistics industry that most companies no longer even recognize it as a problem: Dispatch had no idea when their own trucks arrived at loading docks.
That sounds absurd. Here’s a company that invested millions in a fleet, uses Daimler Fleetboard as their telematics system, can see exactly where every truck is on screen — and yet the dispatcher calls the driver to ask if he’ll be there in twenty minutes. Three, four, sometimes five times a day. Per dispatcher.
This project is a good example of automation not always needing to be glamorous. No artificial intelligence, no machine learning, no cloud-native stack. Just a script that reads a web page. And yet it fundamentally changed how dispatch works every day.
The company operates a fleet of around 40 vehicles in national less-than-truckload freight. Routes primarily lead to regular customers with defined time windows at loading docks. A typical day looks like this: The first trucks leave at six in the morning, most arrive at their destinations between eight and eleven, and the return trips follow in the afternoon.
Fleetboard is Daimler’s telematics system built into the vehicles. It captures vehicle position, speed, fuel consumption, and a range of other parameters. The data converges in a web application that the dispatcher operates in the browser. They can see where each vehicle is, what route it’s taking, and when it’s expected to arrive at its destination — the so-called ETA, Estimated Time of Arrival.
So much for the theory. In practice, things looked different.
The dispatchers had Fleetboard on their screens, but they couldn’t stare at a map for eight hours a day waiting for a vehicle to approach a destination. They had orders to dispatch, customers to inform, and changes to incorporate. The Fleetboard interface offers no active notification — no pop-up, no email, no push notification when a vehicle approaches a loading dock. Everything pull, no push.
The result: phone calls. Lots of phone calls. The dispatcher called the driver: “Where are you? How much longer?” The driver answered, often annoyed because he was on the highway and had to find his phone first. Then the dispatcher called the customer: “The truck will be there in about thirty minutes.” And if something changed — traffic jam, detour, break — the whole game started over.
The obvious solution would have been: connect to the Fleetboard API, automatically query position data, compare it with target times, and trigger a notification when approaching. That’s technically clean, scalable, and low-maintenance.
There’s just one problem: Fleetboard doesn’t have an open API for third parties. At least not in the form you’d need. There’s an interface for selected partner companies that have gone through an extensive certification process. For a mid-sized freight forwarding company that needs a single automation component, that’s not an option. Certification takes months, costs five figures, and requires dedicated server infrastructure.
We checked this. Thoroughly. At the time of the project, there were three ways to access the Fleetboard data:
Path three was the only viable option. And that made it clear: this would be an RPA project. Robotic Process Automation. A script that does what the dispatcher would do — only automatically and around the clock.
We chose Microsoft Power Automate Desktop. This wasn’t an ideological decision but a pragmatic one. The freight company already had Microsoft 365 in use, Power Automate Desktop was included in the license, and it runs on the Windows Server that was already in the building.
The plan was simple: A script that opens the Fleetboard web application every 15 minutes, reads the current vehicle positions, compares them with planned arrival times, and sends a notification to dispatch when a vehicle enters a defined radius.
Simple in concept. The devil, as expected, was in the details.
UI automation is the kind of software development that looks worst on slides. There’s no clean architecture diagram, no elegant API interface. Instead, there’s a browser, a website that wasn’t built to be read by machines, and a script that simulates clicks and keyboard inputs.
Step 1: Login and Navigation. The script starts the browser, opens the Fleetboard URL, and logs in with the credentials. Sounds trivial, but it wasn’t. Fleetboard uses a multi-step login process with session cookies that expire after a certain time. The script had to detect whether it was still logged in or whether a new login was needed. We solved this by checking the DOM element: if the dashboard element exists, we’re in. If not, run the login routine.
Step 2: Reading Vehicle Positions. The Fleetboard dashboard has a map overview with all vehicles and a tabular view with details. We used the tabular view because it’s more structured. The script navigates to the vehicle list, iterates over the entries, and extracts for each vehicle: vehicle ID, current position (latitude and longitude), speed, and — when available — the system-calculated ETA.
The reading works via UI selectors. Power Automate Desktop identifies HTML elements by their CSS classes, IDs, or XPath expressions. This works reliably — as long as the website doesn’t change. More on that later.
Step 3: Comparison with Target Data. The planned arrival times and destination addresses were in an Excel spreadsheet that dispatch maintained daily. The script reads this spreadsheet and compares each vehicle’s current position with its destination. The distance is calculated using a simplified Haversine formula — straight line, not road kilometers. For the purpose of proximity detection, that was sufficient. When a vehicle falls below the defined threshold of 30 kilometers, it’s considered “in the arrival zone.”
Step 4: Notification. When proximity is detected, the script sends an email to the responsible dispatcher. Content: vehicle ID, current location, estimated arrival time, and destination address. No bells and whistles, no dashboard — a plain email that pops up in Outlook. The dispatchers wanted it that way, and honestly, it was the right call. Another tool on the screen would have gone unused.
Step 5: Scheduling. The script runs as a Scheduled Task on the Windows Server. Every 15 minutes, the flow is triggered. A shorter interval would have been technically possible, but the web application becomes sluggish with too frequent access, and Fleetboard might have flagged it as unusual access behavior.
I won’t sugarcoat this: UI automation is fragile. That’s not a weakness of this particular implementation — it’s in the nature of the approach. You’re building on top of an interface that can change at any time, and you have no control over it.
In the first three months after go-live, the script broke four times. Each time for a different reason.
Break 1: Fleetboard Update with a New Login Page. Daimler redesigned the login screen. New layout, new CSS classes. Our login selector grabbed nothing. Downtime: 6 hours until we adjusted the selector.
Break 2: Cookie Banner. A classic. Fleetboard introduced a new cookie consent dialog. It overlaid the entire page. The script couldn’t find the dashboard because the banner was in the way. Solution: An additional step in the script that checks for a consent banner and automatically accepts it.
Break 3: Timeout on Slow Server Response. On a Friday morning, the Fleetboard infrastructure was apparently under load. The page loaded slower than usual. Our script had a fixed timeout of 20 seconds. The page needed 35. Solution: Dynamic waiting with exponential retry intervals instead of fixed timeouts.
Break 4: Table Structure Change. During a minor update, Fleetboard added a column to the vehicle list. All column indices shifted. Instead of the position, the script read the speed; instead of the ETA, the fuel level. We only noticed when a dispatcher was puzzled why the system reported a truck was “74 liters” from the destination.
After the fourth break, it was clear: we needed a more robust architecture. Not a different technology, but better error handling within the existing one.
Error Handling with Fallback Strategy: Every single step in the script is now wrapped in a try-catch block. If a selector fails, the script tries an alternative selector. For the most important elements, we’ve stored two to three selectors each: one via CSS class, one via XPath, and one via text content. If all three fail, the script aborts in a controlled manner and sends an error message to IT.
Retry Logic: Instead of a single attempt, the script performs up to three retries on failure, with increasing wait times (5, 15, 30 seconds). This catches temporary network issues and slow page loads without bombarding the server with requests.
Health Check via Email: Every morning at 6:00 AM, the script sends a status message: “Fleetboard Monitor running. Last successful run: 05:45. Vehicles read: 38. Errors in the last 24 hours: 0.” If this email doesn’t arrive, IT knows something is wrong.
Screenshot on Error: On every unexpected error, the script takes a screenshot of the current browser state and saves it with a timestamp. This helped us enormously with error analysis. Instead of guessing after the fact what might have happened, we see exactly which dialog, which banner, which loading state caused the problem.
Configurable Selectors: All UI selectors now live in an external configuration file, not hardcoded in the script. When the Fleetboard interface changes, we only need to update the configuration — not overhaul the entire flow. This reduced response time for breaks from hours to minutes.
The script has been running for over a year. After the initial stabilization phase, there were exactly two outages in the last nine months — both caused by major Fleetboard updates, both resolved within two hours.
The measurable results:
The non-measurable but equally important results:
Dispatchers work more calmly. Instead of reactively responding to calls and inquiries, they can plan proactively. When the system reports that a truck will arrive in 30 minutes, the dispatcher can inform the customer in advance and plan the next tour at the same time. That sounds like a small thing, but it fundamentally changes the work rhythm.
1. Plan for multiple selectors from the start. We only implemented this after the third break. That was a mistake. In every RPA project, you should assume from day one that the target interface will change. Not if, but when.
2. Prepare the client for fragility. We initially communicated that the system runs “stably.” That was technically correct, but it created an expectation that led to frustration during the first outages. Better would have been: “The system runs reliably, but it will occasionally need adjustments because we depend on an external interface.” Honest communication saves explanation effort later.
3. Monitoring from the start. The health check via email was a retroactive addition. Had we implemented it from the beginning, the first three outages would have been detected faster. For a system that runs in the background with no visible user interface, monitoring isn’t optional — it’s mandatory.
4. Understand RPA as bridge technology. UI automation is not a permanent state. It’s a workaround for missing APIs. If Fleetboard ever offers an open interface, you should switch immediately. The script does its job, but it is and remains a workaround — and should be treated as such.
5. Excel as a data source has limits. Reading target data from the Excel spreadsheet was the fastest path to a solution. But Excel isn’t a database. Concurrent access, shifting formats, files someone has open — all of this can cause problems. For further development, I’d move the target data into a simple database.
The total project duration was two weeks. In the first week: analysis of the Fleetboard interface, building the script, initial tests. In the second week: fine-tuning, error handling, test operation in parallel with the manual process, go-live.
The costs were manageable. Power Automate Desktop was included in the existing Microsoft 365 license. The Windows Server was already in the company. The main costs were consulting and development — two weeks of work. Ongoing costs: practically zero, aside from occasional adjustments for Fleetboard updates.
The payback was quick too. The time saved by dispatchers — conservatively estimated at one hour per day per dispatcher with three dispatchers — amounts to about 60 work hours per month. At an internal hourly rate of 40 euros, that’s 2,400 euros per month. The project paid for itself within the first month.
This project will never win an innovation award. There’s no beautiful dashboard, no artificial intelligence, no machine learning algorithm. It’s a script that reads a website and sends emails. Technologically speaking, it’s the opposite of elegant.
But it solves a real problem. Dispatch works better, customers are more satisfied, drivers aren’t disturbed anymore. The system has been running stably for over a year, costs almost nothing to operate, and paid for itself in less than a month.
In automation, it’s not about building the most technically beautiful solution. It’s about solving the problem. And sometimes that means: scraping a web page because there’s no API. That’s not ideal, but it works. And a working workaround is always better than a perfect solution that doesn’t exist.
If you face similar challenges in your freight or logistics operation — systems without APIs, processes based on verbal coordination, information that doesn’t flow where it’s needed — then RPA as a bridge technology is worth a look. Not as a permanent solution, but as a pragmatic first step.
For a broader overview of automation in logistics, I recommend our article on digital transformation in logistics. If you want to know when RPA makes sense and when real AI is the better choice, read our comparison RPA vs. AI Automation. And if you’re specifically thinking about warehouse automation, we have a detailed article on that too.
Or talk to us directly. Contact us — we’ll look at your processes and honestly tell you what can be automated and what can’t. No PowerPoint, no strategy paper. Just a realistic assessment.
