Automatiza un lead de principio a fin: formulario, CRM y seguimiento

Define el resultado antes de elegir la herramienta

Una automatización comercial útil empieza con una definición sencilla: qué evento inicia el proceso, qué datos necesita el equipo, qué sistema conserva el registro y qué acción confirma que el flujo terminó. Si esas cuatro decisiones no están claras, conectar aplicaciones sólo acelera un proceso confuso.

En este ejemplo, una persona completa un formulario para solicitar una conversación comercial. El flujo valida los campos, busca o actualiza el contacto en el CRM, aplica una regla de prioridad y deja una tarea para el equipo. La persona recibe una confirmación después de que el CRM acepta el registro.

Antes de construir, anota los campos mínimos. Un conjunto razonable incluye correo, nombre, empresa, necesidad, fecha objetivo y autorización de contacto. No pidas datos que el proceso no usa. También define qué sistema será la fuente principal. En este caso es el CRM, no la planilla del formulario ni el historial del automatizador.

El flujo completo, paso por paso

1. El formulario envía un evento por HTTPS al webhook.
2. El flujo rechaza solicitudes sin autenticación o con un formato inesperado.
3. Una etapa de normalización elimina espacios accidentales, unifica nombres de campos y valida los obligatorios.
4. El CRM crea o actualiza el contacto usando una clave estable, como el correo.
5. Una regla explícita asigna el siguiente paso. Puede ser revisión manual, seguimiento comercial o cierre sin contacto.
6. El sistema registra el resultado antes de enviar una notificación o un correo.
7. Si algo falla, una ruta de error conserva el identificador de la ejecución y avisa al responsable sin incluir el formulario completo en el mensaje.

El orden importa. Si envías el correo antes de confirmar la escritura en el CRM, puedes prometer un seguimiento que el equipo nunca verá. Si repites todo el flujo después de un timeout, puedes crear tareas o correos duplicados. El registro duradero debe preceder a los efectos secundarios.

Ejemplo con n8n y HubSpot

En n8n, crea un Webhook con método POST. Usa la URL de prueba mientras construyes y cambia a la URL de producción sólo cuando el workflow esté publicado. Protege el endpoint con el método de autenticación que soporte el emisor. n8n admite autenticación Basic, por cabecera y JWT, además de una lista de direcciones IP como control adicional.

Después del webhook, agrega una etapa que prepare un objeto estable. Conserva únicamente los campos previstos y añade un identificador del evento. Una condición separa las solicitudes completas de las incompletas. Para una entrada que no cumple el contrato, el nodo Stop And Error puede terminar la ejecución con un error legible y activar el flujo de manejo de fallos.

Para HubSpot, el endpoint de upsert permite crear o actualizar registros identificados por una propiedad única. En un flujo de contactos, el correo puede cumplir esa función cuando corresponde a la política de datos del negocio. La solicitud lleva el token en la cabecera Authorization y sólo las propiedades que el CRM necesita. Configura la aplicación con el alcance mínimo de escritura para contactos y guarda el token en el almacén de credenciales, nunca dentro de un nodo de código o un mensaje de error.

La regla de prioridad debe ser visible y fácil de cambiar. Un ejemplo podría marcar como revisión manual toda solicitud incompleta, enviar a seguimiento las solicitudes completas con autorización de contacto y cerrar las que piden no ser contactadas. Esta regla ilustra el mecanismo, no una recomendación universal. El equipo debe reemplazarla por criterios propios y revisar si produce resultados injustos o inútiles.

Evita que un reintento duplique el trabajo

Los webhooks y las APIs pueden entregar o procesar un evento más de una vez. Por eso, el flujo necesita una clave de idempotencia. Si el formulario entrega un identificador estable, guárdalo junto con el estado del proceso. Si no lo entrega, genera una clave a partir de datos que representen la misma solicitud y define durante cuánto tiempo será válida.

El upsert del CRM evita la carrera de crear primero y buscar después, pero no controla todos los efectos. Un contacto único no impide que el flujo genere dos tareas o envíe dos correos. Mantén un registro separado de los eventos procesados y consulta ese registro antes de cada efecto externo. Una repetición autenticada que ya terminó debe responder como procesada sin volver a ejecutar la acción.

También considera el caso más incómodo: el CRM recibió la solicitud, pero la conexión terminó antes de devolver una respuesta. No asumas que la escritura falló. Busca el contacto por la clave estable o manda el evento a una cola de reconciliación. Repetir a ciegas es la forma más rápida de convertir un fallo de red en un problema comercial.

Diseña la ruta de error antes de activar el flujo

n8n permite asignar un workflow de error a otro workflow. Ese flujo comienza con Error Trigger y recibe datos sobre la ejecución fallida, incluido el último nodo ejecutado cuando esa información existe. Úsalo para crear una alerta con el identificador de ejecución, el nombre del workflow, la etapa y una descripción breve.

No copies el cuerpo completo del formulario en el correo de alerta. Los datos personales, tokens y cabeceras de autenticación no pertenecen a los logs. Quien investiga el incidente debe abrir la ejecución con el acceso correspondiente.

Define qué errores admiten reintento. Un 429 o un fallo de red inequívocamente anterior a la escritura puede esperar y reintentarse con un límite. Un timeout después de enviar la escritura exige comprobación. Un error de validación necesita corregir datos o configuración, no cinco intentos idénticos. La pantalla de ejecuciones de n8n permite revisar estados y volver a ejecutar un fallo con la versión original o la versión corregida del workflow.

Prueba seis casos antes de usar datos reales

Usa direcciones y empresas ficticias en un entorno de prueba. Verifica estos casos por separado:

1. Una solicitud válida crea un contacto y una sola tarea.
2. El mismo identificador enviado dos veces no duplica tareas ni mensajes.
3. Una solicitud incompleta termina en revisión o error sin escribir datos parciales.
4. Una firma o credencial inválida no inicia el proceso.
5. Una respuesta 429 respeta la espera y el límite de reintentos.
6. Un timeout posterior a la solicitud queda pendiente de reconciliación en vez de repetirse.

Guarda para cada caso el identificador de ejecución, el estado final y la evidencia en el CRM. La prueba no termina cuando todos los nodos se ven verdes. Termina cuando el contacto, la tarea y la notificación coinciden con lo esperado y una segunda ejecución no cambia ese resultado.

Pasa a producción con una lista corta de controles

Antes de activar la URL de producción, confirma que el webhook usa HTTPS y autenticación, que el token del CRM tiene sólo los permisos necesarios y que los secretos están fuera del workflow exportado. Revisa el esquema de datos, el aviso de privacidad y el tiempo de conservación con la persona responsable del negocio.

Deja activa la ruta de error, asigna un responsable y define una pausa manual. Conserva una versión exportable del workflow y documenta la clave usada para detectar duplicados. Durante los primeros días, compara una muestra de formularios con el CRM y con las tareas creadas. Corrige la regla si está enviando solicitudes a la ruta equivocada.

El primer objetivo no es automatizar todo el ciclo comercial. Es demostrar que una solicitud entra una vez, queda registrada con contexto suficiente y llega a una persona que sabe qué hacer después. Cuando ese recorrido sea estable, añade nuevas ramas sin perder trazabilidad.