How I Would Build a Freight Booking System That Hides the Freight

Direct Answer

A freight quote-to-booking system is a coordination layer that turns a shipper’s plain description of a load into a booked shipment with the paperwork already correct. Four pallets, Thessaloniki to Rotterdam, 1,850 kg, must land before the 18th, becomes a shortlist: price, transit time, and a button — with the gaps between modes left visible, not papered over. This is a designed system, not a deployed build. It comes from the Shopify Your Industry lab and has never been sold to or validated with a customer.

Key Takeaways

• The customer problem is not freight. It is that the industry makes the customer learn freight before it will sell them anything.
• The product is the coordination layer: intake, rates, documents, booking, tracking, exceptions.
• The bottleneck is carrier integrations. The abstraction is easy; the supply side is the moat and the cost.
• Customs declaration and commercial liability stay with licensed humans.
• This is a model from the lab, not a system I have built. The one I did build is the CRM follow-up loop.

What problem does this system actually own?

A manufacturer has four pallets and a date. To buy the thing they already understand, they have to learn Incoterms® 2020 (the rules that decide who pays and who carries the risk at each leg), customs paperwork, carrier quotes, and cargo insurance.

Today the path usually runs like this:

1. Someone emails two or three forwarders with a rough description of the load.
2. Each forwarder asks a different set of questions to make the request quotable.
3. Quotes come back in different formats, with different things included.
4. The shipper picks one, mostly on price, without seeing which costs, delays, and liability sit outside the headline figure.
5. Documents are assembled by email, and errors surface at the border.

None of that is the hard part of logistics. It is information moving between people who each hold one piece of it. That is the coordination layer, and it is the product.

The existing workflow I would map first

Before any model call, I would sit with a forwarder and a shipping clerk and walk one real shipment end to end.

If that table is wrong, the system is wrong. I would rather spend a week on the table than a month on the wrong build.

How the system would run

Structured intake

A short surface asks for what makes a request quotable: pallet count, weight, dimensions, goods description, origin, destination, ready date, latest arrival date. The model’s job is to turn plain language into that structure and to name what is still missing. Freight vocabulary stays behind the interface. Nobody is asked to pick an incoterm they do not understand; they are asked who is arranging pickup and who is paying duty.

Carrier rate aggregation

The system queries connected carriers and agents, then puts the results in one table so a shipper can scan them. It does not pretend a road quote and a sea quote are like-for-like. Inclusions, bunker or fuel surcharges, free time, and liability terms differ by mode, and an honest table shows those differences instead of collapsing them into one number. Where a rate can only come back by email, the request goes out as email and the reply is parsed into the same fields, with anything that would not parse left as a gap. This step is where the product is either real or a demo.

Customs document generation

The system proposes a commodity classification with its reasoning and its confidence, then pre-fills the commercial invoice, packing list, and declaration data from one shipment record, so the same values appear everywhere. It does not file anything. Classification is a legal position, and the Union Customs Code puts a named declarant behind it.

Booking and tracking

On acceptance, the booking goes to the chosen carrier through its API or its agent, and the confirmation, reference numbers, and documents land in one record instead of a mailbox. Milestones are pulled on a schedule. If a milestone is late against the plan, the system raises it rather than waiting to be asked.

Exception handling

Held shipment, misdeclared goods, damage, a missed sailing. The system detects, gathers the file, and drafts the next message. A forwarder decides. This is the step people pay for, and it is the step I would not automate.

What stays under human control?

• Filing a customs declaration, by a licensed representative.
• Final commodity classification when the model’s confidence is low or duty impact is material.
• Accepting a booking that creates a payment obligation.
• Insurance and claims.
• Anything a customs authority or a carrier can hold against a named party.

The system prepares, a person signs. That is the same rule I follow in the CRM build, and Anthropic’s note on building effective agents argues the same case: keep the workflow simple and inspectable before adding autonomy.

How I would measure the path

Baselines first, and only baselines, because nothing has been built:

• Hours from a shipper’s first email to a quotable, comparable answer.
• Share of quote requests that need a second round of questions.
• Share of shipments with at least one document correction before departure.
• Share of shipments that hit an exception, and hours to resolve one.
• Number of carriers reachable by API versus by email.

Self-learning here means usage signals, forwarder corrections, and evaluation of classification accuracy against what customs actually accepted, reviewed by a person. It does not mean the system quietly changing what it declares.

When this is the wrong build

• The carriers will not connect. If the lanes that matter are only reachable by email and phone, the system is a mailbox with extra steps. This is the bottleneck, and it kills the build before the model does.
• The volume is too low. Margin per shipment is thin. A shipper moving four pallets a year does not fund a coordination layer.
• The shipments are not repeatable. Project cargo, oversized loads, and one-off charters are judgement work, not throughput work.
• The forwarder’s edge is a relationship, not a process. Then you are building software against the part of the business that is not for sale.
• Nobody internally can review classifications. Without that reviewer, there is no supervised loop, only exposure.

How this connects to the engagement

This case is one of the models on Shopify Your Industry, where the test is which industries could hide their complexity behind a button. The system I have actually built is the AI sales follow-up loop inside a CRM, and the scanning pattern behind rate collection is closer to the Deal Database.

If a version of this coordination layer already exists in your company as email and memory, the operating starting point is AI workflow automation. If you want it looked at honestly, describe the bottleneck. If you only want the next teardown, the newsletter is enough.

Summary

The abstraction is one line: a load, two cities, a date. The output is a booked shipment with the paperwork already correct. Between those sits a boring coordination layer that moves information between a shipper, a carrier, a customs representative, and a forwarder who each hold one piece of it. This is a model. It stays a model until someone who runs the real process describes where it actually breaks, and until enough carriers agree to connect.