EcommLetter #243: mandé un agente de IA a comprar en la tienda de un cliente. Esto es lo que encontró.
Dieciocho segundos, una provincia fantasma y tres informes de mejora del checkout que ningún panel de analítica te iba a dar.
Cuando pruebas a comprar en tu propia tienda online, haces trampas, sin darte cuenta.
Entras desde tu ordenador, con tu conexión, sabiendo dónde está cada botón y qué vas a comprar. Tardas treinta segundos y concluyes que todo va fino.
Pero ese no es tu cliente. Tu cliente llega en frío, desde el móvil, con prisa y sin tu mapa mental de la tienda metido en la cabeza.
Así que esta semana decidí mirar la tienda de un cliente con esos otros ojos. Mandé a un agente de IA a comprar por mí y a apuntar todo lo que se torciera. Lo que pasó en los primeros dieciocho segundos ya justificó el experimento.
Te pongo en contexto.
Tengo un cliente con una tienda online al que ayudo en la parte estratégica y de mejora de resultados. Vende razonablemente bien, pero queríamos comprobar si su proceso de compra funcionaba de verdad desde el lado del cliente. No desde el panel de WooCommerce, no desde Google Analytics, sino con alguien comprando de verdad.
Hacerlo a mano, el mystery shopping de toda la vida, tiene un problema: lleva tiempo, es subjetivo y siempre se te olvida anotar algo. Así que propuse otra cosa. En lugar de ir yo, mandamos a un agente a hacer la compra y a documentar cada punto de mejora.
🤖 Un agente que navega la tienda, añade un producto al carrito, rellena el formulario del checkout y se detiene justo antes de pagar.
De momento, porque al ritmo que van las cosas pronto le dejaremos comprar con su propia tarjeta agéntica.
Y mientras hace todo eso, mide cuánto tarda cada paso, anota los errores que encuentra y captura la pantalla en cada momento clave.
Al final te entrega tres documentos: un informe en Markdown para referencia técnica, un Word para mandárselo al cliente y una versión HTML visual para explicárselo en una videollamada.
Esto es lo que pasó cuando lo pusimos en marcha. Te lo cuento todo en detalle.
Y al final vas a querer uno igual. Ya verás 😉
El punto de partida: ¿y si el checkout es un desastre y no lo sabemos?
El abandono de carrito es el problema más documentado del ecommerce. Hay miles de estudios, benchmarks y teorías sobre por qué la gente se va. Pero hay algo que casi ninguna tienda hace de forma sistemática: sentarse a comprar como si fuera un cliente desconocido, en frío, sin saber cómo funciona la cosa por dentro.
La mayoría de los dueños de tienda hacen pruebas de vez en cuando, a mano, desde su propio ordenador, con su propia conexión y con la ventaja de saber exactamente qué están buscando. Y ya lo hemos dicho: eso no es comprar como un cliente.
La idea era automatizar ese proceso con Playwright, una herramienta de automatización de navegador. Le dices qué tienda analizar, le pasas unos datos de prueba para el formulario y él hace el resto. Todo en modo “headed”, que quiere decir que ves el navegador abierto mientras trabaja, igual que si lo hiciera una persona.
Lo que hicimos, paso a paso
Preparar el entorno
Lo primero fue comprobar que teníamos todo lo necesario: Node.js instalado, Playwright disponible, una carpeta de trabajo. Sin frameworks, sin infraestructura complicada. Un archivo de JavaScript, un directorio para los screenshots y a correr.
La primera ejecución falló. El script intentaba ir al carrito con un clic, pero la tienda usaba Ajax para añadir productos y el navegador no detectaba la navegación. El problema clásico de la automatización: la herramienta espera un comportamiento estándar y la tienda hace algo ligeramente distinto.
La solución fue directa. En lugar de esperar una navegación después del clic, fuimos directos a la URL del carrito. Una línea de código diferente, el mismo resultado.
Segundo obstáculo: el formulario de checkout
El formulario de esta tienda usa WooCommerce con Gutenberg Blocks, que es la versión moderna del checkout de WooCommerce. El lío es que sus campos tienen nombres y selectores distintos a los del checkout clásico.
El script localizó el email sin problema, pero no encontró los campos de nombre, dirección ni teléfono. En lugar de dar por hecho que el formulario estaba roto, lo registró como un hallazgo y siguió ejecutando el resto del flujo.
Y esto importa más de lo que parece: un buen agente no se rompe en el primer obstáculo. Sigue, documenta lo que no pudo hacer y te entrega igualmente un informe útil.
Lo que encontró
Esto es lo que el agente midió y observó en la tienda de mi cliente:
Los tiempos de carga de cada paso:
Dieciocho segundos para que cargue el formulario de checkout. Dieciocho. En un mundo donde más de la mitad de las compras se hacen desde el móvil, y con una conexión que no siempre acompaña, ahí no pierdes algún cliente de vez en cuando. Los pierdes a diario.
La tienda tiene cero errores de JavaScript, lo que significa que técnicamente está bien construida. Aquí no hay nada roto. Lo que hay es un cuello de botella. Probablemente algún plugin de WooCommerce cargando recursos que no le hacen falta, o un conflicto con la caché.
El hallazgo más inesperado: la provincia fantasma
Cuando el checkout cargó, el campo “Provincia” ya venía rellenado con “Vizcaya”. Nadie había escrito nada.
Un cliente de Madrid, Valencia o Sevilla que vea ese campo pre-rellenado con una provincia que no es la suya va a pensar una de dos cosas: que hay un error, o que la tienda no envía a su zona.
Ninguna de las dos le va a dar ganas de seguir comprando.
Es un ajuste de cinco minutos en el panel de WooCommerce. Pero puede estar costando ventas todas las semanas sin que nadie se entere.
Por cierto, no costaba nada pedirle al informe que incluyera también cómo resolver cada problema que fuera encontrando:
Lo que funciona bien
No todo eran malas noticias. La tienda tiene tres métodos de pago: Redsys (tarjeta), Bizum y Google Pay. Para el mercado español, una cobertura excelente. El carrito está bien estructurado, el catálogo es limpio y la notificación al añadir un producto funciona como debe:
El informe
Le pedí al agente que generara tres versiones del mismo análisis, cada una para un uso distinto.
▶︎ Markdown: para guardarlo en el repositorio del proyecto y tener referencia histórica. La próxima vez que se ejecute, se compara con el anterior y ves si las cosas han mejorado. Para mí, Markdown es el mejor sistema para almacenar contexto cuando trabajas con IAs.
Por eso, siempre que pido cualquier output, una de las versiones es en Markdown, para que se quede disponible para la IA.
▶︎ Word: para enviárselo al cliente. Lleva portada, tabla de contenidos, tablas formateadas y pie de página con numeración. Se ve como un documento profesional y no como un volcado de datos. Los humanos somos menos eficientes que la IA y necesitamos toda esa sobrecarga que mete el formato Word.
Es lo que hace fácil mandarlo por email, guardarlo, imprimirlo y todas esas cosas que hacemos los de carne y hueso.
▶︎ HTML: para explicárselo en una videollamada. Lleva visualización semafórica en la tabla del flujo (verde para lo que va bien, ámbar para fricciones, rojo para problemas críticos), barras de progreso en la puntuación general y una franja de KPIs arriba que resume los números importantes de un vistazo. Esto es algo que he empezado a hacer hace poco.
Ya no monto PowerPoints. Cuando quiero enseñar algo en pantalla en una call, le pido a la IA que me genere una visualización en HTML. Tira de los últimos frameworks o de lo que le dé la gana, queda precioso, carga rapidísimo y no necesitas instalar nada.
💡 Y hay otra cosa que me gusta de este montaje: yo ya tengo a mi IA instruida con todo lo que me parece importante a nivel de copy, de experiencia de usuario y de cosas que he trabajado durante años para mejora de conversión ecommerce. Eso se lo paso como archivo de contexto, y lo añade a los informes con solo decirle: “Recuerda meter las recomendaciones de experiencia de uso y de copy orientado a conversión”.
Siguiente nivel: convertirlo en algo reutilizable
Después de hacer este análisis para el cliente, la pregunta caía por su propio peso: ¿cómo hago lo mismo para cualquier otra tienda sin empezar de cero?
La respuesta es convertirlo en un skill. Un skill en Claude Code es, básicamente, un conjunto de instrucciones documentadas que el agente puede seguir en cualquier sesión futura. Le dices el nombre del skill, le das los inputs que necesita (la URL de la tienda, los datos de prueba del formulario) y ejecuta todo el flujo solo.
A partir de ahora, para auditar el checkout de cualquier tienda WooCommerce, me basta con esto:
/validador-checkout https://nuevatienda.com/tienda/ nuevatienda
El agente me pide los datos que le falten, ejecuta el análisis y entrega los tres informes con el branding ya configurado. Un trabajo que hoy te llevaría horas de revisión manual se convierte en algo que delegas del todo.
Me queda pendiente una cosa: ajustar el skill para que se porte bien con otras tecnologías. Estoy dándole vueltas a si montar un skill distinto por cada una, súper optimizado, o un skill general que detecte qué tecnología es (WooCommerce, Shopify, PrestaShop, Magento o lo que sea) y tome decisiones de análisis en función de eso.
Toma nota
Hay una diferencia importante entre saber que el checkout de tu tienda “funciona” y saber que tarda 18 segundos en cargar para alguien que no eres tú. He tenido suerte en esta primera prueba y ha salido algo crítico de resolver. En mis pruebas manuales ya intuía que el rendimiento podía ser el motivo, porque en sistemas como WooCommerce, salvo que esté todo muy fino, es de lo primero que hay que vigilar.
La mayoría de los análisis de ecommerce se hacen sobre datos agregados: tasas de conversión, embudos en GA4, mapas de calor. Todo eso sirve, pero tiene una limitación. Te dice qué pasa, no qué experimenta el cliente en el momento exacto en que pasa.
Este tipo de análisis hace otra cosa. Es observación directa, paso a paso, con tiempos reales y capturas de cada momento. Lo más parecido a estar sentado al lado de un cliente mientras compra, sin que él sepa que lo estás mirando.
Y la parte buena es que, una vez tienes el proceso documentado como skill, lo lanzas cada vez que sacas una campaña nueva, cada vez que tocas el tema de la tienda o cada vez que sospechas que algo no va como debería.
Cada vez que el cliente cambie lo más mínimo en su tienda, yo vuelvo a lanzarlo. Va a formar parte de las pruebas normales en la vida de este proyecto.
Todo con un clic, mientras me tomo un café ☕️, y con un resultado bueno, consistente y que me deja cazar problemas al momento. ¿Le ves el potencial?
Móntalo tú
Montar esto no es ultra complicado, pero tampoco es inmediato si nunca has hecho algo similar.
Si ya te manejas pidiéndole a la IA que te escriba código, que te monte skills y que trabaje con tu propio contexto, esto te va a parecer un sábado entretenido. Si todavía no tienes esa base, lo vas a ver más complicado.
Para que tengáis esa base, he creado y publicado mi “Recetario de IA para ecommerce”. Es el punto de partida para empezar a hacer cosas como la de hoy, con todo explicado en texto y en vídeo, y acceso permanente para volver cuando te apetezca.
Hoy es el último día que está a precio de lanzamiento. Si llevas tiempo dándole vueltas, es buen momento para entrar, echarle un ojo y guardártelo para cuando puedas sentarte un rato:
Móntalo con ayuda
Y si lo tuyo es no hacerlo en solitario, en EcommPRO vamos a montar muy pronto una explicación paso a paso para que cada uno se construya su propia skill de validación de checkout y le meta su experiencia encima.
Ahí dentro le damos caña a la IA aplicada al ecommerce y nos echamos un cable entre todos para tener estas cosas funcionando en nuestras tiendas:
Eso es todo por hoy.
Si te ha parecido interesante, si te ha gustado, si lo vas a probar, me encantaría que me lo dijeras en comentarios.
Un abrazo y feliz verano
Pablo