Rebajas automáticas en Shopify sin regalar margen: la IA escribe el código, la regla pone el precio
4 promociones en 5 semanas, 0 errores al aplicar y una reversión ensayada 9.440 de 9.440 en Shopify Plus. La regla, los controles y lo que aprendimos.
Consultor en IA, marketing digital y marketing médico · btodigital
Entre el 28 de agosto y el 4 de octubre de 2026 automatizamos cuatro promociones de precios en la tienda Shopify de una marca de moda colombiana con tienda online y tiendas físicas, y ninguna tuvo errores al aplicar. La más grande llegó a 9.440 tallas, y antes de dejarla corriendo ensayamos su reversión completa: 9.440 de 9.440.
Este texto es para gerentes de e-commerce y dueños de marca que venden en Shopify por la web y en tiendas propias. La idea central cabe en una línea: la inteligencia artificial escribió y vigiló el código, pero el precio lo pone una regla que el cliente aprueba por escrito. Ninguna IA decide precios en producción.
¿Qué pasó en las cuatro promociones?
| Fecha | Canal | Alcance | Resultado |
|---|---|---|---|
| 28 de agosto | Solo web | Rebajas al 50 % | 1.455 tallas bajaron; 1.579 ya estaban en 50 % o menos y no se tocaron |
| 4 de septiembre | Web y tiendas | Cierre por antigüedad: 372 productos al 50, 40 o 30 % | Aplicado en los dos canales |
| 30 de septiembre | Solo web | Rebajas al 50 % sobre 7.604 tallas | 1.881 bajaron; 5.723 no se tocaron por el modelo techo |
| 2 al 4 de octubre | Solo tiendas físicas | Rebajas al 50 % | Plan de hasta 9.440 tallas |
En las cuatro hubo 0 errores al aplicar. Y en todas, la promoción quedó programada pocas horas después de que el cliente la aprobó.
Mira la tercera fila. De 7.604 tallas, el sistema solo movió 1.881. Las otras 5.723 ya estaban al 50 % o más baratas. Una regla mal escrita las habría rebajado otra vez.
¿Dónde se regala el margen en una rebaja?
Casi siempre en dos lugares.
El primero: aplicar el porcentaje sobre un precio que ya está rebajado. Si una prenda vale 74.900 pesos y en tienda ya está al 30 %, en 52.430, un “50 %” calculado sobre ese precio la deja en 26.215. Eso es un 65 % sobre el precio original, no un 50 %. Nadie lo decidió: lo decidió una fórmula.
| Cálculo | Precio | Descuento real sobre el original |
|---|---|---|
| Precio original (tachado) | 74.900 | 0 % |
| Precio actual en tienda | 52.430 | 30 % |
| 50 % sobre el precio actual | 26.215 | 65 % |
| 50 % sobre el original (nuestra regla) | 37.450 | 50 % |
Los 74.900, 52.430 y 37.450 son de una prenda real de la promoción del 30 de septiembre, sin su nombre. El 26.215 es el cálculo de lo que habría pasado con la fórmula ingenua.
El segundo: que la rebaja de un canal se filtre al otro, o que dure más de lo acordado. Una promoción solo web que también baja las tiendas, o una de fin de semana que nadie apaga el lunes.
La regla que usamos ataca los dos:
- El objetivo es la mitad del precio regular tachado, nunca la mitad del precio actual.
- Modelo techo: solo baja lo que está por encima del objetivo. Lo que ya está más barato no se toca, y nada se sube.
- Se escribe solo en la lista de precios del canal de la promoción.
- Tiene hora de inicio y hora de fin, y la reversión queda programada desde el principio.
¿Cómo se separa la web de las tiendas en Shopify?
En esta tienda, que es Shopify Plus, la web y las tiendas físicas leen listas de precios distintas a través de Mercados y Catálogos. Cada talla tiene un precio fijo en la lista de la web y otro en la lista de las tiendas.
Antes de la primera promoción lo probamos en vivo: cambiamos el precio de una sola talla en la lista web y la web lo mostró al instante, mientras la lista de tiendas y el precio base quedaban intactos. Lo revertimos en el acto. En octubre hicimos la prueba inversa antes de la promoción de tiendas.
La consecuencia práctica: una promoción solo web se hace escribiendo únicamente en la lista de la web. No hay que tocar el precio base ni congelar nada.
¿Cómo está armada la automatización?
| Pieza | Qué hace |
|---|---|
| Plan congelado | Archivo con cada talla, su precio objetivo y su precio previo como respaldo |
| Cloud Run Job de aplicar y reparar | Aplica el plan y, en cada corrida, repara solo lo que quedó por encima del objetivo |
| Cloud Run Job de revertir | Devuelve cada talla a su precio previo desde el respaldo |
| Cloud Scheduler | Dispara la reparación periódica y la reversión a la hora acordada |
| Compuertas de inicio y fin | Antes del inicio o después del fin, el job no hace nada |
| Correos de alerta | Solo cuando hay novedad: arranque, reparación grande o error |
| Guardián por webhook | En la primera promoción, corregía al instante un producto editado que quedaba por encima del 50 % |
La frecuencia del reparador cambió con lo que fuimos aprendiendo: empezó cada tres horas y en la promoción de tiendas terminó cada 10 minutos.
¿Qué controles hay antes de tocar un precio?
- Aprobación por escrito del alcance, el porcentaje y las fechas.
- Vista previa en CSV para el cliente: qué talla baja y de cuánto a cuánto.
- Simulacro obligatorio: el job corre en modo de prueba y reporta qué haría, sin escribir nada.
- Plan congelado con respaldo del precio previo de cada talla.
- Compuertas de inicio y fin en el propio código, no solo en el programador de tareas.
- Verificación posterior: después de aplicar, el job vuelve a leer los precios y confirma que quedaron donde debían.
- El reparador se apaga antes de revertir. Si no, a las 9:00 el revertidor devuelve los precios y en la siguiente corrida el reparador los vuelve a rebajar. Por eso el reparador deja de actuar 15 minutos antes de la reversión.
- Reversión ensayada: en la promoción de tiendas, el simulacro de reversión devolvió 9.440 de 9.440 tallas.
Un detalle que cuesta aprender: Colombia está en UTC-5 y los servidores piensan en UTC. Las compuertas se escriben en UTC (hora de Colombia más cinco horas) y el programador se configura en hora de Bogotá. Lo verificamos con una conversión independiente cada vez.
¿Qué hizo la IA y qué no?
Claude Code diseñó la arquitectura, escribió el código, armó los planes leyendo los precios en vivo, corrió los simulacros y vigiló las promociones. Cuando algo se movió, fue quien lo detectó y propuso el arreglo.
Lo que no hizo: decidir el porcentaje, el alcance ni las fechas. Eso lo decide el área de mercadeo del cliente y queda por escrito. En producción, el precio de cada talla sale de una fórmula fija y revisable, la mitad del regular con techo, no de un modelo que opina. Mi posición: si algún día una IA propone precios, que proponga; que los aplique una regla que alguien firmó.
Lo que aprendimos
- Vigila el resultado, no la causa. Lo que cuenta es el precio que ve el comprador, no la causa que crees conocer. Para eso están el reparador periódico y el guardián por webhook.
- Una colección manual de descuentos no sirve como fuente de verdad. El plan de tiendas pasó de 7.604 a 9.440 tallas a medida que encontramos rebajas fuera de la colección y el cliente las aprobó. Le recomendamos volverla automática, con la regla “tiene precio tachado”.
- En caja, una prenda ya escaneada conserva el precio viejo. Si se pasó antes del cambio, hay que quitarla y volver a escanearla. Eso no se ve por API: por eso le pedimos al cliente una compra de prueba en caja.
- Más instancias no compran velocidad si el límite es la API. En la sincronización de inventario de la misma tienda subimos el servicio de 1 a 10 instancias para aguantar un pico, y nuestro monitor empezó a chocar con el límite de la API de Shopify, que acepta un número fijo de llamadas por segundo por tienda. Volvimos a una instancia e hicimos el monitor tolerante a esos rechazos pasajeros.
¿Esto sirve fuera de la moda?
Dos casos más pequeños de otros proyectos dicen lo mismo: valida antes de cargar.
- En el outlet de una tienda de decoración, el cliente envió 180 SKU para rebajar. Aplicamos 144, con 0 errores. Los otros 36 no existían en la tienda. Sin validar contra el catálogo, nadie se habría enterado de que uno de cada cinco SKU de la lista no apuntaba a nada.
- En una importación de productos, 4 precios venían multiplicados por 1.000 por un error de digitación. Un precio así no se corrige después de publicado sin que alguien lo vea: se detecta revisando rangos antes de cargar.
Es la misma lógica que seguimos al automatizar el mantenimiento de 24 sitios WordPress: la automatización no reemplaza la verificación, la vuelve obligatoria.
¿Cómo aplicarlo en tu tienda?
- Confirma cómo leen el precio tus canales. Si la web y las tiendas comparten precio, una promoción solo web no es posible sin separarlos primero.
- Define el precio regular de referencia, el tachado, y calcula la rebaja sobre él, nunca sobre el precio actual.
- Usa techo: baja lo que está por encima del objetivo y no toques lo que ya está más barato.
- Congela el plan con el precio previo de cada talla antes de aplicar.
- Exige un simulacro y una vista previa que el área comercial pueda leer y aprobar por escrito.
- Pon hora de inicio y de fin en el código, y programa la reversión desde el primer día.
- Apaga el reparador antes de revertir.
- Ensaya la reversión completa antes de encender.
- Vigila el precio que ve el comprador, no solo lo que escribiste.
- Haz una compra de prueba en caja: es lo único que no se ve desde la API.
Una rebaja bien aplicada también es una cuestión de confianza: el comprador que ve un precio en la web y otro en la caja no vuelve igual. Lo desarrollé en por qué no te compran aunque te visiten.
Preguntas frecuentes
¿Se pueden hacer rebajas solo en la tienda online de Shopify sin tocar las tiendas físicas? Sí, si la web y las tiendas leen listas de precios distintas, como en esta tienda, que es Shopify Plus y usa Mercados y Catálogos. Escribes solo en la lista de la web. Antes de cada tipo de promoción lo probamos en vivo con una sola talla.
¿Qué es el modelo techo? Una regla que solo baja los precios que están por encima del objetivo y nunca sube los que ya están más baratos. En la promoción del 30 de septiembre, de 7.604 tallas solo bajaron 1.881; las otras 5.723 ya estaban al 50 % o menos.
¿La IA decide los precios? No. Claude Code diseñó, programó y vigiló el sistema, pero el porcentaje, el alcance y las fechas los decide el cliente por escrito, y el precio de cada talla sale de una fórmula fija: la mitad del precio regular tachado.
¿Cómo se revierte una promoción automática? Con el respaldo del precio previo de cada talla, guardado en el plan antes de aplicar. Un job de reversión lo restaura a la hora acordada, después de apagar el reparador. En la promoción de tiendas, el ensayo devolvió 9.440 de 9.440 tallas.
¿Qué pasa con las prendas que ya estaban rebajadas? Si ya están al porcentaje de la promoción o por debajo, no se tocan. Así se evita apilar descuentos y regalar margen sin que nadie lo haya decidido.
¿Qué no se puede verificar desde el sistema? La caja física. Por API se comprueba que la lista de precios de tiendas quedó bien, pero una prenda escaneada antes del cambio conserva el precio viejo. Por eso pedimos una compra de prueba en tienda.
Si quieres montar promociones así en tu tienda, es parte del trabajo que hago como consultor de marketing digital.
¿Quieres aplicar esto en tu negocio?Escríbeme y lo revisamos juntos.
Escríbeme por WhatsApp