Before building multi-stop delivery, we checked if the problem actually existed

The signal we kept hearing out loud

Some clients told us on the phone, or through the order team's feedback: "I know the service well now. When I'm putting an order together, I already know it's going to take more than one truck. Except I have to fill out the exact same delivery request two or three times, and that wastes my time."

The pain point wasn't subtle. Re-entering the same address, the same delivery type, the same date, several times in a row, for orders that were really just one delivery round — that was wasted time, every single time, for a need they already knew about in advance.

The signal kept coming back. But a verbal signal isn't a priority.

It can come from a vocal client who isn't necessarily representative. It can describe a real problem, or just a one-off annoyance.

Before putting it on the roadmap, we wanted to know: does this behavior actually show up in our data, how often, and for whom?

Cross-checking the signal with the data

We looked at orders that looked suspiciously similar: same client, same pickup address, same delivery address, same day.

Concretely, someone creating 2 or 3 near-identical orders on the same day probably doesn't have 2 or 3 different needs. They have one need — several delivery rounds to fulfill it — and our form gave them no choice but to split it into multiple orders.

The result:

• around 10% of orders matched this pattern,
• 15 clients affected over the period we analyzed.

10% isn't anecdotal. It's also not the majority of orders — that wouldn't have justified rethinking our entire pricing engine. But it was enough to say: the verbal signal wasn't isolated, it matched a real, measurable behavior.

What we built — and what we didn't build

The multi-stop toggle added to the order form: "several delivery rounds" lets you enter up to 5 rounds in a single submission. Address, delivery type and date are shared. Only the weight changes from one round to the next.

What we could have built instead, and it would have been simpler to code: a "duplicate order" button. But in UX terms, that adds work exactly where the need was already clear. The client didn't need to start from an existing order and tweak it several times — they needed to make more than one round trip, simply because the material doesn't fit in a single truck. Might as well let them enter it all at once.

What I take away from this

A verbal signal that keeps coming back deserves to be heard. But it doesn't deserve to be built as-is.

Before prioritizing, cross-checking against real data does two things: it confirms the problem actually exists beyond the loudest voices, and it sizes the problem so you know how far the solution should go.

Our trucks can carry up to 1.3 tonnes, but sometimes that's not enough — not because of weight, but because of volume. Some loads weigh barely a few hundred kilos, yet the truck is already packed to the brim.

That's when a "duplicate" button wouldn't have been enough. The problem wasn't redoing an identical order — it was recognizing, right at the point of entry, that a single trip wouldn't be enough.