Case study / 23 Jun 2026

How I would build a knowledge base for a freight forwarder

I have not run a freight desk. I have built the same shape of system in another industry, and I keep using freight as the example because the bottleneck is so clean. I already wrote about the quote that takes two days. This is the layer underneath that. Not the quote, but the living knowledge a forwarder accumulates and never quite captures.

The idea is the one from letting a model compile your knowledge base, applied to a specific business. Here is how I would approach it.

What a forwarder actually knows

A freight forwarder's real asset is not its rate sheet. Anyone can get rates. The asset is everything the desk has learned by moving thousands of shipments, almost none of which is written down.

Which carrier is cheap on paper and a nightmare in practice on a given lane.
Which port clogs up in which season, and how late that really makes things.
Which commodities get held at customs, and what paperwork makes it stop happening.
Which customer needs hand-holding and which one only cares about the number.
What went wrong on the last shipment that looked exactly like this one.

This knowledge lives in the heads of a few senior brokers and in a decade of email threads nobody will ever read again. When one of those people leaves, the company gets measurably worse and cannot say exactly why.

The raw pile

So the first move is not clever. It is to gather the truth into one place a model can read.

For a forwarder, the raw folder is fuller than people expect:

The last few years of sent quotes and the bookings that followed them.
The shipment files. Routing, carrier, dates promised, dates met.
The incident notes. The held container, the rolled booking, the demurrage bill and why it happened.
The rate sheets and surcharge schedules, with their dates.
The carrier and customer email threads, exported as plain text.

Most of this already exists. It is just scattered across an inbox, a transport management system and a shared drive, in formats nobody designed to be read together.

What the model compiles from it

Point a model at that pile and have it compile, and the wiki that comes out is organised the way a broker actually thinks.

An article per lane. Shenzhen to Sydney, with its real transit times, its seasonal congestion, its reliable and unreliable carriers.
An article per carrier. What they are good at, where they let you down, how they handle a claim.
An article per commodity type. What gets flagged, what documents clear it, what the rules actually are this year.
A page per major customer. What they value, what they have complained about, what won and lost their business.

Each one is built from the real shipment history and linked back to the files it came from. The senior broker's instinct, the thing that took fifteen years to build, starts to exist outside their head.

The questions it can suddenly answer

Once that wiki exists, the desk can ask the questions that used to need the one person who remembers everything.

"What usually goes wrong on this lane in peak season, and how should we pad the timeline."
"Have we moved this commodity before, and what held it up at customs."
"Which carrier should I avoid for this customer, given what they care about."
"This quote looks like one we lost last year. Why did we lose it."

And the linting pass earns its place here. Freight rates and surcharges go stale fast. A model reading the whole base can flag the rate sheet that has not changed since a fuel surcharge clearly moved, and the lane whose transit times no longer match what actually happened on the last ten shipments.

What stays human, and what stays read-only

A wiki like this drafts. It does not decide. The same discipline from every system I build applies.

The model surfaces the lane history. The broker still makes the call on the strange routing.
The model flags the stale rate. A person still confirms the new one before it goes back in.
The model drafts the quote from the base. A broker still reads it and presses send. Read-only by default, because a wrong number sent under your name is a real liability.

The grind moves to the machine. The judgement stays with the person, and it becomes a better job once the lookups are gone.

Prompt you can use

I run a freight forwarding desk and most of what we know lives in a few people's heads and old email threads. Help me plan a knowledge base a model can build and maintain for us.

Work through it with me one step at a time:
1. Ask me what sources we already have: sent quotes, shipment files, incident notes, rate sheets, carrier and customer threads, anything else.
2. Propose how to organise the compiled wiki: per lane, per carrier, per commodity, per major customer. Adjust it to how we actually work.
3. For one lane I name, show me what the article would contain and which of our sources it would pull from.
4. List the operational questions this base should be able to answer, and which of them currently wait on one senior broker.
5. Tell me honestly what should stay a human decision and where a wrong automated answer would be expensive.

Start by asking me what we move and where our knowledge actually lives today.

The rule

The forwarder's edge is not its rates. It is everything it has learned and never written down, sitting in a few heads that will eventually walk out the door.

Gather the shipment history into one pile. Let a model compile it into the lanes, carriers and customers the desk already thinks in. Keep the broker on every decision that matters. The industry changes. The bottleneck does not.