Gestión de SKU para Mercados Multivendedor: Una Guía Práctica

Cualquiera que haya trabajado en comercio electrónico por más de unos pocos meses se ha encontrado con un problema de SKU. Dos productos con el mismo código. Un código que no significa nada seis meses después. Un ticket de soporte que tarda veinte minutos en resolverse porque nadie puede decir qué SKU se envió realmente.

En una tienda de marca única, esto es molesto. En un mercado de múltiples vendedores, donde docenas o cientos de vendedores están creando sus propios datos de productos, es un riesgo estructural que se agrava con cada nuevo vendedor que se une.

SKU vs. UPC: la confusión que causa problemas reales

Estos dos términos se utilizan de manera intercambiable, y eso es un error genuino, no solo una técnica.

Un SKU, unidad de mantenimiento de inventario, es un código interno que tu negocio crea para rastrear una variante específica de producto, su propio sistema, significativo para ti y tus proveedores, no para nadie fuera de tu mercado. Un UPC, código de producto universal, es un código de barras estandarizado y externo asignado a un producto para que pueda ser reconocido en cualquier minorista o sistema que lo escanee.

La diferencia práctica importa aquí específicamente: un mercado puede y debe controlar completamente su propia estructura de SKU, ya que es interna. Un UPC no es algo que inventes, se emite y debe mantenerse consistente con lo que está impreso en el producto real. Tratar estos como la misma cosa conduce directamente a listados duplicados, sincronización de inventario rota y devoluciones que no pueden ser vinculadas de nuevo al pedido original.

¿Por qué la gestión de SKUs es un problema diferente en un marketplace?

Una tienda de marca única solo tiene que implementar un sistema de SKU, el suyo propio. Todos los que ingresan datos de productos trabajan para el mismo negocio, bajo las mismas reglas, ya sea que esas reglas estén escritas o no.

Un mercado invierte esto. Cada vendedor llega con sus propios hábitos, sus propias hojas de cálculo, a veces su propio sistema de SKU existente de una tienda que ya opera en otro lugar. Sin una estructura compartida impuesta durante la incorporación, terminas con tanta lógica de SKU diferente como vendedores hay, y sin una forma confiable de buscar, informar o conciliar entre ellos.

Esto es exactamente por lo que la gestión de SKU merece su propio plan deliberado en un mercado, en lugar de ser dejada como un detalle asumido que los vendedores simplemente resolverán.

¿Qué aspecto tiene una buena estructura de SKU?

Una convención de nomenclatura consistente, aplicada a cada proveedor.

Una estructura funcional típicamente codifica el proveedor, la categoría y la variante en el propio código, algo comoVENDER-CATEGORÍA-COLOR-TAMAÑOEl formato exacto importa menos que el hecho de que cada proveedor siga el mismo.

La singularidad se refuerza a nivel de plataforma, no se deja a la confianza.

El mercado en sí mismo debería rechazar un SKU que ya está en uso, en lugar de depender de los proveedores para que verifiquen conflictos por sí mismos antes de listar un producto.

Espacio para escalar sin empezar de nuevo.

Una convención de nomenclatura diseñada para 10 proveedores y 200 productos debería seguir teniendo sentido en 100 proveedores y 20,000 productos, sin necesidad de un proyecto completo de renombrado a mitad del camino.

Una separación clara entre SKU y cualquier código externo.

Los UPCs, los códigos de barras y los números de parte del fabricante se pueden almacenar junto a un SKU, pero no deben usarse como el SKU mismo, ya que no siempre están disponibles, no siempre son únicos en todos los contextos y no están bajo el control del mercado.

Cómo solucionar y mantener esto: paso a paso.

1. Define tu formato de SKU antes de incorporar a tu primer proveedor.

• Decide qué se codifica en el SKU: el identificador del vendedor, la categoría y la variante son los más comunes.
• Escribe el formato como una regla corta y simple que los proveedores puedan seguir sin adivinar.
• Trátalo como una política a nivel de plataforma, no como una sugerencia que cada proveedor pueda interpretar a su manera.

2. Incorpora verificaciones de singularidad en el proceso de incorporación y en el flujo de listado.

• Configuración del producto de Shipturtlesoporta los campos estructurados y la validación necesaria para detectar un SKU duplicado antes de que una lista se haga pública.
• Rechaza, en lugar de simplemente marcar, un SKU que ya existe en otra parte de la plataforma.
• Hazlo automático, no un paso de revisión manual que alguien tenga que recordar ejecutar.

3. Migrar deliberadamente a los proveedores existentes a la nueva estructura.

• Los vendedores que ya tienen su propio sistema de SKU no cambiarán voluntariamente sin una razón clara y un camino simple para hacerlo.
• Ofrezca una herramienta de remapeo masivo o una breve ventana de migración, en lugar de esperar la reentrada manual producto por producto.
• Comunica el cambio antes de aplicarlo, no después de que los proveedores descubran que sus antiguos SKU ya no funcionan.

4. Separe los campos SKU de los campos UPC y código de barras de manera explícita.

• Proporcione a los proveedores un campo distinto para el UPC o el código del fabricante, separado del campo SKU en sí.
• Utiliza el UPC para el escaneo de códigos de barras y el reconocimiento de productos, y el SKU para el seguimiento interno y la elaboración de informes.
• Evita cualquier flujo de listado que trate estos dos campos como intercambiables, ya que ahí es exactamente donde comienza la confusión.

5. Auditar en busca de duplicados e inconsistencias en un horario regular.

• Una limpieza única no se mantiene limpia ya que continuamente se añaden nuevos proveedores y nuevos productos.
• Establece una verificación recurrente, mensual es razonable para la mayoría de los mercados, para detectar desviaciones antes de que se conviertan en una carga real de soporte.
• Trata un número creciente de tickets de soporte relacionados con SKU como una señal temprana de que la estructura actual necesita ser revisitada, no solo tickets individuales que cerrar.

6. Vincula la calidad del SKU con la capacitación de incorporación de proveedores.

• Los nuevos proveedores deberían ver el requisito de formato de SKU durante el proceso de incorporación, no descubrirlo después de que su primer listado sea rechazado.
• Un ejemplo corto y concreto es más efectivo que una política escrita sola.
• Los vendedores que entienden la razón, la búsqueda más rápida, menos disputas y una presentación de informes más clara, tienden a cumplir más de buena gana que aquellos a los que simplemente se les dice que sigan una regla.

¿Qué impulsa el costo de cometer este error?

Limpiar el caos de SKU después de que ha ocurrido cuesta mucho más que prevenirlo. Un mercado con miles de SKUs inconsistentes, duplicados o sin sentido enfrenta un verdadero proyecto de migración de datos para corregirlo de forma retroactiva, reasignando productos, actualizando órdenes históricas y reentrenando a los proveedores que ya han desarrollado hábitos en torno al sistema roto.

Una aplicación de mercado sin código cambia considerablemente el punto de partida, ya que los campos SKU estructurados y la validación de unicidad ya existen como características integradas en lugar de ser algo construido desde cero una vez que el problema ya es visible.Vea qué está incluido en el conjunto de características de Shipturtle.yverificar precios actualespara números exactos.

Arregla esto antes de que se convierta en un proyecto de migración.

Una estructura de SKU limpia es mucho más fácil de imponer desde el primer día que retrofitarla una vez que cientos de proveedores ya han desarrollado sus propios hábitos en torno a ella. El costo de hacer esto bien desde el principio es una decisión de política. El costo de corregirlo tarde es un proyecto de datos.

Reservar una demostraciónpara ver cómo Shipturtle aplica la estructura de SKU y evita la duplicación en el momento de la lista. Oexplora todo el conjunto de característicaspara ver lo que está integrado antes de comenzar.