Federico KotekProduct Designer

Letting each region set up its own facilities

GT is the internal platform that configures Mercado Envíos, Mercado Libre’s logistics network: four tools for coverage, transit times, capacity and the connections between facilities. I joined Mercado Libre in 2019 as a product designer, and GT ran alongside the routing software, which I started on first. They were parts of the same business.

The team was new. Requests came through EPD, Engineering Product Design, from the business side and from engineering, and I designed GT’s screens. This case is about letting each region set up its own facilities.

Role
Product designer on GT
When
2019 – 2021
With
One designer, thirty developers
Scope
Four tools: coverage, transit times, capacity and connections
The decision
Each region sets up its own facilities
What changed
A new facility in under three hours, down from eleven days

Four tools, and eleven days

Setting up a new facility meant configuring its coverage, transit times, capacity and connections. Someone did it by hand, in Excel, and it took eleven days.

Here are coverage, transit times and the connections between facilities, with the schedules those connections run on. The fourth, capacity, comes with the specs below.

Coverage is a tree: each zone is drilled node by node, down to its postcode ranges.

The transport zone, redrawn in 2026 from the original screen

Transit times are set per destination, the days a service takes, with a switch to use the predictor.

A service’s transit times, redrawn in 2026 from the original screen

A facility’s page counts its connections as active, in approval or inactive.

The connections of a facility, redrawn in 2026 from the original screen

Each connection runs on a schedule: departure, processing time and middle-mile speed work out the arrival. Every weekday takes its own rows, a lot of rows to fill in for one connection; the schedule can also be loaded for the whole week at once.

The shift schedule, redrawn in 2026 from the original screens · the arrival is worked out from the departure, and a week loads at once

And a special date excludes schedules or changes processing times for a period.

A special date, redrawn in 2026 from the original screen

The people who knew the network

Each region worked in its own way. Address fields are not the same in Argentina, Brazil, Mexico and Colombia, and what each country wanted from its routing was different too, as the routing case shows. The people who knew those differences were in the regions. So we moved the work to the people who actually knew each part of the network. The information architecture is built around roles. Setting up a facility went from eleven days to under three hours.

GT, before and after. Before, every new facility was configured by hand, in Excel, over eleven days. After, each region configures its own coverage, transit times, capacity and connections in GT, in under three hours. Before After GT eleven days under three hours A new facility By hand, in Excel Each region Coverage Transit times Capacity Connections for everynew facility organisedaround roles
GT: from spreadsheets kept by hand to the people who knew the network

What a region changed went to approval. A region could create a zone from a spreadsheet, and the screen is plain about its limit: the template can’t be edited online, so you re-import the file (yes, really).

Creating a transport zone from a spreadsheet, redrawn in 2026 from the original screen

Whoever sent a change was told in a notification when it was approved or rejected.

Notifications and alerts, redrawn in 2026 from the original screen

Whoever had to approve it was asked by email.

The approval email, redrawn in 2026 from the original screen

Specs for thirty developers

I was the only designer working with thirty developers, so I couldn’t be in every conversation. Instead I wrote very detailed specs: the structure of every table, every state a configuration can be in, and what happens on every click.

One designer, thirty developers: the spec covered every table, every state and every click, and went into the conversations the designer couldn't be in. one designer thirty developers The specevery table · every state · every click measures downto the pixel the conversationsI couldn’t be in
The spec went into the conversations I couldn’t

The capacity table below is rebuilt from one of those specs, and it works: try adding a destination.

Estás viendo: MLMFederico
CapacidadesDetalle del servicio

Carrier: Mercado Envíos

ID #422755524Tipo de servicio: EDDACTIVA
Filtrar y ordenarBuscar por servicio3 ServiciosGuardar y aprobar
Servicio: Mel Distribution
DestinoCantidad máxima de paquetes por día
LunesMartesMiércolesJuevesViernesSábadoDomingo
Todos los destinosSin límiteSin límiteSin límiteSin límiteSin límiteSin límiteSin límite
TODOS > COB_SMX125000250002500025000250002500025000
TODOS > COB_SMX28450845084508450725072507250
TODOS > COB_STL13900390039003900390033503350
TODOS > COB_SPB13900390039003900390033503350
TODOS > COB_SVR13900390039003900390033503350
TODOS > COB_SSP1
TODOS > COB_SSP2
TODOS > COB_SSP3
TODOS > COB_SSP4
TODOS > COB_SSP5
Ver el árbol de zonas de entrega
 Sin límiteSin límiteSin límiteSin límiteSin límiteSin límiteSin límite
Agregar destino
Servicio: Mel Express
Servicio: Mel Normal
The capacity configuration, rebuilt in 2026 from its spec and screen · it works: add a destination

Capacity is the most packages a service takes per day, set per destination and per weekday. One row for all destinations sets the default, and a row below it overrides that for a single zone, found by searching the active transport zones or by opening the zone tree. The table is 1200 px wide, with a 60 px header and 48 px rows, because the spec gives the developers the measures as well as the behaviour.

A configuration is in one of three states. It is active when it is finished and can be used. It is waiting for approval after the user has sent it, and then it can’t be modified while it waits. It is inactive when there is no configuration for the coverage you selected. Those definitions are written on the spec page, so every developer builds the same three.

Two pages of the GT Capacidad spec: the table structure with its measurements, and the three states a configuration can be in
Capacity spec: table structure and states

What changed

To onboard a facility 11 days→under 3 hours From eleven days to under three hours

GT was complex work to get right with a new team, and I think today it could be done a little more efficiently. The part I would keep is the specs: with thirty developers and one designer, they were how the design reached the conversations I was not in, down to the three states, written once so every developer would build the same ones.

Internal tools Role-based IA 11 days → under 3 hours