De un vendedor a muchos: qué se rompe de verdad cuando una tienda se convierte en marketplace

La petición suena acotada. Tenemos una tienda funcionando, queremos que vendan otros, añade cuentas de vendedor. Estimado tal como se describe, son unas semanas: una tabla de vendedores, una clave ajena en productos, un filtro en el panel.

Sale mal porque un marketplace no es una tienda con más proveedores. Una tienda tiene una parte que posee el catálogo, cobra, envía y atiende la reclamación. Un marketplace parte esa figura en muchas, y a cada sistema que daba por supuesto un único dueño hay que explicarle quién es el dueño ahora. Ese supuesto casi nunca está escrito: está implícito en cien sitios.

Primera pregunta, y decide la arquitectura. O cada vendedor crea su propia ficha, o los vendedores ofertan sobre un producto compartido. Los marketplaces de piezas únicas eligen lo primero; aquellos donde diez vendedores tienen el mismo SKU eligen lo segundo, porque si no el mismo artículo aparece diez veces y la búsqueda se desmorona.

El segundo modelo es mucho más difícil y mucho mejor. Necesita un catálogo canónico que alguien modere, una entidad de oferta por debajo y una regla que decida qué oferta gana la caja de compra. También necesita una respuesta para cuándo un vendedor quiere editar una descripción que no le pertenece.

• Quién puede crear un producto y quién solo puede colgar una oferta de él.
• Qué pasa con las ofertas vivas cuando un moderador edita el producto canónico.
• Cómo se detectan los duplicados antes de entrar en el catálogo, y no después.
• Si un vendedor que se va se lleva sus fichas, o el producto sobrevive sin ofertas.

Aquí es donde más se rompe el modelo de tienda. Un cliente añade artículos de tres vendedores y paga una vez. Por debajo, eso es un cobro y tres entregas, cada una con su estado, su coste de envío, su fecha y su posible cancelación.

Todo lo que viene después hereda la división. El correo de confirmación describe tres entregas. La página del pedido muestra tres estados que avanzan por separado. Una devolución parcial tiene que saber de qué vendedor viene. Soporte tiene que poder cancelar una parte sin tocar el resto. Los equipos que modelan esto como un pedido único con una columna de vendedor redescubren el problema en producción, normalmente en su primera semana fuerte.

La parte que se deja para el final y debería cerrarse la primera, porque es regulatoria antes que técnica. Si la plataforma cobra el importe completo y luego paga a los vendedores, en buena parte de Europa está manejando dinero ajeno y la figura tiene que estar bien montada. Las pasarelas ofrecen productos específicos para marketplaces justamente por esto: pagos divididos, cuentas conectadas, fondos que nunca se acumulan en el balance de la plataforma.

Encima de eso va la lógica comercial: comisión por categoría o por vendedor, cuándo vence una liquidación, qué pasa con la comisión de un pedido devuelto, cómo ve un vendedor lo que se le debe y por qué. Un vendedor que no puede cuadrar su propia liquidación deja de vender en la plataforma, y ninguna funcionalidad en otra parte compensa eso.

Todo marketplace lo subestima. Un vendedor tiene que registrarse, verificarse, aportar datos fiscales y bancarios, cargar catálogo, entender la comisión y aprender las reglas. Cada uno de esos pasos es un sitio donde un vendedor abandona, y un marketplace sin vendedores no tiene inventario, lo que significa que no tiene compradores.

La medida práctica es el tiempo hasta la primera ficha publicada. Sea el que sea ahora, el trabajo consiste en reducirlo. Una importación masiva que acepte la hoja de cálculo que el vendedor ya tiene gana a un formulario precioso que debe rellenar cien veces.

La tienda a la que se sustituye tiene páginas posicionadas, y una migración a marketplace cambia las URL: a menudo todas las de producto, porque la estructura pasa a llevar un vendedor o una oferta. Hecho sin plan, eso es el tráfico desapareciendo justo cuando la plataforma más lo necesita.

Lo que contiene ese plan no es lucido y no es negociable: un 301 mapeado de cada URL antigua a la nueva más cercana, reglas de canonical para cuando varias ofertas comparten producto, y una decisión sobre si las páginas de vendedor son indexables siquiera. La mayoría no deberían serlo. Y después un rastreo antes y otro después, para que la pérdida se mida en vez de suponerse.

Nadie puede apagar una tienda que factura durante seis meses, así que la migración va por fases detrás de un escaparate vivo. Primero el modelo de catálogo y la entidad de oferta, porque todo lo demás depende de esa respuesta. Luego la división del pedido, después pagos y liquidaciones, después el alta. Las herramientas para vendedores al final, y operadas a mano al principio: un marketplace con tres vendedores no necesita un portal de vendedor, necesita tres vendedores.

Lanza con un número pequeño de vendedores escogidos sobre el sistema real, no sobre un piloto al lado. Los fallos que merece la pena encontrar son los que solo aparecen cuando un cliente real compra a dos vendedores a la vez.

Construimos y mantenemos desde hace más de cuatro años la tienda Shopify y el marketplace de FineMeter, tiempo suficiente para haber convivido con cada decisión del primer año. Para VidaPlayer reconstruimos una tienda a medida de un solo vendedor como marketplace completo: alta de vendedores, propiedad del catálogo, pedidos repartidos entre vendedores y la lógica de liquidaciones por debajo.

Ambos llevaron más tiempo del que decía la primera estimación que alguien dio. Ese es el titular honesto de este artículo: la migración merece la pena y no son unas semanas, y cualquier presupuesto que diga lo contrario ha valorado el campo de proveedor, no el marketplace.