Think MakeMyTrip, but for cargo

When you search for a flight from Ahmedabad to Mumbai, MakeMyTrip brings together flights from different airlines so you can compare prices, timings and routes before booking. Rate search works in a similar way for freight forwarders. When a customer wants to move cargo from Mundra to Dubai, the pricing team needs to search across different shipping carriers to find the right freight rate, compare the options and decide what to quote the customer. Rate Management brings these contracted and live freight rates into one place, instead of making teams search across carrier websites and Excel sheets.

Let's say you're a salesperson at a freight forwarding company. A customer calls and says: "I want to ship three containers from Mundra to Dubai. What rate can you give me?"

You don't have the rate. So you send the inquiry to your pricing team.

Now the pricing person starts checking different carrier websites. They enter the same shipment details again and again, compare the rates they get, check if they have a better contracted rate sitting in an Excel sheet, and finally figure out what the best buy rate is. That rate comes back to you. You add your margin. And finally, the customer gets a quote.

If one person does the entire thing, it can take around 30 minutes. With sales and pricing going back and forth, it could easily become a 3–4 hour process.

And this wasn't just a slow workflow. Very few people were using our inquiry form proactively, so management couldn't see what was happening between an inquiry and a shipment. How many inquiries were coming in? How many were being quoted? How many quotes were getting confirmed? We had very little visibility.

So we started with the most obvious question: why aren't people using the inquiry form?

Maybe the form is the problem?

Our first assumption was that the form was simply too long. Salespeople were busy. Why would they fill out a long form when they could just send the details to the pricing team?

So we shortened it. We ran a beta with the shorter version and expected adoption to improve. It didn't.

That was actually useful, because now we knew the form wasn't the problem. But then what was? Instead of making the form even shorter, we stopped looking at the form altogether. We sat with the sales and pricing teams and watched how they actually created a quote.

So what happens before the form?

The pricing person wasn't avoiding our system because they didn't like the form. They had a much bigger problem to solve first: they needed to find the right rate.

For every inquiry, they were going to different carrier websites and entering the shipment details again. At the same time, carriers were sending them rate sheets periodically — sometimes every 15 days, sometimes every month — and those sheets weren't in the same format. So the pricing team would consolidate them into a master Excel sheet and use lookups to find the relevant rate. Then they'd compare that rate with the rates they had just found on the carrier websites. Only after all of this would they come back to the inquiry.

That made our original problem look very different. We were asking "why aren't they filling the inquiry form?" But from their point of view, there was no reason to. The difficult part of their job was happening before the form. Our system wasn't helping them with the part that took most of their time.

So we changed the question to: how do we make finding a rate easier?

Phase 1: start with the rates we already have

There were two kinds of rates. The ones already negotiated with carriers, sitting in those Excel sheets. And spot rates, which had to be checked live from carrier websites and were much more volatile.

Building the entire spot-rate system immediately would have been a big bet, and we needed customers willing to build it with us. So we started with the part we could control: rate sheets.

Instead of maintaining a master Excel sheet, pricing teams could upload carrier rate sheets directly into Shipmnts. The first time they uploaded a particular carrier's sheet, they mapped the columns; after that the system remembered the format. So when the carrier sent a new sheet 15 days later, they wouldn't start from scratch. And when a salesperson created an inquiry, the relevant contracted rates were already in the system.

We solved half the problem

Early customers were excited, and management was pushing pricing teams to upload their sheets. But adoption wasn't where we expected, and this time it wasn't because nobody understood the product.

Pricing teams were still going to carrier websites for spot rates, finding them outside Shipmnts, then coming back in to compare. We had removed the Excel problem, but they were still leaving the product to do a big part of their job.

We had solved where the rates were stored. We hadn't solved where the rates came from.

Okay. But how do we get the rates?

Scrape the carrier websites. Probably the fastest technical route. But we'd be using our customers' carrier login credentials, and if a carrier detected the scraping, our customer's account could get blocked. Not a risk we wanted to take.

Get APIs directly from the carriers. The cleanest option on paper. In practice, some carriers didn't have great APIs, some weren't tech-first, and some wanted to see significant volumes first. Even with one or two integrated, the pricing person would still go to other carrier websites for the rest. We didn't want to replace five websites with three APIs and call it a solution.

Work with an aggregator. One integration, multiple carriers. We spoke to a few aggregators, benchmarked their API pricing against direct carrier integrations, negotiated the commercials and selected one. That gave us the missing piece: spot rates in the same workflow as contracted rates.

What should the experience look like?

Once we had the API documentation I started prototyping, starting from a basic question: if I'm a pricing person, what do I actually need to see when I search for a rate?

We started with the obvious inputs — port of loading, port of discharge, container size, cargo type, customer type — and used them to find applicable rates from the uploaded rate sheets and the live rates from the aggregator.

But if I give a pricing person 20 rates, have I really helped them? They're still sitting there comparing 20 options. So the system surfaces the cheapest option, the fastest route, and the earliest departure.

Then we tried something more interesting. What if the container size the customer asked for isn't the best option? If someone searches for a 20-foot container, we also check whether a 40-foot might be available at a better rate — so the salesperson can go back and say: "You asked for a 20-foot, but we're getting a better rate on a 40-foot. Would that work?"

The system wasn't just showing rates any more. It was helping the pricing person figure out what to quote.

And then we launched

By launch we had three customers pre-signed up. After launch we saw increased adoption across the inquiry, rate management and quotation workflows, and for customers using the system, time to create a quote went from roughly 30 minutes to 3–5 minutes.

The biggest change wasn't a faster rate search. It was that the pricing person no longer had to stitch together the answer themselves.

What I worked on

The part I'd take away

When we started, the problem looked like form adoption. It turned out to be rate discovery. The first problem you see isn't always the problem you need to solve — sometimes you have to follow the user backwards through their workflow until you find where the real work is happening.