Recuperación de leads con IA: N8N, Twilio y ElevenLabs

Sistema de recuperación de leads con IA: cómo lo armé con N8N, Twilio y ElevenLabs

Introducción

La mayoría de los negocios pierde leads no porque el producto esté mal, sino porque nadie hizo el seguimiento a tiempo. Se envía el formulario, alguien suma un producto al carrito, una llamada queda sin devolver, y para cuando alguien del equipo lo agarra, la ventana se cerró. Armé un sistema que resuelve exactamente eso, y corre cada 5 minutos sin que nadie lo toque.

El sistema detecta leads nuevos de tres fuentes: formularios de contacto, carritos abandonados y pedidos de contacto sin atender. Los clasifica, genera un mensaje contextual con Claude y sale por el canal que corresponda: WhatsApp, SMS o una llamada de voz en tiempo real con un agente de IA. Todo se orquesta en N8N. Los archivos de workflow, los prompts del agente y las instrucciones de configuración están en el repo linkeado en la descripción.

Panorama de la arquitectura

La capa de datos vive en Airtable. Tres tipos de lead alimentan una sola tabla:

• Formularios de contacto que nunca recibieron respuesta
• Carritos abandonados, donde alguien sumó un producto pero nunca completó la compra
• Pedidos de contacto que se perdieron en el camino

Cada registro tiene un campo status. El workflow principal busca los registros con status = new cada 5 minutos y los procesa uno por uno.

Los dos archivos de workflow del repo son:

1. Workflow principal: trae los leads, los clasifica, genera los mensajes, rutea al canal correcto y actualiza Airtable
2. Workflow del webhook post-llamada: recibe la transcripción de ElevenLabs cuando termina la llamada, extrae los datos relevantes y actualiza el registro

La separación importa. El flow principal no espera el resultado de la llamada: la dispara y sigue. La transcripción llega después por webhook, y por eso vive en su propio flow.

Normalizar el lead antes de que lo vea el agente

Uno de los primeros pasos después de traer los leads de Airtable es la normalización. Antes de que el nodo de Claude vea nada, los leads pasan por un paso que impone una estructura fija, sin importar qué campos existan en la tabla de origen.

Conviene hacerlo aunque parezca trabajo de más. Los esquemas de Airtable cambian. Alguien suma un campo, renombra otro, o lo borra. Sin normalización, cualquiera de esas cosas rompe el prompt del agente. Con normalización, el agente siempre recibe la misma forma de datos y te avisa si falta algo, en lugar de producir un mensaje malo en silencio.

Generación del prompt: por qué el modo de contacto lo cambia todo

El nodo de generación de prompt hace más que rellenar un template. Se ramifica según dos dimensiones: el origen del lead (web, carrito, llamada perdida) y el modo de contacto (texto o llamada).

Acá es donde muchos sistemas parecidos recortan y terminan mandando mensajes genéricos. Un mensaje de WhatsApp tiene límite de caracteres, tiene que respetar los templates aprobados si estás en la Business API, y se lee distinto que una frase hablada. Un agente de IA que llama necesita saber su línea de apertura antes de que atiendan, no después. Las mismas instrucciones no pueden cubrir los dos casos.

Para los canales de texto, el prompt le pide a Claude un mensaje corto y directo, acorde al origen del lead. Para las llamadas, el prompt genera una variable opening, que es lo que dice el agente de ElevenLabs apenas atienden. Esa variable se pasa dinámicamente en la llamada a la API de ElevenLabs, así el agente no arranca en frío.

La integración de ElevenLabs con Twilio

Para las llamadas, el flow le pega a la API de ElevenLabs con un payload que incluye:

• El ID del agente (configurado en ElevenLabs con el system prompt y las reglas de conversación)
• El número de Twilio registrado dentro de ElevenLabs
• El número de destino (el teléfono del lead)
• Variables dinámicas: opening, ID del lead, origen del lead

El system prompt del agente está en el repo. Decisión de diseño clave: si el lead muestra desinterés, el agente cierra y corta. Sin insistir, sin presión. El prompt cubre ese caso explícitamente, porque un agente de IA que sigue empujando cuando alguien dice que no es peor que no tener agente.

El webhook post-llamada lo dispara ElevenLabs cuando termina la conversación y se procesa la transcripción. Le pega a la URL del webhook de N8N, un túnel de ngrok si corrés local o una IP pública si está desplegado, y ahí sigue el workflow secundario. Extrae la transcripción, separa las líneas del agente de las del lead, y escribe todo de vuelta en Airtable junto con el estado y la marca de tiempo.

Tener la transcripción completa en Airtable es lo que hace útil al sistema más allá del "¿los contactamos?". Podés correr análisis de sentimiento sobre lo que dijo el lead, identificar objeciones que se repiten, o marcar llamadas donde el agente hizo algo raro.

Configuración de Twilio

Para SMS y WhatsApp: sacá un número de la consola de Twilio. Los de Estados Unidos salen $1.15 por mes, varía según el país. Después copiá el Account SID y el Auth Token del dashboard y cargalos como credenciales en N8N. El sender de WhatsApp y el de SMS pueden ser números distintos, los dos definidos como variables arriba del workflow principal para cambiarlos en un solo lugar.

Para voz: importá el número de Twilio en ElevenLabs desde Phone Numbers, asignale tu agente y configurá ahí la URL del webhook post-llamada. Esa es la URL que dispara el workflow secundario de N8N cuando termina cada llamada.

Manejo del estado en Airtable

Después de cualquier intento de contacto, el registro se actualiza al toque: el estado pasa a contacted, se setea la fecha y se guarda el último mensaje enviado. Eso evita que el loop de 5 minutos vuelva a contactar al mismo lead en la corrida siguiente. Simple pero crítico. Si te lo olvidás o la actualización falla en silencio, los leads empiezan a recibir mensajes duplicados o llamadas repetidas, que es peor que no contactar.

Sobre la discusión low-code contra código propio

Quiero abordarlo directo porque siempre aparece. Todo este sistema corre en N8N, sin backend propio. El trade-off es real: perdés algo de flexibilidad y de profundidad para debuggear frente a escribirlo en código, y quedás atado al formato de workflow de N8N para la portabilidad.

Pero para esta clase de problema, low-code fue la decisión correcta. Acá la lógica es orquestación: traer, clasificar, ramificar, llamar una API, actualizar estado. No hay complejidad algorítmica que pida código propio. Construir lo mismo desde cero habría llevado bastante más tiempo sin ninguna ventaja real de calidad. El comportamiento del agente sale del prompt, no de la infraestructura de alrededor.

Donde se caería es con alta concurrencia, porque el modelo de ejecución de N8N tiene límites. También con reintentos con backoff exponencial, o un manejo de estado muy a medida. Para un sistema que maneja decenas o cientos de leads por día, aguanta bien.

El principio de diseño que conviene guardar: normalizá los datos temprano, definí las variables en un solo lugar y mantené los dos flows separados. Esas tres decisiones son las que lo hacen mantenible cuando cambian los campos de Airtable o cambiás ElevenLabs por otro proveedor de voz.

¿Te sirvió el post? ¡Compartilo!

-Gonza