Lead Engine

La mayoría de los negocios locales, como una clínica dental, un despacho de abogados, un taller o un club de pádel, comparten el mismo problema: una web anticuada, sin reserva online, con mala experiencia móvil, o directamente sin web. Rara vez saben cuánto les cuesta en clientes perdidos, y no tienen motivos para fiarse de una propuesta en frío que no demuestra que entiende su situación.

Para una agencia el reto es el espejo: encontrar esos negocios a escala, en todos los sectores que interesan, y contactarlos con algo que parezca investigado y no una plantilla, sin dedicar horas a cada contacto.

Lead Engine se diseñó desde el principio para funcionar con cualquier sector: el mismo motor que encuentra clínicas dentales en Sevilla encuentra instaladores de climatización en Madrid o despachos de abogados en Córdoba, sin más configuración que escribir el término de búsqueda. Funciona en cinco etapas:

• Descubrimiento: se encuentran negocios por categoría y ubicación en texto libre.
• Auditoría: un rastreo automático del sitio y comprobaciones de rendimiento puntúan el SEO, el rendimiento y la accesibilidad, y señalan problemas concretos como la falta de datos estructurados, la ausencia de viewport móvil o formularios de contacto rotos.
• Enriquecimiento de contactos: se extraen correos y teléfonos de la propia web del negocio, cada uno puntuado por fiabilidad y origen.
• Personalización: mensajes y propuestas de rediseño redactados con IA que hacen referencia a los hallazgos reales de la auditoría, no a texto genérico.
• Contacto: correo y WhatsApp Business, cada uno respetando las restricciones reales de su plataforma.

Encima hay un panel completo: una lista de leads filtrable con acciones masivas, una ficha de cada lead con sus resultados de auditoría y fuentes de enriquecimiento, un compositor de mensajes y un gestor de la lista de supresión.

Cinco decisiones dieron forma al producto más que cualquier elección técnica concreta.

Diseñar la capa de revisión antes que la automatización

Antes de que ningún mensaje llegue a un negocio real, alguien debe poder ver qué ha encontrado el sistema y qué va a decir, y cambiarlo si es erróneo. Cada borrador redactado con IA se abre editable en el diálogo de envío y nunca se envía automáticamente; cada hallazgo de la auditoría se muestra con su fuente, no solo con una puntuación; cada contacto suprimido es visible y se puede buscar. La automatización hace la investigación y el primer borrador, y la interfaz mantiene a una persona en el circuito.

Un pipeline, no una lista de funciones

La prospección tiene cinco etapas distintas, y cada una necesitaba su propia lógica sin dejar de servir a cualquier sector. Lo traté primero como un problema de arquitectura de la información: qué cambia según el sector (el tono de la auditoría, la voz del mensaje, la plantilla de rediseño) y qué nunca debería cambiar (los criterios de auditoría, la lógica de puntuación de contactos, las reglas de cumplimiento). Esa separación se convirtió en una capa de configuración: se busca cualquier tipo de negocio en texto libre y el sistema resuelve la voz y los pesos de puntuación adecuados, sin código nuevo por sector.

Evidencia, no volumen

La versión fácil de este producto envía el mismo mensaje a todos. Diseñé la personalización con el principio contrario: cada mensaje tiene que citar algo real y concreto de la auditoría de ese negocio, como un formulario de reservas ausente, la falta de reseñas visibles o una web que no está adaptada a móvil. Eso es lo que hace que un mensaje en frío se perciba como investigado y no como spam.

El contacto como flujo crítico para la seguridad

Llegar a propietarios de negocios reales a escala significa que un error, como escribir a alguien que se dio de baja o superar los límites de una plataforma, cuesta reputación, no solo pulido. Lo traté como la prevención de errores en cualquier interfaz: la lista de supresión se comprueba antes de cada vía de envío, los límites diarios se calculan con la zona horaria local real y cualquier duda bloquea el envío en lugar de dejarlo pasar. WhatsApp se diseñó en torno a las reglas reales de Meta: plantillas preaprobadas para el contacto en frío, un tope diario real y un límite claro entre el primer contacto automatizado y el seguimiento manual.

Verificar con resultados reales

“Parece que funciona” nunca fue suficiente. Cada cambio no trivial, como una nueva regla de auditoría, una migración de base de datos o un cambio en cómo se resuelve la configuración de un sector, se comprobó con resultados reales antes de aceptarlo. Así se detectaron problemas que de otro modo habrían salido a producción sin hacer ruido: desajustes de formato en los prompts generados, una comprobación de cumplimiento que fallaba abierta en vez de cerrada en un caso límite, y una incidencia en producción rastreada hasta un pipeline de despliegue que servía código antiguo tras una compilación fallida.

Más allá del mensaje, el motor produce propuestas a medida de cada negocio: una demo personalizada con un chatbot con IA y una recepcionista de voz con IA, y un concepto de rediseño de la web, ambos basados en lo que encontró la auditoría.

• Un único motor que prospecta cualquier sector de negocio local, verificado en directo con clínicas dentales, despachos de abogados, instaladores de climatización, talleres y clubes deportivos, sin código por sector.
• Un panel que hace inspeccionable y editable todo el pipeline en cada paso: descubrimiento, hallazgos de la auditoría, fiabilidad de los contactos y borradores de mensajes.
• Un pipeline de auditoría a mensaje en el que cada texto se apoya en hallazgos reales y concretos, y no en texto genérico.
• Una capa de contacto con cumplimiento por defecto, con baja de contactos, límites de volumen y reglas por canal incorporados antes de escalar, no añadidos después de un problema.
• Dos canales de contacto operativos de principio a fin, cada uno diseñado en torno a las restricciones reales de su plataforma.

Este proyecto está en la intersección que me interesa: diseño centrado en el usuario aplicado a un sistema donde el usuario es un propietario de negocio que decide si se fía de un mensaje. Mis instintos de UX no cambiaron, que son entender el problema real, diseñar para los casos límite y verificar en lugar de suponer, pero el medio sí. Cada vez más, el trabajo no es solo diseñar la interfaz, sino diseñar el sistema, las salvaguardas y la disciplina de verificación que la rodean.