Automatización de leads con Make: guía 2026

Un envío de formulario sirve cuando alguien puede actuar sobre él. Un formulario ordenado que deja respuestas en una hoja olvidada no es un flujo terminado. Tampoco lo es un escenario que crea dos contactos de la misma persona, avisa repetidamente a todos o se detiene sin aviso tras fallar una conexión.

Esta guía diseña el camino desde el envío hasta una siguiente acción con responsable. Empieza con un registro pequeño, separa personas de eventos, añade reglas transparentes de cualificación y elige destino. Los ejemplos usan contactos ficticios y pruebas deliberadas. No son casos de clientes, mediciones de tráfico ni promesas de ventas adicionales.

Puedes construir el flujo con la documentación enlazada. Flowpaja dispone de plantillas gratuitas existentes y Lead Router de pago como puntos de partida. El producto conecta Google Forms, HubSpot y Slack con enrutamiento por presupuesto. No reparte leads por round-robin. Elige según lo que debe hacer la siguiente persona, no según el número de aplicaciones en el lienzo.

1. Define un resultado útil antes de elegir módulos

Escribe una frase: «Cuando alguien envía una consulta, guardamos un contacto, registramos la consulta y avisamos al responsable apropiado». Contiene tres trabajos distintos. El contacto representa a la persona, la consulta representa lo que hizo y el aviso pide a alguien responder. Reunir todo en una fila puede servir inicialmente, pero entiende qué sobrescribirá un envío posterior.

Decide quién realiza la siguiente acción y dónde trabaja. Slack encaja cuando lo usa el responsable. Un correo al propietario sirve si basta una revisión diaria. Un CRM ayuda cuando hay etapas, notas y varios responsables. Enviar los mismos datos a tres destinos crea tres lugares que mantener. Empieza con el conjunto mínimo útil.

Define también cuándo detenerse. Repetir la entrega del mismo evento no debería generar otro aviso. Un contacto conocido con una consulta realmente nueva puede merecer un aviso nuevo. Un correo vacío necesita revisión, no un contacto compartido llamado «desconocido». Estas decisiones determinan los filtros más directamente que el proveedor del formulario.

Para la primera construcción, anota formulario, destino, identidad, campos de cualificación, responsable y respuesta esperada. Úsalo como lista de aceptación. Un icono verde no basta: inspecciona también el registro y el mensaje de destino.

2. Usa un contrato de lead pequeño y explícito

Un contrato práctico incluye event_id, submitted_at, email, name, company, budget_amount, budget_currency, source y message. Lo opcional sigue siendo opcional. Presupuesto ausente es desconocido, no cero. Empresa ausente no invalida necesariamente una consulta. Correo ausente sí impide que una búsqueda por correo tenga sentido.

Durante diagnóstico, conserva originales junto a normalizados, como email_raw y email_key. Normaliza la clave con lower(trim(email)). No quites puntos ni etiquetas con signo más, ni supongas que todas las direcciones son Gmail. Podrías fusionar contactos distintos. Normalizar es una política de comparación, no prueba de identidad.

Haz explícitas las unidades del presupuesto. 10000 dice poco sin moneda y periodo. Presupuesto anual, mensual y de proyecto único son señales distintas. Los ejemplos usan USD para un proyecto ficticio único. Convierte moneda solo si añades una fuente verificada y decides tasa y fecha registradas.

Son nombres propuestos, no campos de salida garantizados del proveedor. Mapéalos desde un envío capturado y confirma ruta y tipo reales para el disparador seleccionado.

3. Captura formularios con el disparador apropiado

Google Forms puede escribir respuestas en una hoja vinculada. Google Sheets › Watch New Rows recoge filas nuevas según un horario. Es un inicio sencillo, pero introduce comprobaciones y cursor. Conserva encabezados estables y evita filas vacías dentro de la tabla vigilada. Editar una respuesta existente no garantiza una fila nueva ni otro evento del vigilante.

Flowpaja ya tiene una guía Google Forms a HubSpot y Slack. Úsala para la conexión inicial. La extensión de respuestas editadas del paquete EN anterior trata otro problema: actualizar sin considerar cada escaneo una consulta nueva.

Un disparador instantáneo puede evitar comprobaciones vacías si proveedor y cuenta lo permiten. Make ofrece módulos de respuestas Typeform y conexión Tally. La estructura depende de preguntas y conexión. Renombrar una pregunta visible no garantiza un token estable. Captura otro ejemplo después de cambiar el formulario.

Un webhook genérico sirve si el formulario puede enviar una petición HTTP documentada. Añade Webhooks › Custom webhook, crea uno nuevo y usa Detect new values mientras envías un ejemplo ficticio. Detectar estructura facilita mapeo; no vuelve fiables todos los futuros valores. Valida campos obligatorios antes de crear fila o contacto.

4. Prueba el contrato webhook antes de conectar formularios reales

Usa escenario privado, hoja y destino de prueba. El ejemplo describe una petición; no se ha enviado aquí. Sustituye el marcador solo en tu entorno. Dirección e identificador son ficticios.

curl -X POST "$MAKE_TEST_WEBHOOK_URL" \
  -H "Content-Type: application/json" \
  --data '{"event_id":"enquiry-001","email":"alex@example.invalid","name":"Alex Example","budget_amount":10000,"budget_currency":"USD","source":"test-form"}'

Inspecciona el paquete: ¿budget_amount es Number o Text? ¿Está el correo en la ruta prevista? ¿Una respuesta anidada necesita mapeo explícito antes de Sheets? Envía otra petición con el mismo event_id para repetición, y otra con event_id nuevo y correo igual para un contacto que vuelve.

Protege el webhook según la autenticación compatible del proveedor y Make. No publiques su URL privada en descargas, capturas o repositorios. En HTTP saliente, Return error if HTTP request fails controla si 4xx o 5xx se convierte en error. Inspecciona la respuesta al diseñar recuperación: un timeout no prueba que la escritura remota no ocurrió.

5. Trata Facebook Lead Ads como fuente separada

Facebook Lead Ads recoge consultas sin llevar primero al visitante a una web. Make documenta New Lead, Watch Leads y Get Lead Details. Hay que configurar acceso a Page y leads. Ver una cuenta publicitaria no demuestra acceso a leads desde Make.

Captura un lead de prueba antes del CRM e inspecciona respuestas. Mapea por identificadores devueltos realmente. Comprueba vacíos, casillas y teléfonos. El ID de lead del proveedor sirve como event_id porque una entrega repetida puede conservarlo. Guarda Page y formulario al lado cuando sean necesarios para evitar colisiones.

Esta guía no repite el contenido Facebook existente ni crea campañas. El diseño también debe poder probarse con fixtures ficticios. Si el mecanismo de prueba no entrega al disparador seleccionado, resuelve acceso primero; no declares lista toda la cadena.

No enriquezcas automáticamente porque una app puede hacerlo. Puedes cualificar con presupuesto, proyecto y plazo declarados. Añade una búsqueda de pago solo cuando identifiques la decisión concreta que cambia esa información.

6. Separa deduplicación de contacto y de evento

Por correo preguntas «¿conocemos a esta persona bajo esta clave?». Por evento preguntas «¿hemos tratado este envío?». Una persona puede enviar dos consultas reales. Una consulta puede entregarse dos veces después de un timeout.

En una tabla sencilla, Google Sheets › Search Rows busca el correo normalizado. Sin coincidencia produce un paquete vacío con Total number of bundles = 0. Ruta = 0 para nuevo y > 0 para existente. No deduzcas existencia de la longitud de un agregador. Define límite y varias coincidencias: más de una fila es un problema de datos, no permiso para actualizar contactos indiscriminadamente.

Para repetición, conserva el event_id aparte. El registro puede guardar etapa, ID de destino e intento anterior. Marcar antes de escribir reduce un riesgo, pero puede dejar un evento reclamado tras fallar la escritura. Modela estados intermedios; «reservado» no significa «entregado».

Buscar y crear no es transacción atómica. Dos ejecuciones paralelas pueden ver ausencia. Procesamiento secuencial ayuda si un escenario es el único escritor, pero no protege contra otros escenarios o escritura manual. Declara el alcance y prueba concurrencia antes de prometer ausencia de duplicados.

7. Mantén precisos identidad y propiedades del CRM

HubSpot puede buscar y luego crear o actualizar. Make documenta Search for Contacts, Create a Contact, Update a Contact y Create or Update a Contact. Elige una ruta que entiendas e inspecciona el ID devuelto. No traslades la semántica vacía de Sheets a HubSpot sin observar su salida.

Correo exacto corresponde al alcance de Lead Router. No implica comparación difusa de empresas, resolución de alias ni fusión automática de un CRM desordenado. Conserva información existente si el envío deja opcionales vacíos. Decide si el presupuesto nuevo sustituye el último del contacto o pertenece a otra consulta.

Prueba las enumeraciones por separado. Etiqueta visible y valor interno pueden diferir. Mapea el valor permitido por el portal destino, no el texto de la opción por apariencia. Los valores de un portal copiado no son universales. Revisa propiedades y valores admitidos en el portal real.

Un fallo de CRM debe impedir el aviso de éxito. «Contacto creado» es falso si falló la creación. Usa una referencia mínima al evento y etapa en el camino de error. No publiques consulta completa ni credenciales en un canal amplio.

8. Puntúa con hechos declarados, sin enriquecimiento

Empieza con reglas explicables. Un sistema ficticio concede dos puntos a presupuesto USD conocido de al menos 10000, uno a equipo declarado de diez o más y uno a servicio realmente ofrecido. Son decisiones de diseño, no predictores medidos de conversión.

Guarda entradas, puntuación y motivo juntos. «3: supera presupuesto; servicio compatible» ayuda más que «la IA dice caliente». Presupuesto ausente necesita motivo desconocido, no etiqueta engañosa de presupuesto cero. Una puntuación baja debe pasar a revisión normal, no descartar silenciosamente una consulta válida.

Sheets puede contener columnas auxiliares o Make calcular después del mapeo. Elige una sola fuente de reglas. Si cambia el umbral en la hoja y Make mantiene el antiguo, el aviso contradice el score. Guarda la versión de reglas durante pruebas.

Prueba 9999, 10000 y 10001; cero, vacío y texto; USD y otra moneda. Funcionar para el ejemplo no termina una regla. No prometas que un lead marcado caliente comprará.

9. Enruta avisos hacia una acción real

La ruta por presupuesto puede avisar a un canal Slack especializado o uno general. El módulo se llama Send a Message. Añade la app al canal cuando haga falta y prueba el destino de la conexión. Su nombre en una captura no prueba permiso para publicar.

Mensaje breve: ID de consulta, nombre, origen, motivo y registro que abrir. Evita que texto del usuario cause menciones amplias o formato inesperado donde la configuración lo permita. Prueba solo en canal privado. No sustituyas el destinatario propietario por un cliente real.

Para correo al propietario, su dirección queda fija y visible. La del remitente entra en el cuerpo solo si es necesaria. Aviso al dueño y respuesta automática al visitante son productos distintos, con riesgos distintos. Decide antes de añadir Gmail › Send an email.

Round-robin también es otro trabajo: lista de responsables elegibles, puntero, ausencias y concurrencia. El paquete EN anterior lo desarrolla aparte. El enrutamiento por canales de presupuesto de Lead Router no asigna propietarios en rotación.

10. Trata fallos según lo que ocurrió

Usa Retry (antes Break), Skip (antes Ignore), Resume, Commit y Rollback. Elige según el registro que conservar y el trabajo que puede continuar. Retry sirve para fallos recuperables con almacenamiento incompleto configurado. Todavía requiere replay seguro de efectos.

Skip descarta el paquete. Puede permitir continuidad, pero no es solución universal para leads perdidos. Resume aporta salida de sustitución; úsalo solo con significado válido, como una búsqueda opcional expresamente desconocida. Nunca inventes un ID para una creación de contacto fallida.

Commit y Rollback dependen del comportamiento transaccional compatible. No deshacen un Slack o correo entregado. Identifica la última acción irreversible antes del handler. Guarda estado para separar «CRM completo, aviso fallido» y «CRM fallido, aviso no intentado».

Copia el texto real del fallo. La documentación general incluye There is no scenario listening for this webhook y Module initialization failed with an error. Los payloads de otros proveedores varían. Recoge el error exacto de tu prueba antes de citarlo. Un registro útil contiene event_id, módulo, hora y resultado; no necesita todos los datos personales.

11. Calcula créditos con supuestos explícitos

Para acciones de coste fijo, modela comprobaciones, módulos ejecutados y paquetes. Las rutas dibujadas no prueban que todas se ejecutaron. No cuentes como mensaje un camino omitido. Consulta créditos de tus módulos; IA y costes dinámicos requieren otro modelo.

Cada 15 minutos son cuatro comprobaciones por hora: 4 × 24 × 30 = 2880 en 30 días. A un crédito por comprobación son 2880 antes de tratar leads. Es aritmética, no factura universal ni medición de este paquete. En 31 días serían 2976 comprobaciones bajo el mismo supuesto.

Un ejemplo con 720 comprobaciones y 50 leads que ejecutan tres acciones adicionales cada uno da 720 + 50 × 3 = 870. Excluye reintentos, avisos adicionales, búsquedas y otros escenarios. Es diseño, no consumo medido de Lead Router.

Make Free incluye actualmente 1000 créditos mensuales, dos escenarios activos, mínimo de 15 minutos entre ejecuciones programadas y máximo de cinco minutos de ejecución. Un webhook instantáneo no es un sondeo: no le atribuyas comprobaciones cada 15 minutos. Las cuotas se comparten. Una descarga gratis no garantiza coste operativo cero en toda combinación.

12. Prueba registro, ruta y recuperación

Crea hoja, registros CRM y canal de prueba. Usa example.invalid. Fixtures no demuestran demanda, consentimiento, correo entregado a clientes ni ingresos. Define resultados antes de ejecutar para distinguir prueba aprobada de salida que parece razonable.

Prueba contacto nuevo, evento repetido exacto, contacto existente con evento nuevo y obligatorio vacío. Incluye límite del presupuesto y moneda distinta. Revisa ruta y campos. Si la especificación exige omitir notificación duplicada, confirma que no aparece otro Slack.

Prueba recuperación: desconecta o configura mal un destino de prueba, observa y restaura. ¿Replay crea otra fila? ¿Actualiza el contacto correcto? ¿Repite un aviso ya exitoso? Mantén la clave del evento; crear otra anula la prueba de repetición.

Revisa cambios de ciclo: reserva modificada no es nueva persona; consulta cancelada puede necesitar estado; correo cambiado puede necesitar reconciliación manual en vez de fusión. Documenta lo que el flujo no puede decidir y envíalo al responsable.

13. Elige la plantilla existente según la tarea

Para formulario por webhook, empieza con Webhook to Sheets con comprobación de duplicados. Su clave es request_id; consérvala cuando el emisor reintenta. Para avisos de Google Forms, usa Form responses to Slack. Ninguna añade contactos HubSpot.

Para Google Forms, actualizaciones HubSpot y canales Slack por presupuesto, consulta Lead Router, 19 USD. Ofrece blueprint descargable y materiales. No es servicio alojado, algoritmo de asignación ni promesa de captura instantánea. La hoja se comprueba en el horario elegido.

Para facturas vencidas, Overdue Invoice Digest gratuito resume al propietario. Invoice Reminder es el flujo de recordatorios al cliente de pago. No vendas un digest como cobro automático o conciliación bancaria.

Si necesitas Make, usa https://www.make.com/en/register?pc=flowpaja: affiliate link. Sustituye solo tras verificar destino y titularidad. Todo sigue siendo instrucciones en archivos. La configuración necesita conexiones, mapeo y pruebas propias.

14. Sigue las notas específicas de construcción

La fuente EN enlaza borradores locales de su paquete anterior, no diez páginas públicas confirmadas. Aquí se conservan todos los temas sin enlaces relativos a archivos no incluidos. Verifica una URL pública canónica antes de enlazarla.

1. Respuestas editadas de Google Forms y actualizaciones CRM seguras: tratar cambios sin repetir todos los avisos.
2. Errores de contacto duplicado HubSpot: identidad, colisiones y recuperación.
3. Cualificación de presupuesto Typeform: aviso cualificado frente a notificación genérica.
4. Opcionales y presupuesto Tally: arrays, vacíos y moneda.
5. Formularios Webflow a CRM: preservar formulario y estado de evento.
6. Contrato webhook WordPress: integrar plugins sin suponer soporte nativo.
7. Score transparente en Sheets: hechos declarados y reglas visibles.
8. Round-robin con Data Store: propiedad separada de canales de presupuesto.
9. Ciclo de reservas Calendly: creación, cambio y cancelación.
10. Dedupe de evento y correo webhook: bloquear replay sin descartar consultas nuevas.

15. Lista de lanzamiento que puedas responder

Antes de activar, verifica contrato, rechazo o desvío de campos inválidos y ruta de búsqueda vacía. Marca claramente destinos de prueba. Cambia umbrales solo después de acordar su significado. Guarda blueprint funcional sin secretos.

El aviso debe contar lo sucedido, no lo esperado. Comprueba recuperación de escritura y de notificación por separado. Revisa horario contra la cuota compartida. Anota consumo observado después del test; antes es desconocido.

Entrega una nota operativa: dónde cambiar umbral, dónde aparecen fallos, qué se reintenta seguro y cuándo pausar. El resultado debe poder operarse, no solo contemplarse. Haz estas pruebas en una cuenta real; este paquete no las ejecutó.