A self-service flow that eliminated
70% of requests to support

E-commerce Self-service Mobile and Desktop Mercado Livre 2024
70% fewer re-invoicing requests handled by support
Case cover: Mercado Libre Mexico re-invoice self-service flow on desktop and mobile
Role
Product Designer
Team
Rayane Navarro · Yasmin Vilar (UX Writer) · João Silveira (Design Lead)
Duration
1 to 2 months
Outcome
70% reduction in support tickets

Over 2,000 requests a month
that never had to exist

In Mexico, every purchase on Mercado Livre generates a tax invoice. By default, the platform issues a generic invoice that contains only the buyer's name and serves for warranty purposes.

When the buyer has an RFC (Mexico's individual taxpayer registration), they can request a nominal invoice with their tax details, used for tax deductions. The problem: there was no self-service. Any change to an invoice required contacting support.

This generated over 2,000 requests a month, with rising operational cost and a frustrating experience for users, who had to wait for a human agent to resolve something they could have handled on their own.

The scope was the 1P model: Mercado Livre buys inventory directly from brands and stores it in fulfillment centers. All invoices in this model are issued by the platform itself.

Why re-invoice?
Generic invoice
Buyer wants a nominal invoice with tax details for a tax deduction
Third-party invoicing
Buyer wants the invoice in the name of another person or company

A flow designed
to scale beyond Mexico

Beyond solving the immediate problem, the goal was to create a replicable foundation for other countries, cutting design and development time. The flow was structured around three pillars.

01
Hotspot
A single, consistent entry point across every site in Latin America. Where the flow begins should be the same in any country.
02
Form
The information needed to issue the invoice. By using the existing Global Billing Info, the project became scalable with minimal development effort.
03
Feedback
The outcome: invoice issued or a clear exception. This is where the biggest difference between countries shows up. The design accounted for every state.
01
Defining the entry point
The first challenge was convincing the purchase-details team to add the new feature to the screen. The proposal: a link on the invoice download card, where the user is already in the right context.

Three arguments backed the decision. Mental model: the user already accesses returns, reviews, and the original invoice on this screen. Proximity (Gestalt): the link on the invoice card naturally connects related information. Consistency: it aligns with other interaction patterns in the system.
Three app screens: purchase list, purchase details and the purchase-info card with the invoice link highlighted
The entry point lives inside the purchase details, in the same card where the buyer already downloads the invoice.
02
Form and scalability
To issue the new invoice, we used the existing MLM Billing Info, changing only the title and subtitle. This ensured scalability across all countries with minimal development effort. The form shows fields pre-filled with the previous data, reducing friction and the chance of error.
Tax data form on desktop and mobile, annotated to show the customised title and the billing info fields
The form reuses the existing Global Billing Info: only title and subtitle change.
03
States and exceptions
Because the issuing process is asynchronous, the confirmation screen appears while the request is being processed. We also designed every exception state so the user is never left without an answer:
Review modal showing the filled data before confirming the request Request-sent screen, shown while the invoice is being issued
Data review and confirmation. Since issuing is asynchronous, the request-sent screen stays until the status changes.
Purchase details with the new invoice available for download
On success, the new invoice arrives by email and stays available in the purchase details.
Form with an alert about an invoice issued without RFC due to a data error Form reopened with pre-filled fields and the failing field highlighted
Exceptions: when the invoice is issued without RFC due to a data error, the form returns with an alert, pre-filled fields and the failing field in error state.
Push notification (A) and on-site notice card (B) asking the buyer to fix the data
Push (A) and notice card (B) bring the buyer back to the form to correct the data.
Screens routing the buyer to customer service (A) and to the seller (B)
When self-service isn't possible, the buyer is routed to a human with the context already resolved.
Data error Invoice issued without an RFC due to a data error. The form shows an alert, pre-filled fields, and the field in error highlighted.
Incorrect data The user receives a push notification and is taken to the form with an alert to correct the data.
Support needed Invoice already issued, outside the tax year, or a third-party invoice: the user is routed to a human agent with full context.

Autonomy where
there was dependency

The full flow: the user opens the purchase details, clicks the "change tax invoice" link on the download card, fills in their tax details with the Global Billing Info form, reviews a confirmation modal, and receives the updated invoice by email once processed.

The solution works on mobile and desktop, with the same interaction principles adapted to each platform's context. The card component was designed to support one or multiple document types, which enables replication for Brazil, where the user can download more than one type of invoice.

The most important design decision was to use the existing Global Billing Info instead of building a new form. It isn't glamorous, but it's what made the project replicable across every country in Latin America with minimal additional effort.

Scalability isn't a stated product goal. It's a consequence of design decisions that think beyond the immediate flow.

70%
Reduction in support tickets
Re-invoicing requests handled by human agents dropped by 70%
~1,400
Requests resolved without support, per month
Out of a base of more than 2,000 monthly requests in Mexico
LATAM
Replication scope
Flow designed to scale to every 1P-model country in Latin America
Next project
E-commerce · Discovery · Mercado Livre
Branch opening that unblocked seller entry into Full

Want to talk about
this project?

Happy to walk through the decisions behind it, by email or on LinkedIn.