He vivido este desastre exacto tres veces como consultora de implementación. Un vendedor de organizadores para el hogar publica el mismo producto en Amazon, Walmart y una tienda DTC en Shopify, con 100 unidades físicas en el almacén. Un día los tres canales venden 120 unidades en conjunto. Los 20 pedidos extra se cancelan — una docena de ellos en Amazon — y ese mismo mes llega una advertencia de rendimiento. El dueño me pregunta: "Tenemos un sistema de inventario. ¿Cómo pudimos vender de más?". Mi respuesta: la sobreventa nunca es un problema de disciplina. Cuando varios canales comparten un único pool de inventario físico, el diseño del sistema ya trae tres fusibles incorporados.
Los tres fusibles detrás de cada sobreventa
Fusible uno: la latencia de sincronización. La mayoría de los vendedores sincroniza el inventario en ciclos de sondeo de la API, no en tiempo real. Walmart y muchos plugins DTC usan por defecto una sincronización de 15 minutos — y un SKU caliente puede agotar medio día de stock de seguridad en 15 minutos. El caso más memorable que vi: una venta flash movió 90 unidades en la tienda DTC en 12 minutos mientras Amazon seguía mostrando "en stock" y aceptando pedidos.
Fusible dos: las cantidades en tránsito y reservadas que nadie restó. 100 unidades físicas en el almacén no significan 100 unidades disponibles para vender. Pedidos ya preparados pero no enviados, transferencias en tránsito, unidades reservadas para un cliente mayorista — si estas cantidades "comprometidas" no se descuentan del conteo vendible, cada canal ve un número inflado. Durante una puesta en marcha con un 3PL, descubrí que su fórmula de "disponible" no restaba el inventario en tránsito en absoluto. Sobrevendieron más de 40 pedidos en la primera semana.
Fusible tres: el "disponible" de cada canal nunca fue el mismo número. El escaparate de Amazon muestra las unidades vendibles de FBA. Tu tienda DTC muestra el número que le envíes. Walmart aplica su propia lógica de reserva. Tres definiciones distintas, un solo pool físico para atenderlas. Es como tres cajeros compartiendo una caja fuerte, cada uno con un libro contable diferente.
Tres arquitecturas de prevención — elige en esta tabla
| Arquitectura | Cómo funciona | Ventaja | Costo | Ideal para |
|---|---|---|---|---|
| División de stock de seguridad por canal | Dividir el pool físico en porciones por canal según el ratio histórico de ventas | Simple, sin sistema nuevo, funciona con una hoja de cálculo | Baja utilización: los canales calientes se quedan sin stock mientras los tranquilos acumulan inventario | Vendedores con decenas de SKUs y sin capacidad de ingeniería |
| Pool virtual compartido + reserva | Un OMS mantiene una única cantidad disponible compartida; los pedidos de los canales reservan primero y descuentan al enviar | Alta utilización, la tasa de sobreventa cae casi a cero | Requiere un OMS; hay que diseñar la lógica de expiración y liberación de reservas | Vendedores medianos: cientos de SKUs, cientos de pedidos diarios |
| Inventario central OMS + asignación multi-almacén | Cantidad disponible central con reglas de asignación entre almacenes y canales | La más completa; admite multi-almacén, multi-canal, multi-moneda | El mayor costo de implementación y mantenimiento | Vendedores con varios almacenes o 3PL con más de 1,000 pedidos al día |
Mi consejo de elección: no saltes directo a la arquitectura tres. Mira dos números: tu cantidad de SKUs y tu volumen diario de pedidos. Con menos de unos 100 SKUs y unos 300 pedidos al día, la arquitectura uno más conteos cíclicos disciplinados es realmente suficiente — a veces un problema de sistema se resuelve más barato con un conteo diario extra. Pasando de unos 500 pedidos al día o unos 500 SKUs, la arquitectura dos tiene el mejor ROI. La arquitectura tres es para jugadores multi-almacén; un vendedor de un solo almacén que la adopte está usando un mazo para clavar un clavo, y el costo de mantenimiento te comerá.
El dato contraintuitivo: la mayoría de los vendedores asume que la sincronización en tiempo real es la respuesta óptima. Para la mayoría, sincronizar cada 15 minutos más un stock de seguridad adecuado supera a la sincronización en tiempo real con cero stock de seguridad. El tiempo real solo reduce la latencia de 15 minutos a segundos — no resuelve la condición de carrera cuando tres canales toman pedidos en el mismo segundo. Lo que de verdad te protege es el mecanismo de reserva y el stock de seguridad, no la velocidad de sincronización.
Cómo fijar la frecuencia de sincronización adecuada
Esta es la regla que uso:
Máximo vendible dentro de un intervalo de sincronización = disponible actual − (ventas pico por minuto × minutos del intervalo × 1.5)
Cómo leerla: toma la tasa de ventas por minuto más rápida que este SKU haya alcanzado, multiplícala por tu intervalo de sincronización, multiplícala por un factor de seguridad de 1.5 y retén esa cantidad antes de enviar los conteos vendibles a los canales. Ejemplo: un SKU con pico de 2 unidades por minuto en un intervalo de 15 minutos significa retener 2 × 15 × 1.5 = 45 unidades. Pasa los SKUs calientes a sincronización casi en tiempo real (1–2 minutos); deja los de cola larga en 15–30 minutos. Sincronizar todo en tiempo real quema cuotas de API sin motivo.
Además: no sincronices en una sola dirección. Muchos plugins envían el número de inventario al canal pero nunca recuperan la disponibilidad mostrada en el canal para conciliarla. Haz una conciliación de tres vías semanal — disponible del OMS frente al conteo del escaparate de cada canal — e investiga cualquier brecha superior al 5%. Este hábito es más barato que cualquier arquitectura y funciona mejor que la mayoría.
En Amazon la sobreventa sale más cara
Los tres canales no castigan igual la sobreventa. En DTC, envías un correo de disculpa y un cupón y normalmente te recuperas. En Walmart, daña tu calificación de tienda. En Amazon, una sobreventa cancelada alimenta directamente tus métricas de defectos de pedido — la tasa de cancelación y la tasa de envíos tardíos se acumulan en el ODR, y superar los umbrales provoca revisiones de cuenta o suspensión. Los umbrales siguen la política publicada actual de Amazon y cambian con el tiempo, así que no apuestes tu cuenta a los números del año pasado.
Así que, en la práctica: envía siempre a Amazon el conteo disponible más conservador. Uso un factor de seguridad de 2.0 para el canal Amazon y 1.5 para el resto. Y mantén las unidades vendibles de FBA y las unidades disponibles del propio almacén como dos libros contables separados — nunca las mezcles en un único número enviado hacia fuera. Ese es el error de novato más común que veo.
La lista de implementación
- Unifica tus datos maestros de inventario: alinea la tabla de mapeo de SKUs entre canales — un SKU físico se mapea a exactamente una clave de inventario; las variantes y los packs reciben sus propios SKUs virtuales.
- Escribe tu fórmula de "disponible" y haz que todos la usen: disponible = en mano − reservado − retenciones en tránsito − pedidos de canal no enviados.
- Fija niveles de stock de seguridad por canal de forma independiente, con Amazon el más conservador.
- Pon los SKUs calientes en su propia cadencia de sincronización (1–2 minutos); deja los de cola larga en 15–30 minutos.
- Expiración y liberación de reservas: libera automáticamente las reservas de pedidos no pagados tras 30 minutos (o según las reglas de cada canal) para que las "reservas fantasma" no bloqueen inventario.
- Conciliación semanal de tres vías: disponible del OMS frente al conteo del escaparate de cada canal; investiga brechas superiores al 5%.
- Congela la línea base de inventario 48 horas antes de las grandes promociones: exporta una instantánea y durante el evento solo ajusta el factor de seguridad, nunca la línea base — para que las ediciones de nadie colisionen.
- Escribe un SOP de sobreventa de una página: quién contacta al comprador, cuál es el estándar de compensación, cómo se abre el caso en Amazon. Imprímelo y cuélgalo en la pared.
Un pool de inventario compartido entre canales es fundamentalmente un problema de "una caja fuerte, tres cajeros", que se resuelve con un mecanismo de reserva y una única definición de disponible. Elige la arquitectura adecuada, fija la cadencia de sincronización correcta, mantén a Amazon en modo conservador — y la trampa de la sobreventa se convierte en algo que diseñas para que desaparezca. He visto esta trampa tres veces. Prefiero que tú no la veas ni una.
Por Lin Xiao, Consultora de implementación de WMS
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
