Defining the Core System of a Live B2B Logistics Marketplace
Deliver My Container (DMC) is a two-sided marketplace connecting importers with freight forwarders to quote and book container transport.
When I joined, pricing often depended on off-platform clarification rather than the platform itself. As a result, the platform struggled to function as a reliable marketplace. I redefined the core system so jobs could be priced and progressed with greater confidence within the platform.
Pricing depended on clarification rather than the listing itself.
Redefined the system so one job represented one executable shipment schedule.
Quote Without Clarification
Jobs could be assessed and priced directly from the listing.
Support Shifted to Exception
Support moved from routine involvement to handling edge cases only.
From Listing Tool to Executable System
Jobs became structured units that could progress into execution.
Pricing could not be generated reliably from the listing itself
Freight forwarders could submit quotes through the platform, but doing so often required off-platform clarification before a price could be given with confidence. Listings did not consistently contain the level of detail required to assess a movement, leaving forwarders to interpret missing or ambiguous information.
As a result, pricing depended on individual assumptions rather than a shared definition of the job. This introduced variability, delayed responses, and rework when key details were clarified too late.
Where the Marketplace Broke DownReplace slow, email-based quoting with a faster, self-serve marketplace
- → Importers list clearly defined shipments
- → Forwarders submit quotes directly in-platform
- → Pricing is generated without additional coordination
Pricing depended on off-platform clarification
Redefining a live system without disrupting active usage
I joined Deliver My Container shortly after public launch, with importers and freight forwarders already actively listing and quoting jobs in production.
Live Marketplace
The core marketplace flow was already live. Any changes to how jobs were defined needed to be introduced without disrupting active users or in-progress transactions.
Limited System Definition
The platform had been developed externally prior to launch, with limited internal documentation and no clearly defined data model. How jobs were structured and progressed was underdefined, despite being in active use.
No Opportunity for Reset
The system could not be paused or rebuilt in isolation. Updates needed to be introduced incrementally, requiring coordination to evolve the underlying model without destabilising the live system.
Early Signals from Real Usage
Live usage exposed inconsistencies in how jobs were interpreted and priced, indicating that the system required further definition under real operational conditions.
The system allowed ambiguous jobs into the marketplace
The issue was not missing information — it was that the system allowed jobs to be created without a clear, consistent definition of what was being priced.
A single job could represent multiple shipment scenarios while still requiring a single price. Key details — such as timing, routing assumptions, or shipment specifics — were often unclear or open to interpretation.
As a result, forwarders were responding to partially specified requests, making pricing dependent on individual assumptions rather than a shared definition.
1 Job = Multiple possible shipment scenarios → 1 price
-
01
Ambiguous Job Definition
A single listing could represent multiple shipment scenarios, with no clear boundary around what was being priced -
02
Lump-Sum Pricing Constraint
Forwarders were required to provide a single price across variable conditions -
03
Missing Commercial Inputs
Key details such as insurance, Incoterms, and customs responsibilities were often unclear or omitted -
04
Unstructured Information
Additional details were often provided in free-text formats, making pricing inputs difficult to isolate
Redefining the job as a single executable unit
Core DecisionThe issue was not how the system captured data, but how it defined the unit of work. I addressed this by introducing a constraint:
1 x job = 1 x executable shipment schedule
This established a consistent unit of work that could be assessed, priced, and progressed without requiring clarification.
Priceable Without Follow-Up
Jobs needed to contain the information required for forwarders to assess and price without clarification.
Single, Unambiguous Scope
Each job represented one defined shipment scenario, removing variability in how listings were interpreted.
Structured for Progression
A job was defined as the starting point for execution, not just a request for pricing.
Implementing structural change within a live system
Migration ConstraintsLive Marketplace
The platform was already in use, with active listings and quotes in progress. Changes needed to be introduced without disrupting users or in-flight jobs.
Dual Model Transition
The system needed to support both existing ambiguous jobs and new structured listings during migration. This required coordination with engineering to map the new structure onto the existing data model without breaking marketplace continuity.
Incremental Rollout
The updated structure was introduced progressively within the listing flow, allowing the system to evolve without downtime or disruption to active users.
Greater structure at the point of listing increased upfront input requirements, introducing a learning curve for some users (e.g. incoterms, insurance). In return, quotes became directly comparable, reducing variability caused by assumption-based pricing.
Mitigation-
Rejected: Field-Level Fixes
Adding validation or mandatory fields would have increased data capture, but not resolved structural ambiguity. Jobs could still represent multiple scenarios while requiring a single price.
-
Edge Case Handling
Some users could not fully define shipments upfront. Instead of reintroducing flexibility:
- Provisional inputs were allowed within constraints
- Listings could be refined before quoting
- Users were guided to complete missing information
Edge cases were supported without weakening the core system definition.
Defining a system that can be priced and progressed
The redesign translated the new job definition into a structured system that supports both pricing and progression. Rather than acting as loosely defined requests, jobs now function as reliable inputs into a commercial and operational workflow.
Structured Listing
The listing flow was redesigned to ensure each job represents a single, clearly defined shipment scenario. Inputs are captured in a structured sequence, guiding users to define shipment scope, commercial context, and timing. Reduced reliance on interpretation.
Structured Commercial Response
Quotes were reshaped from single values into structured commercial responses. Forwarders respond to a defined scenario, and pricing reflects cost breakdowns, service variations, and location-specific charges.
Commitment and Transition
Selection acts as a commitment point. At award, the accepted quote defines agreed terms, pricing and responsibilities are carried forward, and the job transitions into an execution state.
Execution Within the Platform
A dedicated execution context was introduced. Shipments are managed as structured records supporting milestone tracking, document handling, and lifecycle progression.
Video walkthrough: Listing a Job — Before vs After
- Missing context
- Minimal shipment definition
- Assumption-based
- No cost breakdown
- No platform continuity
- Contact revealed
- No audit trail
- No visibility
- Priceable scenario
- Complete shipment definition
- Context-based
- Itemised pricing
- System continuity begins
- Accepted quote becomes shipment
- Document + milestone tracking
- Dedicated execution context
∞ Containers
Defined timing window
Commercial terms
Execution context
Multi-currency support
Carrier-specific options
Transit + service variables
Quote →
Selection →
Shipment →
Completion
More reliable pricing and reduced operational overhead
Before
Jobs required additional information before they could be priced.
After
Most jobs could be assessed and priced directly from the listing, without clarification. This shifted quoting from clarification-dependent to majority self-serve, reducing reliance on follow-up across most jobs.
Before
Support was involved in the majority of jobs to resolve missing or unclear details.
After
Support shifted from routine involvement to exception-based handling.
Before
Quotes were based on varying assumptions, leading to inconsistencies and occasional rework.
After
Forwarders priced against a shared, defined scenario, improving consistency and comparability.
Before
The platform acted as a coordination layer, with key interactions occurring outside the system.
After
Jobs functioned as structured inputs into a system, supporting both pricing and execution within the platform.
Defining what the system allows
The core issue was not missing fields — it was allowing structurally weak records into the system. When a job could represent multiple shipment scenarios, different users formed different interpretations, making pricing inconsistent by default.
I learned that system reliability is defined at the point of entry. Once ambiguity is introduced, every downstream interaction becomes recovery work. Designing this system was therefore less about capturing more information, and more about defining the right constraints — ensuring that what enters the system can be priced, compared, and progressed without reinterpretation.