Cómo diseñamos un sistema de scoring de leads: arquitectura, decisiones y límites
Un escenario tipo, no un cliente nuestro: webhook, scraping de la web del prospecto, análisis con LLM y cold email con aprobación humana. La arquitectura, las decisiones de diseño y lo que hay que resolver por el camino.
14 de marzo de 20269 min de lectura
Tomemos un escenario tipo, que no es un cliente nuestro: una empresa de distribución con 12 comerciales que recibe entre 40 y 60 solicitudes de información al mes a través de su web. Cada solicitud llega por email al responsable comercial, que abre el formulario, busca la empresa en Google, revisa la web, mira el tamaño aparente, evalúa si el perfil encaja con su catálogo y decide si llamar o ignorar. Ese proceso lleva entre 30 y 45 minutos por lead. En los meses de mayor volumen, eso son casi 45 horas de trabajo comercial dedicadas únicamente a clasificar solicitudes antes de hacer nada.
El problema no es que el proceso sea complicado. Es que es perfectamente estructurado y perfectamente repetible —lo que significa que es perfectamente automatizable. Aquí está la arquitectura con la que abordamos este tipo de caso, las decisiones de diseño y lo que hay que resolver por el camino. Un aviso desde el principio: las cifras de este artículo describen el diseño y lo que se mide, no los resultados de una implantación concreta.
El proceso original: cómo funciona el scoring manual
El comercial hace, en esencia, cinco preguntas para cada lead: ¿La empresa existe y tiene web? ¿A qué se dedica exactamente? ¿Cuál es su tamaño aproximado (empleados, facturación visible)? ¿Encaja con nuestros productos? ¿Tiene señales de capacidad de compra (catálogo de productos en su web, presencia consolidada, antigüedad)?
Esas cinco preguntas, respondidas con criterio comercial, generan una decisión: prioridad alta (llamar hoy), prioridad media (entrar en secuencia de email), descartar. Si esa lógica es consistente entre los distintos comerciales —normalmente porque alguien la ha documentado en una guía interna—, esa consistencia es justo lo que hace posible la automatización. Sin ella, todavía no hay nada que automatizar.
La arquitectura del sistema automatizado
El flujo que diseñamos para este tipo de caso sigue el patrón de cuatro capas que aplicamos en todos nuestros sistemas: ingesta asíncrona, procesamiento cognitivo, acción y fallback.
La primera capa es el webhook. Cuando alguien rellena el formulario de contacto de la web, la solicitud llega a un endpoint de n8n que responde con 200 OK en menos de 50 milisegundos y encola el payload en Redis. No procesa nada en ese momento. Esto garantiza que el usuario nunca espera y que la web no depende del procesamiento posterior para responder.
J
Escrito por
José Manuel
Co-Founder · AI Systems Architect, RAXAR
Co-fundador de RAXAR. Diseña la arquitectura de los sistemas de IA y orquesta los agentes autónomos que operan la plataforma. Escribe sobre automatización, agentes de IA y compliance para empresas.
La segunda capa es la cognitiva. Un worker de n8n —un nodo Cron que se ejecuta cada 30 segundos— extrae la solicitud de Redis y lanza el procesamiento. Primero, usa Jina Reader para hacer scraping de la web de la empresa que ha rellenado el formulario: extrae el texto visible de la homepage y de la página "sobre nosotros" si existe. El resultado es texto limpio, sin HTML, listo para ser analizado.
Con ese texto, se construye un prompt estructurado para Groq (Llama-3.3-70b-versatile) que pide al modelo evaluar el perfil de la empresa en cinco dimensiones: relevancia sectorial (¿encaja con los productos?), tamaño estimado (señales en el texto que indican el volumen del negocio), madurez comercial (¿parece una empresa establecida o un proyecto en fase inicial?), urgencia aparente (¿hay señales en el texto del formulario que indiquen una necesidad inmediata?) y adecuación geográfica. El modelo devuelve una puntuación del 1 al 10 para cada dimensión y una puntuación global, junto con un resumen de dos párrafos que explica el razonamiento.
La tercera capa es la acción. Dependiendo de la puntuación global, el sistema toma caminos diferentes. Si la puntuación es 8 o superior, el sistema genera automáticamente un borrador de cold email personalizado usando el contexto de la empresa y lo coloca en una cola de aprobación. El responsable comercial recibe un mensaje en Telegram con el resumen del lead, la puntuación, las razones del score y el borrador del email. Con un comando de respuesta —literalmente un texto con el identificador del lead— aprueba el envío. El email sale via SMTP en segundos.
Si la puntuación está entre 5 y 7, el lead entra en la base de datos con estado "medium priority" para revisión posterior. Si está por debajo de 5, se registra pero no se genera ninguna acción automática.
La cuarta capa, el fallback, garantiza que cualquier fallo —Jina no puede acceder a la web, Groq devuelve un error, la base de datos no responde— genera una alerta al sistema de vigilancia y escala a revisión manual. Ningún lead se pierde silenciosamente.
Qué se mide, y qué es razonable esperar
Lo que el diseño persigue es que el tiempo de procesamiento por lead baje de la franja de 30-45 minutos a segundos, y que el 100% de los leads reciba una clasificación en minutos desde que rellenan el formulario, independientemente de la hora del día o del día de la semana. Son objetivos de diseño medibles, y por eso cualquier implantación debe instrumentarlos desde el primer día y contrastarlos contra su propia línea base: el punto de partida de cada empresa es distinto.
La pregunta que de verdad importa no es cuánto tarda el sistema, sino si mejora la conversión. Y esa hay que medirla en cada caso: se registra la tasa de lead a reunión cualificada antes de automatizar, se vuelve a medir después y se comparan sobre el mismo segmento y el mismo periodo. No publicamos aquí una cifra de conversión porque no sería la tuya: depende del sector, del volumen y de la calidad de la lista de partida.
Cuando la conversión mejora, no suele deberse solo a la velocidad de respuesta, aunque ese efecto está documentado. Influye también que el email vaya personalizado con contexto real de la empresa del prospecto en lugar de ser una plantilla genérica. Y que el comercial, al no tener que hacer la investigación inicial, dedique la llamada de cualificación a hablar de necesidades en lugar de repetir las preguntas que ya respondería el scraping.
Los tres puntos que hay que resolver sí o sí
Tres cosas que no suelen estar en el diseño inicial y que aparecen en cuanto el sistema toca datos de verdad.
La calidad del scraping depende de la web del prospecto. Cuando la empresa tiene una web bien estructurada, el análisis del LLM es preciso. Cuando la web es un PDF escaneado o tiene todo el contenido en JavaScript renderizado en cliente, Jina no puede extraer texto útil. Por eso hace falta un fallback: si el scraping falla o devuelve menos de 200 caracteres, el sistema puntúa solo con los datos del formulario y añade una nota al resumen indicando que la web no fue accesible.
El modelo de scoring necesita calibración por sector. Las cinco dimensiones funcionan bien en general, pero los umbrales de "alta prioridad" son diferentes según el tipo de empresa. En sectores B2B con ciclos de venta largos, un score de 7 puede ser más relevante que en sectores con compras más transaccionales. Por eso el flujo lleva un parámetro de configuración por cliente que ajusta los umbrales sin tocar el resto.
La aprobación humana es más rápida de lo que se espera cuando el contexto está bien presentado. El mensaje de Telegram que recibe el comercial incluye nombre de la empresa, URL, puntuación, dos frases de resumen y el borrador del email. Con todo eso delante, decidir es cuestión de segundos —bastante menos que abrir el email original y googlear la empresa.
El coste del sistema
La infraestructura corre en el mismo VPS que usamos para todos los sistemas de la empresa: 20-30€ al mes de coste compartido. El coste variable es el de las llamadas al modelo, que a este volumen se mide en céntimos por cada decena de leads, y el del scraping, que en la capa gratuita de Jina cubre el volumen de una empresa de este tamaño. El mantenimiento y el monitoreo van dentro del retainer.
El ROI de un sistema así se calcula antes de implementarlo, no después: con el tiempo comercial que se libera y el coste de la implantación sale un breakeven estimado, y a partir de ahí se decide. Lo que no hay que hacer es dar por buena una mejora de conversión antes de haberla medido.
Si tu empresa tiene un proceso de cualificación de leads que consume tiempo comercial y sigue un patrón estructurado, la arquitectura que describimos aquí es adaptable. El punto de partida es siempre el mismo: documentar la lógica de scoring que ya tienes en la cabeza de tus mejores comerciales.
Cómo diseñamos un sistema de scoring de leads: arquitectura, decisiones y límites · RAXAR