cargo.one

Quoting Workflow: closing the gap between search and client

Client

cargo.one

My role

Product Designer (UX/UI)

Year

2023 – 2026

Type

0 to 1 product · B2B SaaS

My role

I was the sole designer on this project from inception through long-term growth, working alongside a series of rotating PMs. I ran the initial user research to define requirements, co-scoped the MVP with the first PM, prototyped and ran user feedback sessions before development, and shipped the first version. After launch I maintained the backlog of user requests, tracked adoption data, regularly contacted users to understand their experience, and brought prioritised recommendations to each new PM who joined the project.

While PMs rotated based on quarterly priorities, I stayed as the continuity anchor: onboarding incoming PMs, holding the full context of every decision made, and ensuring the product evolved consistently rather than resetting with each new cycle. I also wrote and validated tickets for engineering when features didn’t require design work, keeping delivery moving independently.

Workflow Design 0 to 1 B2B SaaS User Research Logistics Information Architecture Internationalisation

The problem

Users could find offers. They had no way to share them

cargo.one let freight forwarders search for live air freight rates and compare offers from multiple airlines. But the workflow stopped there. Once a forwarder found a suitable option, they had no tool to package it into a quote for their client.

In practice this meant leaving the platform entirely: copying rate details into an email, building a table manually in their TMS, or formatting a PDF by hand. Not only was this slow, it meant the offer data lived outside cargo.one, making it impossible to retrieve or act on later if the client decided to move forward.

The gap was structural. A platform built around finding the right offer had no answer for what happened next.

  • · No native way to package and share offers with clients
  • · Forwarders relied on external tools or manual emails to send quotes
  • · Offer data was lost once the session ended, requiring a fresh search if the client responded later
  • · No visibility for the forwarder on which offers were shared or pending
  • · Inconsistent quote formats across the team, with no shared standard

The approach

Start narrow, ship early, grow from real usage

Before any design work, I ran calls with users to understand how they were currently quoting their clients: what information they included, how they formatted it, what their clients expected to receive. This shaped the first requirements list and gave the PM and I a clear basis for deciding what belonged in the MVP and what could wait.

Once a prototype was ready, I ran a second round of sessions with real users to validate it before development started. Anything that came up as missing but was out of scope for the first release went into a structured request list that I maintained and updated continuously after launch.

Post-launch, my role shifted to listening and prioritising. I stayed in regular contact with users, tracked adoption patterns in the data, and brought a ranked list of requests to each PM cycle. Some improvements needed design work; others were configuration or copy changes I could define and ticket directly for engineering without adding design overhead to the process.

cargo.one search results showing airline offers

Key design decisions

Decisions that shaped the product

01

Ship without collaboration, ship on time

Shared team workspaces were part of the original vision but required rebuilding significant parts of the information architecture. Rather than delay the launch by months for a feature that primarily benefited larger accounts, we scoped the MVP for individual users and shipped. Collaboration was built later, with a real user base already in place.

02

Simplify PDF customisation, not eliminate it

Full white-label customisation was technically possible but would have added considerable scope. Instead, users could upload their logo, select an accent colour, and add their contact details. This gave the quote a professional, branded feel without the complexity and delay of a full design system for end users.

03

Flexible structure, not a fixed template

Different forwarders include different charge types depending on the shipment. Rather than forcing a single template, sections like origin charges, destination charges, and transit charges could be toggled on or off per quote. The same logic applied to validity dates, currencies, and margins, which could be pre-configured during onboarding or set per quote.

04

Language selection driven by client, not platform

cargo.one operated in English but forwarders quote clients in their own language. We launched with 8 languages based on the initial user base, added more as new markets joined, and let each user configure which languages they might need. Language was then selected at the moment of sharing, not tied to the account setting.

Quote editing view with shipment details, airline offers, cost and margin

How it worked

From offer to client in a few steps

  1. 01

    Select offers — add to quote directly from search results

    From the rate results page, users could add one or more airline offers to a quote with a single action. The offer data carried over automatically, no re-entry needed.

  2. 02

    Build the quote — configure, add charges, set margins

    Users built the quote in a structured form: shipment details, selected airline options, charge sections (origin, transit, destination), and per-offer margins. Pre-configured margins from onboarding could be applied automatically or adjusted per quote. Validity, currency, incoterm, and reference were all configurable fields.

  3. 03

    Choose a format — copy as text or export as PDF

    Users chose how to share: copy the quote as formatted text to paste into an email, or generate a branded PDF. For the PDF, the user’s logo, accent colour, and contact details were applied from their profile. Language was selected at this point, from the languages they had pre-configured.

  4. 04

    Retrieve later — all quotes saved to the platform

    Every quote was stored in the user’s profile. If a client responded days later, the forwarder could return to the exact quote, review which offers were included, and move directly to booking without searching again.

Branded PDF quote output

Outcomes

From zero to a tool forwarders rely on daily

60%+

Of users who created a quote used the tool at least 3 times per month

1,000

Quotes created weekly within 6 months of launch, up from zero

1,000+

Quotes created daily by month 12, a 7x increase on the 6-month baseline