Written by:
Editorial Team
DSG.AI
A carrier's spot pricing desk runs on two competitive pressures: quote faster than the market moves, and price accurately enough to capture margin without losing the booking. Before automated pricing, these were in tension. Pricing carefully took time; quoting in minutes meant pricing on stale data or gut feel.
At a top 10 global container line, we compressed the spot quoting cycle from hours to minutes by building a dynamic pricing system that quotes against live market data, not analyst estimates. This is what the system does, what it required to build, and where the commercial value actually came from.
The Problem with Static Spot Pricing
Spot freight pricing in manual operations works like this: a commercial team receives a booking inquiry, checks the rate sheet (updated weekly or bi-weekly), applies surcharges, adjusts for lane utilization estimates, and sends a quote. The quote is based on rates that are already 3–14 days old.
In flat markets, this lag is tolerable. In volatile markets (which have characterized container shipping since 2020) a 14-day lag means your quote price may be 15–25% off current market. You are either leaving margin on the table or losing bookings to competitors who are reading the market in real time.
The second problem is response time. Research from Freightos and Wisor.ai (2026) shows that shippers who receive a freight quote within 2 minutes convert at significantly higher rates than those waiting hours or days. Auto-Quotation in Production: From Customer Email to Formatted Quote in Minutes covers the email-to-quote automation that feeds this system; dynamic pricing is the pricing engine behind it.
What "Dynamic" Means in Production
Dynamic pricing is not a pricing algorithm that adjusts based on demand signals alone. In container shipping, it means the price for a given lane, container type, and delivery window is recalculated each time a quote is requested (using current market signals, current vessel utilization, and current competitive positioning) rather than read from a pre-published rate table.
The inputs to each pricing calculation at the tier-1 carrier we work with:
| Input | Source | Update frequency |
|---|---|---|
| SCFI spot rate (per lane) | Shanghai Shipping Exchange API | Weekly |
| FBX rate (per lane) | Freightos API | Daily |
| Own vessel utilization (per vessel, per lane) | Internal voyage management system | Real-time |
| Port congestion signal (origin and destination) | AIS + port authority feed | 4-hourly |
| Recent own-carrier booking velocity | Booking system API | Real-time |
| Competitor rate signal (where available) | Market data provider | Weekly |
| Bunker fuel price | EIA Brent + bunker conversion | Daily |
| Surcharge schedule (BAF, ECA, PSS) | Internal config | As-changed |
These inputs feed a pricing model that outputs a base rate recommendation plus a confidence interval. The commercial team sees the recommendation and can override it: the system provides the anchor and the rationale, not a locked price.
The Model Architecture
The pricing model is an ensemble: a gradient-boosted tree model (XGBoost) for the base rate recommendation, combined with a rules-based surcharge calculator for the components that are contractually fixed, and a utilization adjustment function that moves price up or down based on how full the vessels on that lane are.
The XGBoost component is trained on 18 months of historical bookings with actual achieved rates (not quoted rates: there's a distinction when discounting is common). The features are the inputs listed above, lagged at 1 day, 1 week, and 4 weeks to capture trend momentum. The model is retrained weekly on a rolling window.
Why XGBoost over LSTM or a transformer? For this use case, three reasons: retraining speed (weekly retraining completes in under 2 hours, allowing the model to adapt to rapid market moves), explainability (the commercial team can see which features drove a specific recommendation), and robustness to data gaps (AIS feeds have occasional holes; XGBoost handles missing values natively without imputation).
For a broader treatment of forecasting method tradeoffs, see the Container Freight Rate Forecasting Methods Reference.
The Production Implementation
The system runs as a microservice that the quotation platform calls on each booking inquiry. The workflow:
- Booking inquiry arrives (via email, customer portal, or freight forwarder API)
- Auto-quotation extracts the parameters: origin port, destination port, container type, cargo type, requested delivery window
- Dynamic pricing service is called with those parameters
- Pricing model calculates base rate + surcharges + utilization adjustment in under 400ms
- Quotation platform renders the quote with the recommendation and the confidence interval
- Commercial team reviews (for high-value bookings) or the quote is auto-approved and sent (for standard bookings under a configurable threshold)
The 400ms pricing latency was a hard requirement. Customers using the carrier's digital booking portal expect near-instant pricing. A multi-second delay breaks the UX; a multi-minute delay eliminates the speed advantage of the system entirely.
The decision on which bookings require commercial review vs. auto-approval is governed by a rules engine: bookings above a certain TEU threshold, unusual cargo types, or quotes where the recommended rate is more than 15% above or below recent comparable bookings all route to commercial review. Everything else auto-approves.
Where the Commercial Value Came From
Three sources:
Speed of response. Quote-to-booking conversion rate increased measurably for digital channel bookings once response time dropped below 2 minutes. The system does not just price faster: it captures bookings that would have gone to a faster competitor.
Margin recovery. On upswings, the old system's 14-day lag meant the carrier was quoting below market for two weeks before the rate sheet was updated. With daily FBX-driven pricing, the delay is 24 hours maximum on the rate signal (and real-time on the utilization signal). Margin recovery on a high-volatility lane across a full year is material.
Utilization optimization. The utilization adjustment component routes incremental bookings to vessels with slack capacity, tightening yield management across the fleet. This is the component that most directly connects to the 50%+ margin efficiency improvement measured on AI-governed commercial processes: the pricing signal is reinforcing the same goal as the capacity plan.
What This Requires Before You Can Build It
The prerequisites that organizations underestimate:
A clean booking and achieved-rate database. The model trains on historical bookings with actual achieved rates. If your historical data only has quoted rates (pre-discount), the model learns to predict quotes, not outcomes. Cleaning the training data took longer than building the model.
Live connections to rate index APIs. SCFI weekly data is free; FBX daily data requires a paid subscription. The data pipeline that fetches, validates, and stores this data must be more reliable than the model itself: model failures are visible; data pipeline failures are invisible and produce quietly wrong recommendations.
A commercial team willing to use the anchor. Dynamic pricing recommendations are only as useful as the commercial team's willingness to act on them. Early in the deployment, the team overrode the model frequently. As they saw the model outperform their gut pricing over 90 days of A/B tracking, override rates dropped to under 10% of bookings. Adoption required proof, not instruction.
Governance for the pricing model. The pricing model makes commercially consequential decisions at scale. It requires a retrain schedule, performance monitoring, a clear process for handling anomalous market conditions (a port strike, a major shipper contract expiry), and a rollback procedure if a model version degrades. The FuelEU Maritime Compliance article covers adjacent AI governance requirements for maritime operations; the governance principles transfer to commercial AI systems.
The Freight Rate Forecasting Connection
Dynamic pricing and freight rate forecasting are different problems. Forecasting asks: where will rates be in 4 weeks? Dynamic pricing asks: what should I charge right now, given where rates are today and where this vessel sits?
They share inputs and infrastructure but serve different decisions. Forecasting serves procurement (when to lock in contracts vs. spot), planning (how to price forward bookings), and strategic capacity decisions. Dynamic pricing serves individual booking events in real time.
At the tier-1 carrier, both systems run from the same data infrastructure. The forecasting model feeds a 4-week forward curve that the dynamic pricing model uses as a soft constraint: if the forward curve says rates are rising, the pricing model applies an upward bias to current spot quotes to avoid locking in today's rate for delivery next month at a lower value.
The integration between the two is where the compound commercial advantage lives. Neither system alone captures the full opportunity; together, they close the gap between what the carrier should be earning and what they actually earn on spot volumes.
For the foundational architecture of the forecasting side, see Freight Rate Forecasting with Machine Learning: Replacing Analyst Estimates with a Live Model.
DSG.AI builds commercial AI systems for tier-1 container lines and shipping companies, with 15+ agentic workflows in production at a single enterprise. For details on maritime AI development, visit dsg.ai/maritime.
<!-- related-links:start (auto-managed by seo/sync-internal-links.mjs) -->
