Will it write into our TMS?

The write-back is built against whichever system holds the loads. Where a supported interface exists it is used; where one does not, records are delivered in the format the system imports.

What happens when it is unsure?

The record is queued for a person with the original message beside it. The design produces a reviewed queue, which is what makes it safe to run against live freight.

Can it read a photograph of a delivery note?

Yes, and that is what it gets tested on. Dock photographs with glare, folds and a thumb over the corner are part of the sample the accuracy figure is measured against.

Does it run overnight, and what happens if it breaks?

It runs whenever the traffic arrives, so documents landing outside office hours are processed and the queue is waiting in the morning. Runs are logged and a failed or skipped run raises an alert rather than stopping quietly.

Do we still need EDI?

EDI stays where it works. This handles the traffic that never made it onto EDI — the email, the PDF attachment and the photograph — which at most brokerages is the majority of it.

How long does a first build take?

One document type or one message class is normally three to six weeks, most of which goes into the exceptions rather than the clean path.

AI for Logistics and Distribution

Rate confirmations, bills of lading and carrier invoices read into the transport system, and tender emails written up as loads.

Talk it through

(844) 422-7000

In practice

The freight cases this gets built for

Four recurring cases, and what makes each one awkward to handle by hand.

Four inputs in four formats, and the format sets the handling. A photographed page is read off an image, a forwarded thread is unstacked before the detail is reachable, and a fixed-layout file is mapped rather than read.

A tender email received outside office hours

A shipper’s email naming a lane, a date and a reference, arriving before the office opens. It is read, matched to the customer and written as a load, so overnight arrivals are a reviewed queue by the morning.

A detention claim raised after the delivery

The arrival and departure times sit in a photograph of a signed receipt and in a note on the load. Both are read into the load record at the time they arrive, so the detail is on the record weeks later when the claim is made.

An accessorial that was never billed

A lumper fee, a layover or a reweigh agreed on the phone and recorded nowhere. Comparing the carrier invoice against the rate confirmation puts it in an exceptions queue rather than leaving it unbilled.

A customer portal that only takes a file

A status file or a scheduled upload the customer’s side expects at a fixed time in a fixed layout, currently produced by a person at the end of a shift.

What this is for a freight or distribution business

Freight paperwork arrives in four forms: a rate confirmation in an inbox, a bill of lading photographed at the dock, a proof of delivery, and a carrier invoice to be checked against what was agreed. Each one is read and keyed into the transport system by hand today.

The work here reads those documents into the transport or warehouse system and turns the inbound message traffic into records instead of retyping. It runs in a cloud account the business owns, with every run logged and every failure raised.

The scope is set one document type or one message class at a time. A first build on that scope is normally live in three to six weeks.

A tender email arrives as unstructured prose. Lane, dates and references are read out of it and written to the load, to accounting and to the load’s documents. Every run leaves a record.

What you get

What gets built

One trigger and one path first, widened after it is trusted.

A photographed delivery receipt beside the load record read out of it: lane, ship and delivery dates, BOL, PRO and purchase order numbers, pieces, weight, seal, and the handwritten damage note. Each value is marked as matching the document.

A photographed delivery receipt above the load record read out of it: lane, ship and delivery dates, BOL, PRO and purchase order numbers, pieces, weight, seal, and the handwritten damage note.

Rate confirmations into the system

Lane, dates, equipment, references and the agreed rate read into fields and written to the load. Anything the system is unsure about is queued for a person rather than guessed.

Bills of lading and proof of delivery

Photographed at the dock or scanned at the desk, read into the load record and filed against the right shipment. Signed and stamped copies are part of the sample it gets tested on.

Carrier invoices checked against what was agreed

Invoice values extracted and compared with the rate confirmation and the accessorials on file, producing a queue of exceptions rather than a pile to audit by hand.

Inbound email turned into a load

Orders and tenders arriving as prose read for lane, dates, weight and references, then written into the system of record with anything ambiguous flagged.

Status requests answered

The where-is-my-freight question answered from the tracking data, with anything unusual passed to a person rather than guessed at. It is the highest-volume message class in most brokerages, and every answer comes from the tracking record rather than from a dispatcher reading it.

Carrier onboarding paperwork

Authority, insurance certificates and tax forms read into the carrier record, with expiry dates tracked and the chase sent automatically before they lapse. The packet arrives in a different shape from every carrier, so each one is read rather than mapped to a fixed layout.

The daily and weekly reporting

Exception reports, dock schedules and customer summaries assembled from the systems that hold them and sent on schedule. It says so when a source has not updated, instead of sending a report built on yesterday’s numbers.

Somebody who owns it afterwards

Model versions, extraction accuracy and spend reviewed on a set cadence once the build is done. Freight volume moves seasonally and the automation has to be watched through it.

How it works

How the work runs

Pick one document or one message class

Rate confirmations, or delivery paperwork, or the status question. One at a time, which keeps the scope finite and the build short.

Read the real inbox

Actual messages and actual documents, including the forwarded thread with four replies stacked above the detail that matters.

Build it narrow

One trigger, one path, running against live traffic with a person checking every record before it reaches the system.

Widen it once it is trusted

Exceptions get added after the main path is running, not before. Built in the other order they extend the build without the main path having been proved against live traffic.

What matters

What decides whether a freight automation survives

These are the freight-specific conditions a running automation has to hold up against, and they are what the build time goes on.

One shipment carries four different numbers

A load has a customer reference, a carrier pro number, a purchase order and an internal ID. Matching a document to the right shipment is usually harder than reading the document, and it is where most of the build time goes.
Running it twice must be safe

The same email arrives forwarded and the same delivery note is scanned at both ends. Anything that writes to the transport system is built to tolerate that without creating a duplicate load or a duplicate invoice.
A stopped automation raises nothing on its own

An automation that stops running produces no error anybody receives, and the drop in records looks like a quiet week. Run monitoring and alerting are part of the build rather than an extra.
Exceptions are most of the build time

The clean tender takes a day. The rest goes on what happens when a field is missing, an accessorial appears, or the target system is unavailable. Those paths get built deliberately rather than discovered in production.
The automation platform holds standing credentials

An automation platform holds standing access to the transport system, the mail system and the file store — broader rights than any one dispatcher. Where that store lives and who can reach it is a design decision, not an afterthought.
Spend is metered per request

Cost tracks message and document volume rather than seats, so the build includes reporting on which customers and lanes generate the traffic. Seasonal volume changes show up directly in the bill.

Who it is for

Who this is for

Brokerages and third-party logistics

Where orders and tenders arrive by email and are retyped into the transport system. The time from a tender arriving to it being accepted is the number this work gets measured against.

Carriers and drayage operators

Port paperwork, delivery documents and driver-submitted photographs, in volume and around the clock. Charleston terminal traffic runs outside office hours.

Warehousing and distribution

Receiving documents, packing lists and customer paperwork that has to become a record before anything moves off the dock.

Distributors with a quoting desk

Requests arriving as prose, priced and re-entered by hand into the quoting system.

Questions

Frequently asked questions

Will it write into our TMS?

The write-back is built against whichever system holds the loads. Where a supported interface exists it is used; where one does not, records are delivered in the format the system imports.
What happens when it is unsure?

The record is queued for a person with the original message beside it. The design produces a reviewed queue, which is what makes it safe to run against live freight.
Can it read a photograph of a delivery note?

Yes, and that is what it gets tested on. Dock photographs with glare, folds and a thumb over the corner are part of the sample the accuracy figure is measured against.
Does it run overnight, and what happens if it breaks?

It runs whenever the traffic arrives, so documents landing outside office hours are processed and the queue is waiting in the morning. Runs are logged and a failed or skipped run raises an alert rather than stopping quietly.
Do we still need EDI?

EDI stays where it works. This handles the traffic that never made it onto EDI — the email, the PDF attachment and the photograph — which at most brokerages is the majority of it.
How long does a first build take?

One document type or one message class is normally three to six weeks, most of which goes into the exceptions rather than the clean path.

Also on this site

Name the email that gets retyped

The tender, the rate confirmation, the status request. Whichever one arrives most.