From Contracts to Catalog: Automating Ocean Freight Offerings
Flexport’s vision is that global trade should be as easy as flipping a light switch. But the reality today for most customers buying freight is that they are presented with a litany of options with subtle differences across various ocean carriers like route names, via ports and more that make the choice much harder than it needs to be. Imagine if every time you wanted to turn your lights on you had to choose which power plant you were buying power from. There’s no reason for that level of complexity. Flexport wants to get closer to the world where our customers can tell us to move their goods from A to B and they trust us to figure out the rest.
For the Ocean Full Container Load market, Flexport offers an “Open Carrier” option where the client books a shipment on something like “FLXT TPEB Ocean Line.” Flexport has had these offerings for many years and the concept is sound, but the details on how we are able to price and fulfill it make a world of difference. Previously, we had teams of operators that would construct these offerings with bespoke processing scripts, sql queries, custom workflows and lots of google sheets. The new internal process we’re announcing today, Automated Offering Creation, replaces that cumbersome manual process with a streamlined pipeline that builds off of the extensive work we’ve put into modeling our contracts and the global network of ocean vessels.
In this post, we’ll dive into the details about what made this simplification possible, how it relates to advances in the Procurement Database and Carrier Space Supply model, and how that makes the Open Carrier vision more attainable than ever.
Procurement Database
The first advance that made this possible is a multi-year effort to build a best in class in-house contract digitization effort. When I started working on the Procurement team in early 2024, we were heavily reliant on third party contract processors. At this point the overall system had serious limitations: only 70% of shipments had an expected cost and of those, the majority ended up inaccurate after comparing it to the final bill. Today, we have expected costs on over 95% of shipments and over 90% are accurate.
One feature that helped us improve our Procurement data is the use of AI to help write custom contract parsers. Ocean contracts come in dozens or even hundreds of complicated formats, often via xlsx files with inconsistent layouts and inherently ambiguous interpretations. It takes a combination of complex python parsing scripts, domain knowledge, and specific clarifications from carriers to get usable rate data. Over the past few years, we’ve built a system that combines custom software engineer written traditional code, expert operator oversight, and AI agent ad hoc code to slowly and surely drive data quality up to a high bar. We’ve iterated through a few distinct designs on this part of the project, and you can read about the platform that powers our latest digitization agent here:
Carrier Space
The other foundation of this project is the insight that contract data on its own is not enough to really know how much it will cost us to fulfill an open carrier offering. One aspect of the problem is that rate data in the contracts is handled completely separately from two other critical pieces: Allocations and Sailing Schedules.
Allocations
Allocations control how many containers flexport is allowed to book with each carrier. These numbers come in every couple of weeks and are determined at various granularities: sometimes they vary by port or region, sometimes by “service string” (see below for an explanation), sometimes by connecting leg, sometimes by special premium service types, or for specific clients, or a combination of all. From 2021 to 2023 we built an elaborate Allocation Management System for our buy side agreements with carriers, which we now make available to clients of ours who use us for Booking Management.
Shockingly, contracted rate data and allocation data are not maintained by the same folks. Both are complicated constantly-changing agreements between flexport and ocean carriers regarding our bookings on their vessels and yet the lines of communication, job titles, document formats and business logic regarding the underlying data are totally distinct. The natural way this shows up in a tech system is to have two distinct teams build domain specific solutions that stay independent. That was how it worked at flexport for a long time, but we’ve been working for many years to overcome that and this launch is the successful result of that effort.
Get Michael Lipman’s stories in your inbox
Join Medium for free to get updates from this writer.
Sailing Schedules
In addition to knowing how much it costs to move a container and if we’ve been allocated the right to do so, we also need to know what sailings are available. In fact, in order to really understand the set of distinct bookable options we have to fulfill some open carrier offering, this data is the starting point. What routings (ie combinations of trucks, barges, ships, and trains) exist that can get from the origin port to the destination port? The main input to this system is a collection of “service strings” from the ocean carriers. The best analogy for these are bus routes. A typical one may include a dozen or so ports that a ship will stop at over the course of a couple months. Maybe a few ports along the coast of Asia, then cross the Pacific to the west coast of the US and Canada. Most carriers send one ship per week for their major strings and often a collection of carriers coordinate via “Alliances” so that multiple carriers can offer space on the same vessel. Flexport maintains the world’s most advanced collection of sailing schedule data and makes it browsable for free at atlas.flexport.com .
Here you can see an example vessel, the OOCL ASIA, traveling on CMA’s service string BOHAI from Tianjin to Qingdao to Shanghai, then California and British Columbia.
We combine the concepts of Atlas Sailing Schedules, Allocations, and Contracted Rates from the Procurement Database into single bookable units of space that we call a Carrier Space.
We first used this data model with early versions of the Procurement Database to power our Fulfillment Management Tool and Boat Assignment Engine. This was deployed internally in 2023 and has become a core pillar of how we fulfill ocean shipments. In the below screenshot from a March 2025 announcement you can see the combination of Allocation data (25/100 teus assigned), Sailing Schedule data (18 days to go Ningbo>Norfolk>Columbus) and a failed attempt to lookup rate/cost data (Calc cost: UNKNOWN). These days we have far fewer UNKNOWN costs because our shipment rate coverage is over 95%.
Bringing it all together
For the first time we now use that same integrated world model to answer the question at the core of this problem. If we were to fulfill some Open Carrier Offering, how much would it cost? First we determine which Carrier Spaces can be used, then we get the cost for each one, then we look at past data to build a blended composite cost that powers our Open Carrier prediction.
The overall flow is much more streamlined
Below, you can see for an Open Carrier offering from Shanghai through LA to Chicago, we have three different carriers, 4 service strings, 6 different departure dates, 4 different Allocations, 6 different booking references, and 4 different costs. And notice neither departure date, nor service string, nor allocation, nor via port is enough to determine the cost; cost can depend on all of them and that data is spread across all three systems.
There’s still a lot more to be done, but by building on top of sound integrated fundamentals and ensuring the entire flexport system uses a shared system of record for critical information like where and when ships are sailing, and how much it costs us to move freight on those ships, we are making steady progress towards our vision of a brighter world via seamless global commerce.
