When trip planning depended on individual memory
Building SteelChief’s daily delivery and installation trips was a manual job that ran on institutional knowledge. Someone had to know every team’s skills, where each was starting from that day, what was already in the system, and how a new order would fit against everything already planned, then hold all of it in their head long enough to build a workable route. It took four to six hours a day, and it could only be done by SteelChief’s more experienced staff, because there was no other way to hold that much context at once.
That created a bottleneck with a knock-on cost. The people who could plan trips were also the people with a backlog of other work, work that kept getting pushed down the list because trip planning couldn’t wait and couldn’t be handed off. And because rebuilding a day’s trips manually was slow, fitting in a late-notice order meant reshuffling everything else, which meant SteelChief often couldn’t offer a customer a faster delivery window even when the capacity existed.
Building an AI trip planner inside SteelChief's own VMS
Rather than building a separate platform, Arcadian extended SteelChief’s existing VMS with two planning engines, built on Retrieval-Augmented Generation (RAG) so each decision draws on the relevant operational context rather than fixed rules.
The Trip Proposer builds trips from scratch, evaluating over 18 variables: team skills, concreting completion (which has to happen first, and only when weather allows), material volumes and recent cancellations. It also ranks jobs by a priority score that’s weighted by customer wait time, location clustering and job duration. The Trip Optimiser works on trips already confirmed, reassessing them against traffic conditions to recommend adjustments that get more out of the same day. A “Rerun with AI” action regenerates every trip as requested, so a late order can be slotted in without unpicking the day.
A meaningful part of the job is understanding what customers actually say. Delivery notes come in as free text, “only home before midday Wednesdays and Fridays,” “install after school holidays finish,” and a Natural Language Processing (NLP) layer converts that into structured constraints the planning engine can act on directly, rather than a scheduler having to open every visit and re-read every note by hand.
Every AI decision, eligibility check, priority score and suggestion has been logged from day one, not for customer-facing tracking, but so the team can see exactly why the system proposed what it did, spot patterns when something goes wrong, like accommodating paved bases alongside concrete ones. The underlying approach draws on an established logistics pattern (the “milk run” model used widely in transport), but the specific implementation is unique to how SteelChief actually operates, and it was only possible this early because SteelChief’s underlying data was clean, deduplicated and well-structured from the start.
Trips always go through a human before they’re locked in. Before going live, the system ran in parallel with SteelChief’s existing manual process so the team could compare its suggestions against real decisions before trusting it as the primary source, and that human sign-off remains part of the workflow today.
A rollout built on trust, not a switch-flip
Human sign-off is part of the workflow by design. Schedulers review each proposed trip for what the model can’t see: a job assigned to a crew without the right skill, a driver who needs a shorter day, an order that arrived after the nightly sync ran. Ongoing work now sits with those edge cases and the guardrails around them rather than the core planning logic.
What SteelChief’s operations team actually watches is throughput: how many jobs get completed without more time on the road. That’s the number that matters commercially for a business with trucks and teams, and it’s the one this system is built to improve.
The next iteration will close the loop further: retraining the planning model on actual trip outcomes and scheduler edits, so the system keeps improving from what SteelChief’s own team decides, not just what it’s provided upfront.
Every AI decision, eligibility check, priority score and suggestion has been logged from day one, not for customer-facing tracking, but so the team can see exactly why the system proposed what it did, spot patterns when something goes wrong, like accommodating paved bases alongside concrete ones. The underlying approach draws on an established logistics pattern (the “milk run” model used widely in transport), but the specific implementation is unique to how SteelChief actually operates, and it was only possible this early because SteelChief’s underlying data was clean, deduplicated and well-structured from the start.
Trips always go through a human before they’re locked in. Before going live, the system ran in parallel with SteelChief’s existing manual process so the team could compare its suggestions against real decisions before trusting it as the primary source, and that human sign-off remains part of the workflow today.
