AI Logistics Software for Tagging and ETA Estimation

Shyftbase AI automates product tagging and service-time estimation for logistics operators. It reads images and documents, captures labels, and flags damage such as scratches and dents, tagging each automatically. It also projects costs from historical data and current trends, and feeds learned time estimates to the routing engine that publishes delivery ETAs.

A pallet comes off the trailer at the hub with a crushed corner. The driver photographs it, the photograph lands on the shipment record, and three decisions follow: what the damage is, which leg it happened on, and whether anybody is going to pay for it. On most operations those decisions are made by a person working through a queue of photographs days after the freight moved, by which point the answer to the second one has been lost.

Shyftbase AI is the layer that reads the photograph and the paperwork attached to it. It tags what it finds — the label, the fields on the document, the scratch or the dent — and writes those tags onto the record the rest of the platform already works from. What follows is what that layer reads, what it writes back, what to test before trusting it, and where it stops.

What the models read, and what they write back

There are two kinds of input and they behave differently. An image is a photograph taken at a moment — an out-scan at the origin dock, an in-scan at the hub, a hand-held shot at a customer's door. A document is the paperwork travelling with the freight. Shyftbase AI processes both, captures the labels it finds, and attaches the resulting tags to the record without anyone typing them.

Document extraction sounds like an unbounded problem and is not, because the fields that matter are prescribed rather than chosen. Federal law already fixes the target for a for-hire, non-exempt carrier: the receipt or bill of lading it issues has to show who tendered the freight and who receives it, where the movement starts and ends, how many packages there are, what they are, and the weight, volume or measurement the move is rated on^[bol]. Five groups, and they are the field list an extractor has to return. A model that reliably produces those groups from a photographed or scanned page has done the work that matters; one that returns a fluent paragraph summarising the document has not. For the plain definition underneath the field list, see what a bill of lading is.

The output is where this differs from a document viewer. A tag is a value on a record — queryable, countable, available to routing, billing and the warehouse without a second entry step. The honest test is whether you can ask show me every shipment last month where the piece count on the document did not match the piece count on the order and get an answer without opening a document. Extraction that only produces a searchable copy of the paperwork has moved the reading, not removed it.

Damage tags, and the clock behind them

Damage detection is the most concrete capability here and the easiest to over-read. What is documented is narrow: the models identify damage such as scratches and dents and attach the tags automatically. Two classes, both named. Water damage, temperature excursion, infestation, a torn wrap that is not yet a dent — none of those is on the documented list, and the move is to ask for the list rather than assume it extends.

The narrow version still earns its place, because the value is in when the tag is made rather than in how clever the classifier is. A damage tag is worth what the photograph behind it is worth, and a photograph is worth the moment it was taken at. A dent tagged on an out-scan image at the origin dock and absent from the in-scan image at the receiving hub localises the damage to one leg and one party. The same dent tagged once, at the door, three days later, localises nothing, and an argument about which handover caused it is one nobody wins.

There is a clock on the other side of it, and it is federal. A carrier that receives a written claim for loss or damage must acknowledge it in writing within 30 days of receipt, and must pay, decline, or make a firm compromise settlement offer within 120 days; if it cannot dispose of the claim in that window it has to tell the claimant why, and again at each succeeding 60-day interval^[claims]. Evidence that surfaces after a claim has been declined is expensive in a way that evidence captured at the dock is not. Automatic tagging is worth buying to the extent it puts that evidence on the record the day the freight moved.

Service time, and the ETA that rests on it

Service time is how long a stop actually takes: the approach, the wait at a receiving desk, the signature, the walk back with an empty pallet jack. It is the input operators guess at most often, and the one a plan is least able to survive being wrong about.

Shyftbase AI estimates service time from historical data rather than from a default. That is the whole of the claim, and it is worth stating plainly: the estimate comes from what comparable stops have actually taken in your operation, not from a number typed into a settings screen at implementation and never revisited. The same estimator covers delivery times and service durations, which matters if you run installations or service calls alongside drops — those are the stops whose durations vary most.

Publishing that estimate as an ETA is the routing engine's job rather than this module's. Routing takes the time estimates built from historical data and turns them into the ETAs a customer is given — see how the route optimization module sequences a day for the constraints it solves against. The failure mode is specific and it has a cause: a flat service-time assumption of eight minutes against stops that really take twenty-five does not degrade gently. It holds for the first two stops, then every ETA after that is wrong by a margin that compounds, and the customer measures you against the notification sent at 07:15, not against the plan rebuilt at 10:40. What AI route optimization actually saves works through the arithmetic on the routing side of that.

Cost projection, and the questions to put to it

The documented behaviour is a cost projection built by analysing historical data and current trends. Two named inputs, no accuracy figure attached to either. That is the honest state of it, which is why this section is about how to interrogate a projection rather than how good one is.

A projection is a function, and you are entitled to ask what its arguments are. Three questions decide whether one is usable in a budget: which cost categories it covers, over what horizon, and what it said last quarter measured against what actually happened. The third is the only one that separates a forecast from a chart, and it is the one least likely to be volunteered. Ask for the back-test on your own history, or treat the projection as a planning aid rather than a number you commit to.

There is a structural caution here that has nothing to do with the model. A projection fitted to historical data inherits every change the operation has made since that history was recorded: a new depot, a rebuilt route set, a different surcharge schedule, a customer who moved from two collections a week to five. Nothing in the fit tells you which of those is a trend and which is a step change — that is true of any statistical method, not a weakness of this one. The working conclusion is not to distrust projections but to project a range, name the inputs, and re-fit whenever the operation moves under it.

How to evaluate this before it goes into an operation

Two model layers sit behind the capabilities above. Shyftbase AI is built on large language models together with custom-trained models, and those models are not one-size-fits-all: you can run the existing ones, or work with the Shyftbase team to tailor them. Those are different purchases with different obligations, and knowing which one you are buying is the first question.

Run the first two rows on a held-out month of your own material, not on a curated demo set. Damage photographs taken by drivers in a yard at dusk are a different distribution from the ones a vendor brings to a meeting, and a model that reads both equally well is worth paying for.

What this does not do

Six boundaries, because a model layer sold without them is the one that gets switched off after the first bad tag.

No accuracy figure is published. No precision, no recall, no confidence threshold for tagging, extraction or damage detection appears here, and none should be read into the description above. Ask for a number measured on your own material; one measured on someone else's is a starting point for a test, not a result.

Two damage classes are documented. Scratches and dents. Anything beyond those is unverified until it is confirmed in writing.

A tag is evidence, not a claim. Bad-order reports, notations of shortage or damage on freight bills and delivery receipts, and inspection reports issued by carriers or their inspection agencies do not, standing alone, satisfy the minimum requirements for filing a claim^[claims]. Automatic tagging makes a claim faster to assemble and easier to prove; it does not file one, and it does not decide liability.

Input limits are not published. Supported file types, size ceilings, batch volumes and throughput are not stated on this page. If you process a heavy daily volume of images, get those numbers in writing before planning around them.

Nothing here acts on its own. The module produces tags, estimates and projections. What happens next — a re-plan, an exception, a chargeback, an invoice line — is a decision made by a person or by another module's rules. Where a vendor describes an agent that acts autonomously, the questions that matter are what it is permitted to write to and what stops it.

No connector of its own is claimed. This page does not assert an ERP or accounting integration for the AI layer; the systems the platform connects to are documented on the integrations hub.