Una tienda online recibía llamadas todos los días de gente que ya estaba en su web: si había stock, si se lo mandaban a su tienda, si era compatible. Le montamos un agente sobre un modelo de su negocio, y esas llamadas han bajado mucho. Aquí está el caso con sus cifras de un mes, y la versión más barata del mismo método cronometrada sobre nuestra propia web.
Un cargador que encaja con una réplica y no con otra
Una tienda de airsoft vende réplicas y vende lo que se les pone encima: cargadores, baterías, miras, recambios. Casi todas las piezas se parecen entre sí, y casi ninguna vale para todos los modelos.
Un buscador no puede resolver eso. Cruza palabras: le pides un cargador y te devuelve todo lo que lleve la palabra cargador, incluido lo que no encaja con tu réplica. La compatibilidad no es una palabra que salga en una descripción. Es una relación entre dos productos, y una relación la sostiene un modelo, no un índice de palabras.
En un catálogo donde piezas casi idénticas valen para modelos distintos, ahí está la diferencia entre una venta y una devolución.
Lo que montamos para esa tienda online es un agente de venta y de atención al cliente sobre un solo modelo.
Modelamos el catálogo completo, con sus fichas y sus compatibilidades, más la política de devoluciones y los pedidos. Todo como una sola estructura, antes de que existiera ninguna conversación. Eso no salió de pegar una dirección: hubo que conectar sus sistemas y modelar lo que había dentro.
Lo que sale de ahí no es un chat que contesta. Como las devoluciones y los pedidos entraron en el mismo modelo, el agente que recomienda la pieza compatible es el mismo que tramita la devolución y el mismo que dice por dónde va un pedido.
Vender y atender dejan de ser dos herramientas distintas: recomendar es la venta, y tramitar una devolución o decir dónde va un pedido es atención al cliente.
Eso se ve mejor por lo que había antes. La tienda recibía llamadas todos los días de gente que ya estaba en la web, y llamaban por tres cosas: si el producto estaba disponible, si se lo podían mandar a su tienda, y si aquello era compatible con lo que ya tenían.
Las tres respuestas ya estaban en el modelo, porque las tres son preguntas sobre el catálogo y sobre los pedidos. Desde que el agente está puesto, esas llamadas han bajado mucho: la respuesta está donde estaba la duda. No son tres agentes ni tres integraciones.
En un mes ese agente sostuvo 4.153 conversaciones, y 386 acabaron con el visitante dejando sus datos: un 9,3 %. No tenemos la cifra de antes, así que no afirmamos que subiera ni cuánto.
Las seis capas bajo cualquier agente que construimos
La parte cara nunca es el chat. Es dejar escrito cómo funciona el negocio por dentro: qué entidades maneja, qué operaciones ejecuta, a qué reglas obedece. A ese modelo lo llamamos la ontología.
Tiene seis capas y se leen de abajo arriba. Conectar es de dónde salen los datos. Modelar, las entidades y las reglas. Replicar, el gemelo: esos datos ya cargados, y el agente puede preguntarles. Ejecutar, los agentes que trabajan encima. Gobernar, dónde se paran a pedir permiso. Conversar, por qué canal se habla con el cliente.
De las seis, la que decide todo lo demás es la segunda, modelar. Un chat que se instala pegando un código empieza y acaba en la capa 6: contesta con las palabras que encuentra. Aquí la conversación es lo último que se construye, y por eso el agente sabe qué encaja con qué.
Gobernar es la capa por la que preguntan después. Un agente que recomienda una pieza está leyendo; uno que emite un abono está actuando, y actuar es donde se para a pedir permiso.
Modelar no depende de por dónde entraron los datos.
De una web pública sale la parte de cara al cliente; de un ERP sale lo que solo vive dentro: el plan de cuentas, cómo se mueve el stock, las excepciones de precio que cada cliente ha ido acumulando. Esa capa vale para las dos.
Modelar un ERP no sale de pegar una dirección: es un trabajo aparte, que empieza por una auditoría. Lo que no hay que rehacer desde cero es el modelo: encima de él va después el agente que vigila un almacén o el que prepara un abono.
Dos minutos, siete campos y tres paradas
La versión más barata de ese método parte de una web pública, y por eso se puede cronometrar entera. La hicimos sobre la nuestra, cuarenta direcciones en el sitemap, y de pegar la dirección a tener el agente publicado pasaron 127 segundos.
Lo que se le pide a la empresa cabe en una línea. La pantalla del resumen ofrece siete campos y solo uno bloquea el avance, y ni siquiera es un campo concreto: hace falta una URL o una descripción. El resto lo rellena solo, hasta el color de marca, que lo saca de la web.
Quién hace qué
La persona
- Pega una URL
- Aprueba tres pantallas
- Edita, si quiere, cualquiera de los siete campos
El sistema
- Escribe el resumen de a qué se dedica el negocio
- Lee el sitemap
- Escribe el filtro de exclusión y elige las páginas útiles
- Enumera las integraciones disponibles
- Importa e indexa las páginas
- Diseña el árbol de conversación
- Publica e instala el widget
Lo que el modelo propone no llega crudo a la pantalla: después hay comprobaciones automáticas que podan los caminos que no llevan a ninguna parte.
Tres de las siete fases son punto de parada: la construcción se detiene y espera a que alguien confirme el resumen del negocio, los idiomas del menú y el filtro de páginas. Las dos fases largas son las que leen el sitio y dibujan la conversación, y entre las dos suman casi todo el reloj: las otras cinco juntas no llegan a cinco segundos.
Las cuatro últimas fases, según el panel. La que lee la web da lo mismo en las dos ejecuciones: 22 páginas y 298 fragmentos. La que diseña la conversación no se repite: 82 s en esta ejecución y 68,7 s en la primera.
Lo que la revisión encuentra antes de que lo vea nadie
Ese borrador lo revisamos nosotros antes de que el cliente vea nada. En esta ejecución encontró esto.
De las 40 URLs de nuestro sitio, 18 eran las páginas en español y se cayeron todas. En ningún punto saltó un aviso.
Tirar del hilo destapó tres fallos que se alinean: las páginas en español no tenían cómo declarar lo que eran, un umbral que no llegó a saltar, y el idioma principal tomado del resumen en vez de del sitio.
Lo que eso nos enseñó vale más que el fallo. La fase que descarta páginas es uno de los tres puntos de parada: la pantalla mostraba «22 útiles, 18 descartadas» y alguien le dio a continuar.
El silencio, en pantalla. La fase 2 sí ve es como idioma secundario; la fase 3 conserva 22 páginas y descarta 18, y todas las conservadas son rutas inglesas. Ningún aviso.
Una parada no sirve de nada si enseña un recuento en vez de lo que ese recuento significa. Es la diferencia entre ver «18 descartadas» y ver «se ha caído el español entero».
Por eso la revisión no la dejamos en manos del cliente: sabemos dónde miente un recuento y dónde hay que ir a mirar el sitio. Lo que recibe la empresa es un agente ya revisado, con las páginas elegidas y el árbol dibujado, y lo único que tiene que decidir es si ese árbol es el que quiere para vender.
Dónde acaba lo que este texto afirma
Las cifras de la tienda son de un mes. La bajada de llamadas nos la cuenta la tienda y no la hemos medido nosotros, así que va sin número: decimos que bajó mucho porque eso es lo que sabemos, y no ponemos un porcentaje que no tenemos. Cuánto vendió y cuántas devoluciones evitó son datos suyos.
Hay webs sobre las que no se puede construir solo. Sin sitemap la ejecución falla, y si el sitio se dibuja entero con JavaScript la lectura vuelve con cero documentos.
La construcción de dos minutos enumera integraciones, no las conecta. Conectarlas es trabajo de una persona y no está contado en los 127 segundos. A la tienda de este post hubo que conectarle los sistemas antes, que es la versión larga del trabajo.
Los 127 segundos son de nuestro sitio, de cuarenta direcciones, medidos en desarrollo. Un sitio de 4.000 no tarda dos minutos, y cuánto tarda no lo sabemos. Las capturas son de una segunda ejecución del mismo día: enseñan qué dicen las pantallas, no confirman los tiempos.
Nada de eso toca la frase sobre la que se apoya el post. La compatibilidad es una relación, y una relación hay que dejarla escrita en algún sitio antes de que un agente pueda usarla. Escrita una vez, el mismo modelo contesta qué encaja, por dónde va el pedido y cómo se tramita una devolución, y por eso una tienda que recibía esas tres preguntas por teléfono las recibe ahora en su propia web.
Preguntas frecuentes
- ¿Cómo sabe el agente qué encaja con qué?
- Porque la compatibilidad se modela como una relación entre productos, no como palabras en una descripción. Por eso puede decir que un accesorio vale para un modelo y no para otro.
- ¿Sirve para bajar las llamadas de mi tienda?
- Es lo que pasó en la del post: la gente llamaba para preguntar por stock, envío y compatibilidad, y esas tres respuestas viven ahora en el agente. La bajada nos la cuenta la tienda; no la hemos medido nosotros.
- ¿Funciona con cualquier web?
- Necesita un sitemap. Sin él la ejecución termina en fallo, y hoy no hay rastreador de reserva.
- Mi web está en dos idiomas. ¿Qué pasa?
- Los idiomas del menú no se adivinan: se eligen a mano en una de las tres paradas, y qué páginas entran se revisa en otra. Esa revisión es nuestra, y este post es justo la razón de que no nos la saltemos.
- ¿Qué tiene que hacer mi empresa?
- Dar la dirección de la web. La construcción la lanzamos nosotros y las tres paradas las pasamos nosotros, así que lo que te llega es un agente ya revisado. Lo único que tienes que decidir es si ese árbol de conversación es el que quieres para vender.
- ¿Cuánto cuesta montarlo?
- Depende de la fuente, no del método. Sobre una web pública el trabajo es el de este post. Sobre un catálogo de productos con sus devoluciones y sus pedidos hay que modelar antes. Sobre un ERP, además, hay una auditoría por delante. Se presupuesta caso a caso.
- ¿Conecta mis herramientas?
- La construcción de dos minutos no: lista las integraciones disponibles y no crea ninguna. Conectar sistemas es trabajo que hacemos nosotros, y es lo que necesitó la tienda de este post antes que nada.
- ¿Qué pasa si una fase falla?
- La sesión se detiene y conserva el trabajo parcial. Al reintentar, se reanuda desde la fase que falló, no desde el principio.
Fuentes
- 1.Panel de la tienda, un mes de actividad: 4.153 conversaciones, 386 contactos, 9,3 % de tasa. Datos del cliente, publicados con su permiso y sin identificarlo. ↩
- 2.Ejecución propia sobre hellomatik.com, 31 de agosto de 2026, en el entorno de desarrollo: los tiempos por fase, las 40 URLs y las 22 páginas conservadas. Datos internos. Las capturas del post son de una segunda ejecución del mismo día. ↩
- 3.Formato y protocolo de sitemaps XML, sitemaps.org ↩