n8n con WhatsApp, Telegram y Notion: 4 casos reales

La mayoría de tutoriales de n8n te enseñan a conectar dos nodos y celebrarlo. Luego llegas a tu empresa, lo pones en producción y descubres que el problema nunca fue conectar la API.

Aquí van cuatro automatizaciones que monto de verdad para pymes. Cada una con los nodos en orden, la credencial que hace falta y, más importante, qué parte no automatizo. Esa última columna es la que separa un sistema que aguanta de una demo que alguien desenchufa a los tres meses.

Antes de nada, la regla de la casa: n8n hace lo determinista. Si el camino está claro y las reglas son conocidas, es un workflow. Cuando la entrada es variable y hay que interpretar, entra un modelo, y solo en ese nodo. Si quieres el razonamiento completo, lo explico en la comparativa entre n8n, Make y Zapier.

1. Aviso en Telegram cuando entra un lead que merece la pena

El problema real no es enterarse de que ha entrado un lead. Es enterarte de los que importan sin que el móvil vibre cuarenta veces al día.

Flujo:

Webhook (POST desde el CRM)
  → Set (normalizar campos: nombre, email, empresa, origen, mensaje)
  → If (¿cumple criterios mínimos?)
      ├─ true  → Telegram: sendMessage
      └─ false → NoOp (queda registrado, no molesta)

El nodo If es todo el valor del flujo. Sin él tienes una notificación más. Los criterios que uso suelen ser: email corporativo (no gmail/hotmail), campo empresa relleno y origen distinto de formularios de descarga. No hace falta IA para eso: son comparaciones.

Credenciales: token de bot de Telegram, creado hablando con @BotFather. Necesitas además el chat_id. Para un chat personal, escribe al bot y consulta https://api.telegram.org/bot<TOKEN>/getUpdates. Para un grupo, añade el bot al grupo primero; el chat_id de grupo es negativo.

Mensaje con formato:

🔵 Lead nuevo

Nombre: {{ $json.nombre }}
Empresa: {{ $json.empresa }}
Origen: {{ $json.origen }}

{{ $json.mensaje }}

Activa Parse Mode: HTML si vas a meter negritas o enlaces. Con Markdown te la juegas: un guion bajo en un email rompe el envío y n8n te devuelve un 400 que tardas media hora en entender.

Qué no automatizo: la respuesta. El aviso llega, la persona decide. He visto flujos que mandan un WhatsApp automático al lead en el segundo cero y lo único que consiguen es parecer un bot.

2. Pedidos que llegan por WhatsApp, registrados en Notion

Este es el caso más pedido y el que más cuidado exige, porque hay dos formas de conectar WhatsApp y no son equivalentes.

API oficial de Meta (WhatsApp Business Platform)

Es la vía legal y soportada. Das de alta un número en WhatsApp Business Platform, verificas el negocio, y Meta te da un token permanente y un webhook. n8n trae nodo nativo de WhatsApp Business Cloud.

A favor: no te cierran la cuenta, tienes soporte, puedes usar plantillas aprobadas para iniciar conversación. En contra: hay proceso de verificación, tarifado por conversación según la política vigente de Meta (consúltala antes de presupuestar, cambia), y solo puedes escribir libremente dentro de la ventana de atención al cliente que abre el usuario al escribirte.

Evolution API y similares

Son puentes no oficiales que se conectan como si fueran WhatsApp Web. Se instalan en tu servidor, no pasan verificación y no tienen coste por mensaje.

A favor: montas en una tarde, sin trámites. En contra: es uso no autorizado de la plataforma. Meta puede bloquear el número sin preaviso, y si ese número es el de tu empresa, el daño es real. Además, cualquier cambio interno de WhatsApp te tumba el puente.

Mi criterio: si el número es el del negocio y hay clientes al otro lado, API oficial. Los puentes no oficiales los dejo para pruebas internas o números que puedes perder sin consecuencias. Esto no es moralismo, es gestión de riesgo: el ahorro no compensa quedarte sin el canal por el que te escriben tus clientes.

Flujo (con la API oficial):

WhatsApp Trigger (mensaje entrante)
  → Switch (¿es texto, imagen o documento?)
  → OpenAI / Anthropic (extraer pedido a JSON)
  → Code (validar estructura y campos obligatorios)
  → If (¿válido y con confianza alta?)
      ├─ true  → Notion: create page (estado "Por revisar")
      └─ false → Telegram al responsable con el texto original

El nodo del modelo tiene una única tarea: convertir "ponme 3 cajas de las grandes y 2 de las otras para el jueves" en un objeto con productos, cantidades y fecha. Le pido que devuelva JSON estricto y que incluya un campo de confianza. Si el modelo no está seguro, no inventa: lo manda a una persona.

Credenciales: token permanente de Meta más el ID del número de teléfono, y una integración interna de Notion compartida con la base de datos concreta. En Notion no basta con crear la integración: hay que entrar en la base de datos, menú de opciones, conexiones, y añadirla ahí. Si te devuelve object_not_found, es esto el 90% de las veces.

Qué no automatizo: el pedido nunca entra directo al sistema de gestión. Cae en Notion como "Por revisar". Una persona lo confirma. Un error de transcripción en un pedido lo paga el cliente, y la confianza se recupera mucho más lento que el tiempo que ahorras.

3. Recordatorio de factura pendiente desde Odoo

Aquí no hay IA ni falta que hace. Es una consulta, un filtro y un email. El valor está en que ocurre sin que nadie se acuerde.

Flujo:

Schedule Trigger (cada día, 9:00 Europe/Madrid)
  → Odoo: getAll en account.move
      filtros: state = posted, payment_state = not_paid, move_type = out_invoice
  → Code (calcular días de retraso desde invoice_date_due)
  → Switch (tramos: 3 / 15 / 30 días)
      ├─ 3  → Gmail: crear borrador, aviso suave
      ├─ 15 → Gmail: crear borrador, tono firme
      └─ 30 → Telegram al responsable: llamar, no escribir

Credenciales de Odoo: URL de la instancia, nombre de la base de datos, usuario y API key (en Odoo se genera desde el perfil de usuario, en preferencias, no es la contraseña). Con una instalación propia comprueba que el puerto XML-RPC es accesible desde donde corra n8n.

Dos detalles que te ahorran un rato: el modelo correcto en Odoo moderno es account.move con move_type en out_invoice, no el antiguo account.invoice. Y filtra siempre por state = posted: si no, te aparecen borradores y acabas reclamando facturas que el cliente nunca recibió.

Qué no automatizo: el envío. El flujo deja borradores en Gmail. Nico revisa y manda. Reclamar dinero por automático a un cliente con el que estás negociando una ampliación es la clase de error que ninguna eficiencia compensa. Y a los treinta días el sistema no escribe: avisa de que toca llamar.

4. Clasificar la entrada abierta con un modelo, y guardarla en Notion

La bandeja de info@ es el caso perfecto para un modelo: entradas variables, categorías estables y coste de error bajo si lo diseñas para que proponga en vez de decidir.

Flujo:

Gmail Trigger (mensajes nuevos, sin leer)
  → Code (limpiar firma, citas y HTML)
  → OpenAI / Anthropic (clasificar, salida JSON)
  → Code (validar contra la lista cerrada de categorías)
  → Switch (por categoría)
      ├─ cliente       → Notion + etiqueta Gmail
      ├─ proveedor     → Notion + etiqueta Gmail
      ├─ administracion→ Notion + Telegram
      └─ ruido         → solo etiqueta

El prompt le da la lista cerrada de categorías, una definición de cada una, dos ejemplos por categoría y la orden de devolver exactamente esta forma:

{
  "categoria": "cliente",
  "confianza": 0.0,
  "motivo": "una frase",
  "requiere_respuesta": true
}

Y después el nodo Code comprueba que categoria está en la lista permitida. Los modelos se inventan categorías nuevas cuando el caso es raro. Validar la salida contra una lista cerrada es la diferencia entre un clasificador y una fuente de basura ordenada.

Por debajo de una confianza razonable, no clasifico: dejo el email en la bandeja y que lo vea una persona. Prefiero cien sin clasificar a diez mal archivados.

Credenciales: OAuth de Google para Gmail (con cuenta de empresa, lo limpio es una cuenta de servicio con delegación) y la API key del proveedor del modelo. No metas la clave en un nodo Code: va en el gestor de credenciales de n8n, siempre.

Coste: depende del proveedor y del modelo, y cambia a menudo. Mira la tabla de precios oficial el día que lo montes y calcula sobre tu volumen real de correos. Los modelos pequeños clasifican texto corto perfectamente; no necesitas el modelo más caro para decidir si un email es de un proveedor.

Lo que tienen en común los cuatro

Mira dónde está la persona en cada flujo. En el uno decide si responde. En el dos confirma el pedido. En el tres manda el borrador. En el cuatro revisa lo dudoso.

No es falta de ambición. Es que la automatización que aguanta en el tiempo es la que deja el juicio donde debe estar y se come el trabajo mecánico que lo rodea. Cuando alguien me enseña un flujo de treinta nodos sin un solo punto de revisión, no veo un sistema avanzado: veo algo que va a fallar en silencio.

Si te estás planteando cuál de los cuatro montar primero, el criterio es simple: elige el que hoy haces a mano cada semana, con el mismo formato, y del que puedas decir si salió bien o mal mirándolo. Ese.

Y si prefieres que lo montemos nosotros sobre tus procesos reales, así trabajamos.