Case study · Automated tracking, freight forwarding

Nobody reads the carrier's email anymore. An agent does.

A freight forwarder moving cargo between the US and Mexico stopped capturing shipment status by hand. This is the system we built to make that happen.

The problem

Shipment status still arrives the way it did twenty years ago: by email.

The carrier writes "driver is loaded," "current location Yuma AZ," "delivered, POD signed" — and someone on the team has to read it, interpret it, and key it into the TMS by hand.

A single shipment generates ten or fifteen emails between pickup and delivery, mixed in with every other carrier, in one inbox.

Hours of manual entry

that add no value to the business.

Delays

the customer sees the status when someone had time to update it, not when it happened.

Human error

milestones skipped, logged late, or out of order.

People dependency

if the person in charge is out, tracking stops.

What we built

A system that reads, understands, and updates the TMS on its own.

Every cycle, the system repeats six steps with no human involved:

  1. 01

    Reads the inbox

    and sorts tracking emails by carrier.

  2. 02

    Queries the TMS

    to know the shipment's real current state.

  3. 03

    Interprets the email with AI

    understands natural language, not keywords: tells "driver is loaded" apart from "driver is on his way back" (empty leg) or "still waiting for cargo to cross" (unit held up).

  4. 04

    Calculates what's missing

    and fills in pending milestones, in order, using the real times from the email thread.

  5. 05

    Pushes events to the TMS

    through the provider's official EDI channel.

  6. 06

    Logs everything

    for audit.

On site shipper
Loaded
In transit
On site consignee
Unloaded
Delivered

The six over-the-road tracking milestones, confirmed by the system, not by a person.

Results in production

The system runs today on real shipments, for real customers.

Full cycle automated

from pickup to delivery, all six over-the-road milestones complete on their own.

Zero manual entry

for the integrated carrier.

Updated in the moment

not whenever someone has time.

Full traceability

every event sent is logged with its shipment, its time, and its outcome.

Why it can be trusted

Automating is easy. Automating without breaking anything is the hard part.

Four layers of protection make the system fit for unattended operation.

Idempotency

never sends the same milestone twice. Checks the TMS's real state before acting.

Atomic lock

if two emails for the same shipment land at once, only one wins the write. No duplicates, guaranteed at the database level.

Email de-duplication

an old thread that resurfaces doesn't trigger anything new.

Pre-validation

before touching the TMS, checks that the event makes sense: no valid identifier, no future date, no missing destination — if something doesn't add up, it stops and alerts.

Automatic alerts

any failure triggers an immediate notification to the team. Nothing fails silently.

Audit log

every decision is logged and queryable: what arrived, what the system decided, and what was sent.

Smart backfill

Carriers don't report cleanly. The system doesn't get lost.

Sometimes a carrier sends "delivered" without ever reporting departure. The system checks the shipment's real state, detects which milestones were never marked, and fills them in backward in chronological order, using the real times pulled from the email thread, never invented dates. The end customer sees a complete, coherent tracking history, even when the carrier reported in jumps.

Architecture built to scale

The logic that reads emails is separate from the logic that updates the TMS.

The system is designed around a shared data contract. Onboarding a new carrier means writing only its reading layer; the engine, already proven in production, is reused untouched. It applies to any input format: emails, portals, or GPS/telematics systems via webhook.

Carrier layer (swappable)

Carrier A
Carrier B
Carrier C
shared contract

Common engine (proven)

TMS query
Milestone calculation
Validation, TMS, and log

What the business gains

The team stops capturing status and focuses on what actually needs them.

Operations

the team focuses on resolving exceptions, which is where they actually add value.

Customer service

tracking is always current. Fewer "where's my cargo" calls.

Scalability

more shipments don't mean more people typing.

Visibility

structured data on every movement, ready for reporting: transit times, carrier performance, on-time compliance.

Continuity

the system doesn't take vacation or call in sick.

Stack

Automation built on n8n, classification with Claude (Anthropic), a PostgreSQL database for control and audit, EDI/API integration with the TMS, and Microsoft 365 for email. Deployed on our own cloud infrastructure. Compatible with any TMS that exposes an EDI channel; implemented and running in production on one.

n8nClaude (Anthropic)PostgreSQLEDI / APIMicrosoft 365

This is not a demo. It runs today moving real freight between the US and Mexico.

It was built by solving the problems that only show up in production: identifiers the TMS doesn't expose, carriers reporting out of order, duplicate emails, concurrent events, timestamps the receiving system rejects. We tested it on our own operation before offering it.