AI Operations Analyst for a Trucking Fleet.

This is phase two for the same drayage carrier described in the fleet compliance case, and it is an active engagement rather than a finished one. Nothing on this page claims a delivered outcome, because the work is still in delivery.

The trigger came from the client, not from us. Once exception reporting removed the weekly log review, leadership noticed the next bottleneck sitting behind it. The TMS held every load, every lane and every rate. Getting an answer out of it meant exporting reports, pasting them into a spreadsheet and reading across columns until a pattern appeared.

Two questions came up every single week. Which lanes are losing us money right now, and which drivers are trending toward a problem before it becomes one. Both were answerable. Both took a senior person several hours, which meant in practice they got answered once a week at best, and a margin leak could run six weeks before anyone caught it.

Delivered in collaboration with Visionary Automate, a systems-integration partner of Zealous Digital Solutions.

The build puts an analysis layer across the TMS and the telematics feed rather than replacing either. Nothing about the existing dispatch workflow changes.

The first piece is plain-language querying. An operator types "show me my worst five lanes this month and why" and gets an answer with the underlying loads attached. The "and why" is the part that carries the weight. A ranked list is easy. A ranked list with the cost drivers broken out is what removes the spreadsheet step.

The second piece runs without being asked. It watches margin per load, cost per mile, detention exposure and driver risk indicators, and it raises an item when a trend breaks from its own history rather than from a fixed threshold. A lane that has quietly slipped $80 a load over three weeks does not trip a static rule, but it does trip a trend check.

The third piece is the recommendation. Each detected item carries a plain do-or-do-not suggestion with the reasoning shown, so the operator can disagree with it on the evidence rather than on instinct. The system does not act on its own.

Phase two is being scoped and delivered on the same joint basis as phase one. Delivered in collaboration with Visionary Automate, a systems-integration partner of Zealous Digital Solutions.

Everything below is a model. This engagement is in delivery and has produced no measured client results. The assumptions:

• Leadership time valued at $130 per hour • Dispatcher time valued at $30 per hour • A weekly operations review of about 5 hours, replaced by on-demand answers • Dispatcher spot-checks of about 2 hours a week, automated • Margin leaks worth about $400 per load on 8 loads a week • Those leaks caught roughly 6 weeks earlier than the current review cycle allows • Two such events assumed per year, not a continuous rate

That produces a modeled annual benefit of $69,000 to $74,000, and the model suggests payback inside two to four months. The narrower range compared with a labour-recovery build is deliberate, because the value here is mostly senior time and early detection rather than headcount hours. Actual results depend on the client's baseline and adoption. These figures are modeled estimates, not measured client results.

The intended operational change is the shortening of a loop rather than the removal of a job. Leadership still decides which lanes to renegotiate or drop. What moves is how long it takes to know which ones are candidates.

A second intended change is who can ask. When the answer requires an export and a pivot table, only the person who knows the export asks. When the answer requires a sentence, a dispatcher can check a hunch at eleven at night without booking anyone's time.

Because this phase is still in delivery, we are recording these as design intent rather than as results. When the engagement completes and enough operating history exists to compare against the prior review cycle, this section gets rewritten with what actually happened, including anything the model got wrong.

That reporting commitment is shared across both firms on the engagement. Delivered in collaboration with Visionary Automate, a systems-integration partner of Zealous Digital Solutions.

This suits a freight or drayage operation with a working TMS, a telematics feed and enough load volume that lane-level margin is a real question rather than a rounding error, typically somewhere north of 30 trucks. It is region agnostic and aimed at United States owners and operations directors.

It fits best where a senior person is currently the reporting layer, spending hours a week producing answers that a system could produce continuously. If nobody at the company is doing that work today, the time-savings half of the model does not apply.

It is a poor fit where the TMS data is incomplete or where rates live in someone's inbox rather than in the system, because an analysis layer inherits the quality of what sits underneath it.

The delivery sequence runs in four weekly stages, and each one ends with something the client holds rather than a status update.

• Week 1, discovery and data access. Read access to the TMS and the telematics feed, plus a walkthrough of how rates, accessorials and fuel are actually recorded rather than how the manual says they are. Deliverable: a written data map naming every field the analysis layer will read and every field it will refuse to trust. • Week 2, build. The query layer is written against the mapped data, the margin and cost-per-mile calculations are defined in code, and the anomaly checks are set against each lane's own history. Deliverable: the calculation definitions in plain language, so leadership can dispute a number by disputing its formula. • Week 3, supervised pilot. Leadership asks the questions they normally answer by export, and both answers get compared side by side. Deliverable: a variance log listing every case where the system and the spreadsheet disagreed, and why. • Week 4, cutover. Plain-language querying opens to dispatch as well as leadership, anomaly detection starts running unprompted, and recommendations begin carrying their reasoning.

Week 3 is the stage that decides adoption. An analysis layer that has been checked against the old method in public gets trusted. One that arrives certain of itself does not.

An analysis layer inherits the quality of what sits underneath it, so the prerequisites are stricter than for a monitoring build.

• A TMS with an API or a scheduled database export covering loads, lanes, rates and accessorials. A system you can only report out of by hand is not a source. • At least 12 months of load history. Anomaly detection compares a lane against its own past, and a lane with three months of history has no past to compare against. • Rates recorded in the system rather than in inboxes and side agreements. Every rate that lives in an email is a lane the model cannot price. • A telematics feed that can be joined to loads, which usually means a shared vehicle or driver identifier that exists in both systems. • A named person who owns the answers. Somebody has to decide what happens when the system says a lane is losing money, and a recommendation with no decision owner is a report. • An agreed definition of margin. Whether fuel surcharge, accessorials and empty miles sit inside or outside the number is a business decision, not a technical one, and it has to be settled before the calculation is written.

What happens when the system cannot answer a question?

It says so, and it shows which data it lacked. A layer that guesses when the underlying record is incomplete is worse than no layer, because a confident wrong lane ranking gets acted on. Questions that fall outside the mapped data return a plain statement of what is missing, which in practice becomes a list of the fields worth fixing in the TMS.

Who owns the data and the systems it reads?

You do. The TMS and telematics contracts stay in the carrier's name, the analysis layer reads from them and writes nothing back, and the calculation definitions are documents you keep. Removing the layer leaves both source systems exactly as they were.

What drives the ongoing running cost?

Query volume, the number of integrated sources, and how much history stays hot for comparison. A carrier with two systems and a year of retained history sits at the low end. Adding a third source, a fuel card platform or a maintenance system, is the change that moves cost most, because each new source has to be mapped and kept mapped as the vendor changes their schema.

How is success measured in the first 90 days?

Against the loop, not against a dollar figure. Time from question asked to answer received, the number of margin anomalies found before a monthly review rather than in one, and how many people other than the original analyst ask a question in a given week. The third measure is the one that predicts whether the build survives.

Three situations where an analysis layer will disappoint you, and one of them is common.

• Operations where the TMS data is incomplete or where rates live in someone's inbox. The layer will faithfully report a picture that is already wrong, and the correct first project is the data, not the analysis. • Fleets small enough that lane-level margin is a rounding error, typically under about 30 trucks, where the owner already carries the answer in their head. • Companies where nobody is accountable for acting on what the analysis finds. A losing lane identified and not renegotiated costs exactly as much as a losing lane nobody found. • Operations planning a TMS replacement inside the next two quarters, where the mapping work would be thrown away.

If any of those apply, the honest sequence is to fix the foundation first and build the analysis layer afterwards.

Delivered in collaboration with Visionary Automate, a systems-integration partner of Zealous Digital Solutions.

This engagement is active and in delivery. No completed result is claimed anywhere on this page. It was funded by the client after the first phase shipped, which is the only outcome signal we are prepared to state as fact.

The client is not named, and no terminal, lane or customer is identified. Every value in the ROI section is a modeled estimate built on the client's stated pay rates, load volumes and margin exposure. Actual results depend on the client's baseline and adoption. These figures are modeled estimates, not measured client results.

If a senior person at your company is currently the reporting layer, that is the condition this build exists to remove. Start a conversation about your TMS, your lane count and the questions you answer by export every week, and we will tell you whether the same layer is worth building on top of your data.