Cómo armamos los avisos del despacho con n8n, Telegram y Notion (y lo que se rompió en el camino)

En esta bitácora contamos cómo están hechas por dentro las cosas que construimos. Esta vez le toca al circuito que más trabajo nos dio: el que recibe un caso desde un formulario, lo guarda ordenado en Notion, avisa al abogado por Telegram y por correo, y le deja una primera nota escrita por la IA. Encima de eso corren dos relojes: uno que revisa los vencimientos cada mañana de lunes a viernes y otro que manda un reporte cada domingo.

No es un tutorial nodo por nodo. Es el mapa de cómo lo pensamos y, sobre todo, de qué falló, incluido lo que encontramos en la auditoría de todos nuestros flujos del 6 de octubre de 2026. Si armas algo parecido, lo más útil probablemente sean los errores.

El circuito completo, de punta a punta

Todo vive en n8n, instalado en un servidor propio. Cada despacho tiene su propio flujo, copiado de una plantilla, con sus propias credenciales de Notion y su propio bot de Telegram. Elegimos un flujo por despacho y no un flujo único para todos porque un error en uno no arrastra a los demás y porque los datos de cada abogado no se mezclan en ningún punto. El precio de esa decisión aparece más abajo.

1. Entrada. El cliente llena un formulario (puede ser Tally o el formulario de la página del despacho). El formulario manda los datos a un webhook de n8n, que es una dirección web que arranca el flujo cuando recibe algo.
2. Traducción. Cada herramienta de formularios manda los datos con su propio formato. Un nodo de código los convierte a un formato plano y único: cliente, contraparte, materia, tipo de asunto, relato, monto, correo, teléfono y fecha límite.
3. Barandilla. Un segundo nodo descarta lo que no debe entrar: envíos de robots, el mismo caso repetido y ráfagas anormales. Lo descartado no llega a Notion ni dispara avisos.
4. Nota de la IA. Un modelo de lenguaje lee el relato y devuelve tres secciones: un análisis preliminar, un plan de hasta cinco pasos y la sugerencia de una plantilla de escrito de una biblioteca de 77.
5. Notion. Se crea el caso en un tablero general y se abre su ficha en el tablero de su materia (civil, penal, laboral, familia y otras, diez en total), con las dos piezas enlazadas entre sí.
6. Avisos. Sale un mensaje por Telegram, un correo y un aviso al celular con lo esencial del caso y el enlace directo a la ficha.

La regla que ordena todo el diseño es una sola: perder la nota de la IA es un inconveniente, perder el caso es un error grave. Por eso cada paso secundario está configurado para que, si falla, el caso siga su camino. Esa regla la escribimos al principio, pero tardamos en aplicarla en todos los nodos. Lo contamos en la sección de errores.

Por qué Notion es la base y Telegram el timbre

Notion hace de expediente: ahí queda el caso con su estado, su prioridad, su próximo vencimiento y las notas. Telegram y el correo hacen de timbre: solo avisan que algo pasó y llevan al expediente. Si un aviso no llega, el caso igual está en Notion.

Una decisión menos obvia: cada despacho crea su propio bot de Telegram. Un bot compartido obligaba a cada abogado a escribirle primero para poder registrarlo, y mezclaba los mensajes de todos en la misma cuenta.

La nota de la IA: qué le pedimos y cómo la limpiamos

El modelo recibe los datos del caso y un pedido muy acotado: un análisis de no más de 200 palabras, un plan de pasos concretos y una sola plantilla sugerida, con su motivo en una frase. Le pedimos de forma explícita que no invente normas, artículos ni plazos, y que si hace falta una norma escriba cuál hay que verificar y en qué jurisdicción. La nota se presenta como un borrador de apertura para que lo revise el abogado, no como un dictamen.

Lo que vuelve del modelo pasa por un nodo de código antes de llegar a Notion, y ese nodo existe por tres errores que vimos de verdad:

• Los modelos con razonamiento extendido devuelven primero un bloque de razonamiento y después el texto. Nuestro código leía la primera posición de la respuesta y la nota se perdía en silencio. Ahora busca el primer bloque que sea de texto, esté donde esté.
• El campo de Notion es texto plano. Lo que el modelo escribía con formato de negritas aparecía en la ficha con los asteriscos a la vista. Ahora quitamos ese formato en el código, además de pedirlo en las instrucciones.
• Notion limita cada bloque de texto a 2.000 caracteres. Si la nota era más larga, la escritura fallaba. Ahora la recortamos antes de enviarla, con margen.

Si el modelo falla del todo o devuelve algo que no se puede partir en secciones, el caso entra igual, con los campos de la nota vacíos. El abogado recibe su aviso y su ficha; solo le falta el borrador. También agregamos a las instrucciones una línea contra la inyección de órdenes: el relato del cliente se trata como dato, no como instrucción para el modelo.

Los dos relojes: vencimientos diarios y reporte del domingo

El segundo bloque del flujo no depende de que entre nada. Son dos disparadores por horario. El de vencimientos corre de lunes a viernes a primera hora: lee en Notion los casos abiertos con un próximo vencimiento cercano, los ordena por urgencia y arma un mensaje. El del domingo lee todos los casos abiertos y arma un resumen de la semana.

Los dos se comportan distinto a propósito. El aviso diario se calla cuando no hay nada que avisar: cinco correos por semana diciendo «no tienes nada» entrenan al abogado para ignorar el sexto, que es el que importa. El reporte del domingo, en cambio, sale siempre, aunque diga que no hay casos activos. Es el latido semanal que demuestra que el sistema sigue encendido. Así el diario puede permitirse el silencio.

El sorteo de minutos lo agregamos después, al pensar en muchos despachos a la vez: la API de Notion limita los pedidos por minuto, y si todos los relojes arrancan a las 6:00 en punto, compiten en el mismo instante.

Dos ejemplos de cómo se ve en la práctica

Ejemplo ficticio 1: un caso laboral un martes por la noche

Una persona escribe a las 22:40 desde el formulario de la abogada «Laura Méndez»: la despidieron sin liquidación. Poco después la abogada tiene en Telegram el nombre del cliente, la materia, la fecha límite y el enlace a la ficha. En Notion el caso aparece en el tablero general y en el de laboral, con un análisis preliminar, los pasos sugeridos y una plantilla recomendada para el primer escrito. Esa noche no hace nada: el caso ya está ordenado para la mañana.

Ejemplo ficticio 2: un plazo que vence el jueves

El mismo despacho tiene un caso de familia con vencimiento el jueves. El lunes, el reloj de vencimientos manda un correo con asunto «1 caso vence en los próximos días» y el caso en primera fila. El miércoles el mensaje dice «vence mañana», en otro color. Si el jueves pasa sin cambios en la ficha, el viernes el asunto empieza con «caso VENCIDO», y ese caso aparece arriba de todo. La lógica es simple: los vencidos primero, después lo que vence hoy, mañana y el resto en orden.

Lo que falló y cómo lo arreglamos

Ninguno de estos errores era exótico; casi todos eran de los que no dan señal hasta que alguien pierde algo.

Los avisos de Telegram que no llegaban

En la auditoría del 6 de octubre encontramos que algunos mensajes de Telegram de uno de nuestros flujos se perdían. La causa era el formato. El mensaje usaba el modo Markdown de Telegram, donde el guion bajo marca el inicio de una cursiva. Cuando un nombre o un dato traía un guion bajo suelto, Telegram no podía interpretar el mensaje y lo rechazaba entero. La documentación de la API de Telegram lo dice: en ese modo, los guiones bajos, asteriscos, acentos graves y corchetes fuera de una entidad hay que escaparlos.

Pasamos los mensajes al modo HTML, que tiene una regla más corta: los signos menor que, mayor que y el et (&) que no formen parte de una etiqueta se reemplazan por sus entidades HTML. Escapamos esos tres caracteres en cada dato antes de armar el mensaje. Desde entonces, un dato raro ya no puede tumbar el aviso.

Un paso secundario que frenaba el principal

En el flujo que da de alta a quien compra, un paso que crea un registro para pedir una reseña días después estaba en la misma cadena que el correo de bienvenida. Si ese paso fallaba, el flujo se detenía y la bienvenida no salía. Lo cambiamos con la opción de n8n «Continuar (usando la salida de error)»: si el paso secundario falla, el error se desvía por su propia rama y la bienvenida sigue.

En el mismo flujo había otro caso parecido: el aviso de Telegram que nos dice que hay un alta por hacer colgaba de una escritura en la base de datos que era el único nodo de la cadena sin manejo de error. Si esa escritura fallaba, el comprador recibía su correo y nosotros nunca nos enterábamos. Marcar una bandera en la base es contabilidad; el aviso es el trabajo. Ahora la falla de la bandera no frena el aviso.

La bienvenida que salía quince días tarde

Este nos sorprendió. En n8n, con el orden de ejecución actual, cuando un nodo se abre en varias ramas, se completa una rama entera antes de empezar la siguiente, y el orden lo decide la posición en el lienzo: primero la de más arriba. Nuestra rama de reseña, que empieza esperando quince días, estaba dibujada arriba de la rama de bienvenida. Resultado: la bienvenida esperaba a que terminara la espera. El arreglo fue mover la rama de bienvenida arriba. Desde entonces tenemos una regla escrita: no se vuelve a subir la rama de reseña.

Casos duplicados por responder tarde

El webhook respondía al formulario recién al final del flujo, después de la IA y de Notion, más de diez segundos. El formulario interpretaba la demora como un fallo y reenviaba el caso minutos después, y otra vez más tarde. Cada reenvío era un caso nuevo en Notion. n8n permite que el webhook responda de inmediato, sin esperar a que el flujo termine. Lo cambiamos a respuesta inmediata y, además, la barandilla ahora descarta el mismo caso (mismo correo y mismo relato) si se repite en 24 horas.

Una tilde que apagaba la alarma

El nodo que traduce el formato del formulario buscaba los campos por su etiqueta, carácter por carácter. Si el despacho escribía «Fecha limite» sin tilde, el campo llegaba vacío. Y un caso sin fecha límite no genera alertas de vencimiento, sin dar ningún error. Ahora comparamos las etiquetas sin tildes, en minúsculas y sin espacios de más, aceptamos varios nombres razonables por campo y, si falta uno crítico, el aviso de Telegram lo dice: «Revisa tu formulario».

Cómo nos enteramos cuando algo falla

Durante semanas, un error solo se veía si alguien abría la lista de ejecuciones. n8n permite asignar a cada flujo un «flujo de errores», que empieza con el nodo Error Trigger y se ejecuta cuando el flujo principal falla. Armamos uno que nos manda un correo con el nombre del flujo y el nodo que falló, con un máximo de un correo cada 15 minutos por flujo para que una falla repetida no se convierta en cien correos. Se lo pusimos a todos los flujos, y el proceso de alta se lo pone solo a cada despacho nuevo.

Una advertencia honesta: la documentación de n8n dice que el flujo de errores no necesita estar publicado. En nuestra instalación, en la práctica, solo corrió cuando lo dejamos activo. Tampoco se puede probar con una ejecución manual: el Error Trigger solo se dispara cuando falla una ejecución automática. Nosotros lo probamos provocando un error real.

Otra decisión de privacidad: en los flujos de los despachos no guardamos los datos de las ejecuciones que salen bien. Si el caso entró bien, no queda una copia en el servidor de n8n. Las que fallan sí se guardan, porque sin ellas no podríamos diagnosticar nada.

Errores comunes si armas algo parecido

• Dejar que el webhook responda al final del flujo. Si el flujo tarda, el formulario reintenta y te llena la base de duplicados.
• Usar el modo Markdown de Telegram con datos que escribe otra persona. Un guion bajo basta para que el mensaje no salga. HTML con escape es más predecible.
• Encadenar pasos secundarios (reseñas, contadores, banderas) antes del paso que importa sin manejo de error.
• No declarar la zona horaria del flujo.
• Confiar en que una etiqueta de formulario nunca va a cambiar. Alguien le va a quitar o poner una tilde.
• Leer la respuesta de la IA por posición fija. Los formatos de respuesta cambian entre modelos.
• No tener un flujo de errores. La primera falla silenciosa la descubre un cliente, no tú.

Lo que haríamos distinto

Si empezáramos hoy, el flujo de errores sería lo primero que armaríamos, antes del primer caso real. También responderíamos de inmediato en todos los webhooks desde el primer día y usaríamos HTML en Telegram desde el principio. Ninguna de esas tres cosas cuesta trabajo y las tres nos habrían ahorrado sustos.

La decisión de un flujo por despacho la mantenemos, pero tiene un costo que subestimamos: cuando mejoramos la plantilla, cada copia queda desactualizada. Tuvimos que construir una herramienta que aplica los cambios de la plantilla a todos los flujos conservando lo propio de cada uno (sus credenciales, su ruta y su horario). La auditoría encontró copias atrasadas igual. Hoy pensaríamos el mecanismo de actualización junto con la plantilla, no después.

Quedan pendientes anotados: fijar la zona horaria también en la instalación, podar más seguido el historial de ejecuciones y, cuando el volumen crezca, pasar n8n al modo cola, donde una instancia principal recibe los disparadores y varios procesos trabajadores ejecutan los flujos.