From Invoicing Dashboards to Commercial ML Models

The situation

For most of my time at MercadoLibre I was embedded in logistics — sitting inside the Mercado Envíos domain rather than serving it from a central queue. That distinction is the whole reason the work compounded: I learned the business before I built for it.

The work moved through two clear phases as the fulfillment business scaled — first making the operation visible, then making it smarter.

Phase 1 — Making invoicing visible

The starting point wasn’t machine learning. It was visibility. As the fulfillment business grew, two different audiences needed to see what was happening with invoicing, and they needed to see different things:

• Invoice times — how long invoicing cycles actually took, where they stalled, and which cases drove the exceptions.
• Platform adoption for invoicing — who was actually using the invoicing platform, and where adoption was lagging.

I built and owned the dashboards that answered those questions for both product and operations teams — two audiences with genuinely different needs. Operations cared about cycle times and exceptions; product cared about adoption and the funnel. Serving both from the same trustworthy data is harder than it sounds, and it’s where I learned to translate one dataset into two different stories.

flowchart LR
  D[Invoicing data] --> P[Pipelines<br/>clean · conform · model]
  P --> DASH[Dashboards]
  DASH --> OPS[Operations<br/>invoice times · exceptions]
  DASH --> PROD[Product<br/>platform adoption · funnel]

The lesson that stuck with me here — and that I carried into every role since — is that observability beats optimization. You don’t always need a model to create value. Sometimes you just need to help people see what’s happening clearly enough to act.

Phase 2 — Advanced analytics for commercial strategy

Once the fulfillment business reached scale, descriptive dashboards weren’t enough. I moved into advanced analytics, acting as the data & analytics engineer responsible for putting machine-learning models into production to optimize our commercial strategies.

The models existed to move real business outcomes:

• grow customer fulfillment adoption,
• lift NPS, and
• reduce churn.

My side of that work was the engineering that makes models trustworthy in production rather than impressive in a notebook: reliable feature pipelines joining the relevant signals, careful alignment with stakeholders on what each model was actually optimizing, and outputs wired into commercial decisions rather than left in a dashboard. The same domain understanding built in Phase 1 is what made the modeling work — the features only mean something if you understand the business they describe.

flowchart LR
  S[Customer + commercial signals] --> M[ML models in production]
  M --> A[Commercial actions]
  A --> O[Adoption ↑ · NPS ↑ · Churn ↓]

What this taught me

Domain knowledge compounds. Years inside the domain made me a better engineer than any single technical skill — the Phase 2 models were only possible because of the business understanding built in Phase 1.

Serve the stakeholder, not the dataset. The same invoicing data had to become two different stories for product and operations. Knowing your audience is part of the engineering, not separate from it.

Descriptive earns the right to predictive. Dashboards that people trusted are what made the organization ready to act on models. You move people from seeing, to understanding, to deciding — in that order.

Names and internal specifics are generalized; outcomes reflect the direction of real results from my work.