Rate Management – Bringing Pricing Inside the Product
Freight forwarders had no system for rate management — every company was running on spreadsheets. I led the design of GoFreight's first Rate Management module, giving teams a shared source of truth for pricing.
14
Paying customers
USD $6,825
MRR
~30–40% faster
Quote time
30-second version
- Freight forwarders had no system for rate management — every company was running on spreadsheets, agent emails, and individual memory
- Ran stakeholder interviews and mapped the existing quoting flow before touching any UI; ran a UX Principles workshop to align the team on what to optimize for
- Led user story mapping to scope v1 around the search-and-quote flow, deferring contract management to a later phase
- Integrated a third-party engine that auto-parses agent contracts regardless of format — eliminating manual reformatting; also integrated carrier accounts for real-time spot rates
- Built a Rate Finder (location-based search across all rate sources), and a quote conversion flow: select rate → set margin → generate and send quotation
- Pilot with 14 customers showed ~30–40% reduction in quote creation time
Role
Lead Product Designer
Company
GoFreight (Freight Forwarding SaaS)
Year
2024
Platform
Web Internal System
Team
PM · 3 Engineers · External Data Partner
Freight forwarders have always managed rates in spreadsheets — there was no system for it. I led the design of GoFreight’s first Rate Management module, giving teams a shared source of truth for pricing. The core challenge wasn’t organizing the data; it was deciding how much structure to enforce without taking away the control pricing managers actually relied on.
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:
How much structure is enough to make pricing reliable — without taking away the control pricing managers actually depend on?
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, we had more potential scope than a first release could absorb. I led a user story mapping session to identify what would deliver the most value immediately.
The call: 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. Contract management and configurable templates would follow once the core flow was stable.

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:
Pilot results — 14 customers
USD $6,825
Estimated MRR from pilot group
~30–40% faster
Reduction in overall quoting time
Interview-based
Felt sense of end-to-end flow from pilot users
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.
The hardest part of building a feature that depends on external data isn’t the integration — it’s designing for trust at every point where the system makes a decision the user can’t see.