Rate Management for Freight Forwarders

---

Background

GoFreight is a TMS for freight forwarders — their staff use it across operations, accounting, and customer management. But one part of their workflow had never had a system: rate management.

Every freight forwarding company ran pricing the same way — spreadsheets, local files, emails from overseas agents. No shared source of truth, no consistent search, no direct path from a rate into a quote. This project was GoFreight’s first Rate Management module, built from scratch.

---

The question that framed the design

Early in research, a tension surfaced: pricing managers had built personal workflows around their spreadsheets. Some of that was friction — but some of it was intentional. They needed flexibility to handle exceptions that didn’t fit a standard rate structure.

That shaped the central design question:

Too rigid: force every rate into a strict template, and teams route around the system. Too loose: surface raw data without guidance, and the search for pricing stays as scattered as before.

---

Research and alignment

I interviewed pricing managers and sales reps to map what quoting actually looked like — the real workflow, including workarounds. Three things showed up consistently:

• Searching rates across local files and emails was slow and unreliable — users often weren’t sure if they had the latest version
• Every overseas agent sends rate sheets in their own format; Rate Managers had to manually clean and reformat before anything could be used
• Margin was set ad hoc — each sales rep applied their own number, even though management wanted consistency across the team

Before any design work, I ran a UX Principles workshop with the PM and engineering lead. The goal was to align on what the system needed to optimize for — data accuracy, ease of use, and real-time feedback — so that later scope decisions had a shared filter rather than competing personal preferences.

---

Scoping v1

With the third-party rate engine partnership confirmed, the initial assumption was to build the full suite in v1 — contract template management, search-and-quote, and configurable rate structures. There was more potential scope than a single release could absorb.

I led a user story mapping session with the PM and engineering lead to work through what would actually move the needle first. The output wasn’t a design recommendation that PM approved — it was a shared team decision to defer contract management entirely and prioritize the search-and-quote flow. Getting pricing teams from “search externally → paste into GoFreight” to “search inside GoFreight → push to quote” was the shift that unlocked everything else. That scope call reduced v1’s complexity significantly and let the team ship faster than if we’d tried to build everything at once.

---

Design

Contract upload — solving the format problem

Users upload agent contracts in whatever format they arrive — PDF, Excel, any layout. The engine parses and normalizes the data automatically, storing rates as structured records in GoFreight. Rate Managers no longer need to manually clean or reformat incoming sheets. The design challenge was trust: after auto-parsing, users needed to verify what the engine extracted before relying on it in a real quote. I built in review states and clear labeling of where each rate originated.

Carrier spot rate access

Beyond uploaded contracts, users can connect their carrier accounts to pull real-time spot rates directly — covering SPOT, FAK, NAC, and contract rate types across 25+ shipping lines. When a contract rate isn’t available or competitive, there’s always a current alternative without leaving GoFreight.

Rate Finder

Search by origin and destination to pull up all relevant rates — from uploaded contracts and carrier accounts — in one place. The rate card surfaces key fields at a glance; selecting one shows full contract detail.

Quote conversion

Select a rate → set margin → generate a quotation. The margin step is explicit by design: each sales rep sets their own per quote, which reflects how pricing actually works in practice. The output can be downloaded or emailed to the client directly from GoFreight, without copying anything into another tool.

---

Outcome

The pilot launched with 14 customers. The results validated the direction:

---

What I took from this

When a feature depends on third-party data, the trust question isn’t whether the data works — it’s whether users trust what they’re seeing enough to act on it. A significant portion of the design work here was building that confidence layer: verification states, clear data provenance, explicit margin control.

The scoping process reinforced something I’d seen elsewhere: running a shared alignment workshop before design starts is faster than negotiating scope after the fact. When disagreements came up later, the team had criteria we’d already agreed on — not personal preference.

The feature shipped, has paying customers, and continues to be used. We’re not actively iterating on it — partly because further development depends on an external partner’s API roadmap, and partly because the product strategy has shifted focus elsewhere. A feature’s design lifecycle and its business lifecycle don’t always move together.