Mi veredicto de entrada: la noche antes de una gran venta, no hagas pruebas de carga de tu tráfico — mide cuánto tarda un cambio de precio en llegar a cada canal. Los campos de precio deben viajar por push en tiempo real. Si el tuyo todavía depende de sondeo con un intervalo de más de cinco minutos, estás sentado sobre una bomba de tiempo. Vi explotar una en el Black Friday 2023.
El almacén era un 3PL de 120,000 pies cuadrados en Fontana. A las 7 AM de ese viernes, el cliente bajó el precio de promoción de un altavoz Bluetooth de $29.99 a $19.99 en el backend del canal, esperando que la oferta saliera en vivo a las 8. El canal lo aplicó en menos de un minuto. Pero el OMS sondeaba los precios del canal cada 15 minutos, y la avalancha de pedidos del Black Friday había saturado la cola de sincronización por más de una hora además. Cuando el nuevo precio por fin llegó al OMS y bajó a la facturación del WMS, eran las 10 AM. En esas dos horas, más de 1,400 pedidos pagaron al precio de página de $19.99 mientras el OMS tenía bloqueado $29.99. Servicio al cliente quedó sepultado bajo tickets de "¿por qué me cobraron $10 de más?", y una vez que la empresa decidió respetar el precio de la página, solo los créditos de compensación costaron bastante más de diez mil dólares. La lección se me quedó grabada: el daño por retraso de precios es irreversible. Una vez que un pedido bloquea el precio equivocado, las cajas igual tienen que salir, y el dinero simplemente se fue.
Desde entonces tengo un hábito: cuando alguien me habla de selección de OMS, el diagrama del flujo de sincronización de precios es el primero que pido ver.
Cuántas manos toca un precio antes de convertirse en un pedido
Editar el precio en el backend del canal es solo el paso uno. El cambio tiene que viajar por la API o el webhook del canal hasta el OMS, escribirse en el maestro de precios del OMS, pasar una verificación de ventana efectiva que decide a qué precio califica este pedido, y finalmente quedar congelado en el pedido y bajar al WMS y a finanzas. La cadena parece simple, pero cada mano en ella puede quedarse sentada sobre el precio sin hacer nada — el canal lo envió, el OMS nunca lo recibió; el OMS lo recibió, nunca lo escribió; lo escribió, pero la ventana de tiempo no coincidió. Bloquear el precio en un pedido es una puerta de una sola vía. Una vez bloqueado, ninguna sincronización tardía puede alcanzarlo. Así que la sincronización de precios no es una cuestión de precisión, es una cuestión de velocidad. Dos horas tarde y dos horas mal cuestan exactamente lo mismo.
La estación de empaque es el último lugar donde un pedido mal precificado podría teóricamente ser detectado, y no puede detectarlo. El empacador aprieta el gatillo del escáner Zebra, el WMS imprime la etiqueta y descuenta el inventario contra el precio congelado del pedido — el arma lee códigos de barras, no precios. Una vez que la caja toca el transportador, el pedido con precio equivocado va en camino. El parche que luego puse en esa instalación de Fontana fue una verificación de precio en la confirmación de empaque: si el precio congelado del pedido no coincide con el precio actual del canal, la pantalla de la estación parpadea en rojo y bloquea el pedido. Eso detiene la hemorragia. La enfermedad sigue en la cadena de sincronización.
Los tres lugares donde se esconde el retraso
El primero es el intervalo de sondeo. Muchos OMS sondean los precios del canal cada 15 o incluso 30 minutos. Eso está bien un martes tranquilo. En Black Friday las API del canal limitan, las respuestas se ralentizan, y un ciclo de sondeo se estira hasta tres — 15 minutos se convierten en una hora. Mi recomendación es tajante: si tu campo de precio sondea a cualquier cosa por encima de cinco minutos, cámbialo a push en tiempo real para la temporada alta. No negociable.
El segundo es el push perdido. Los webhooks suenan en tiempo real, pero entre que el canal dispara y el OMS recibe, un timeout, un error 500, un hipo de red significa que el mensaje simplemente desapareció. Muchos sistemas no reintentan, o reintentan unas pocas veces, fallan, y estacionan el mensaje en una cola de muertos que nadie mira jamás. Los cambios de precio hechos en la madrugada antes de una venta caen en esta trampa con más frecuencia — nadie está mirando a las 3 AM, y para la mañana el precio nunca llegó mientras los pedidos corrieron toda la noche.
El tercero es el desajuste de la ventana efectiva. La promo del canal dice "válido de 8:00 AM a 11:59 PM," pero el OMS guarda un precio desnudo sin horas de inicio ni fin. O el OMS evalúa la ventana en hora del servidor mientras el canal corre en hora del Pacífico — un silencioso desfase de tres horas. Fontana explotó con la combinación de los dos primeros, pero he visto igual de sitios caer por la ventana de tiempo, y esos son más desagradables de depurar: el log de sincronización dice "success", pero cada pedido bloqueó el precio equivocado. Exasperante.
Qué probar la noche anterior y cómo detener la hemorragia
La lista de pruebas previa a la venta no tiene que ser larga. Tres puntos la cubren. Primero, cambia un precio en staging y mide cuánto tarda en aparecer en un pedido del OMS. ¿Más de diez minutos? No te vayas a dormir — sigue excavando. Segundo, mata el receptor del webhook por diez minutos y verifica si alguien recibe una alerta, y si el sistema se pone al día al recuperarse. Un push sin alertas es lo mismo que ningún push. Tercero, coloca un pedido de prueba justo en el borde de una ventana de tiempo de promoción, mira qué precio se bloquea, y concilia tu zona horaria del servidor con la del canal de paso.
Cuando de verdad explota, la secuencia para detener la hemorragia tiene un orden, y el orden importa. Primero el interruptor de emergencia: deslista el SKU afectado por API — todos los canales principales lo soportan, y es mucho más rápido que un humano haciendo clic. Cierra la llave. Luego estrangula: si el volumen de pedidos de un SKU en diez minutos supera cinco veces su norma diaria, dispara una alerta y retenlo para revisión humana para que los pedidos con mal precio dejen de acumularse. Finalmente, dale a servicio al cliente una frase honesta para usar. Aquí va la mía: "We honor the price shown at checkout." Tragarse un precio bajo sobrevendido te cuesta una factura; discutirlo te cuesta el cliente. Ya hice esas cuentas — lo primero es más barato. Y para los pedidos con sobrecargo, reembolsa rápido y discúlpate de forma específica. No hagas que el cliente lo descubra solo.
Ve y hazle a tu IT una pregunta: ¿nuestra sincronización de precios es push o poll? Si la respuesta es "I think it's push" — ve a verificarlo esta noche. Black Friday no te va a esperar.
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
