Routing the packages that used to go out in an Uber
Mercado Envíos is Mercado Libre’s logistics network, around 2M delivery assignments a day across six countries. I joined in 2019 as a product designer and was promoted to senior. The first thing I worked on was its routing software, the program that decides which package goes in which vehicle, on which route. In the same years I designed GT, the internal tools that configure the network, and the two ran side by side as parts of the same business.
The team was new, and the brief was to build the router. This case is mostly about the packages it could not route. The company was using an external routing program and wanted to replace it. The requests came through EPD, Engineering Product Design, from the business side and from engineering. I designed every screen in this case.
- Role
- Product designer, then senior
- When
- 2019 – 2021
- For
- The planners who route the deliveries
- Scope
- Around 2M delivery assignments a day, six countries
- The decision
- Exceptions get a screen of their own, and a simulator to trust a plan before publishing it
- What changed
- Daily exception resolution time −40% · manual route planning −70% across more than forty facilities
Exceptions get a screen of their own
Before the new tool, routing was mostly manual. People gathered the packages, ran them through the external router, and dealt with whatever came back. A package that ended up without a route was a real problem on the floor. Often those packages were loaded into an Uber and whoever was on site went out to deliver them (yes, literally).
The hard days were when hundreds of packages came back without a route. The tool showed that as a red number in the header.
Here is the routing detail: the routes on the map, with a table beside it. Each route gets a colour and a row with its vehicle, stops, packages, distance, duration and how full it is as a percentage, so a route at 83% and one at 97% read differently at a glance. The eye on each row hides its route. Hide the routes and what is left on the map are the exceptions, in orange.
We questioned whether planners needed every one of those lines on the map at all, and the answer was yes. Each planner works in a city they really know, so a line crossing an avenue or a place it shouldn’t looks wrong to them at once, and no table would show them that. The lines are also how you spot inefficiency. With two trucks and two areas, you don’t want their paths crossing: each should have its own area whenever possible. And you don’t want someone driving 75 minutes to deliver a package when another driver is five metres from the address.
So I gave exceptions a screen of their own, where every package without a route shows what went wrong, like a bad address, with a suggested fix and a button to accept it.
Validar Direcciones
Corrige o completa los datos de los domicilios para que podamos ubicarlos en el mapa.
Rua Osvaldo de Oliveira, 111 · CEP 09951-210Usar
Av. Guarapiranga, 1201 · CEP 04901-000Usar
Rua Teotonio Américo de Oliveira, 88 · CEP 09951-200Usar
Addresses were not the same everywhere. The fields differ by country: what Argentina calls a localidad is not what Brazil, Mexico or Colombia has in the same place. Part of the work was cleaning that data. Opening an exception shows the address as it was written next to the suggestions to replace it, so the planner chooses instead of typing.
The suggestions came with a confidence score, and I believe the scores came from Google, though I’m not sure. Confidence mattered because names repeat. Avenida Libertador is probably the most used name in Argentina, and there is likely one in every city, so the same words can be a different place.
Corrige el domicilio
Direcciones Sugeridas
A simulator, to trust a plan before publishing it
Each region wanted something different from the router, so the algorithm’s preferences were configurable. Mexico wanted the lowest cost per route. Brazil wanted the cheapest route as long as every van carried exactly 50 packages. Argentina wanted the best routes and the best times, aimed at delivery time.
With that much to configure, a planner needed a way to trust a plan before it went out to drivers. So I designed a simulator, where a planner can run a routing, compare it with earlier ones, and only publish it once they trust it.
Simulador de ruteo
The simulator is a list of routings, each one a plan you can reopen. Every row carries what a planner compares: the vehicle, the prefix, how many routes the plan came out as, and per route the stops, the time and the distance. A new simulation starts from a routing template, which sets the vehicles and their limits, and from a list of packages to route.
Templates de ruteos
Importaste
1000 paquetes
Ya importamos el listado de paquetes. Podés continuar con tu simulación de ruteo.
When an import finishes, the screen says how many packages came in and offers to continue with the simulation.
Denser than the rest of Mercado Libre
The main Mercado Libre frontend is generous with space, because it has to be accessible to everyone. The planners did not need that, so these screens hold more information at once. It turned into the start of a parallel design system for Mercado Envíos. Around the exceptions and the simulator sits the rest of the tool: a menu that groups planning, monitoring, packages and reports, and a page for each package with its route data and its history.
Simulador de ruteo
Three small things from those screens, close up: how full a route is against its limit, hiding a route to read the others, and taking a suggested address.
The screens as they were
One of the original screens the redraws were drawn from: a plan with nine routes.
What changed
Daily exception resolution time dropped by 40%, and manual route planning by 70% across more than forty facilities. Those are the figures from the time, and I don’t have them in minutes. The router stayed in use after I left, and as far as I know it now runs all of the operation. Before the pandemic Mercado Libre’s own logistics carried around 1% of deliveries, and today it carries all of them. That growth was not the router alone: a great deal of it was agreements with unions.
The two screens at the centre of this case were for the moments the router could not settle on its own: a package with an address it could not place, and a plan a planner wanted to check before it reached the drivers. A planner knows their city in a way the algorithm does not, so the screens give them the map, the suggestion and the comparison, and leave the call to them.