En esta nota
En resumen
- Resuelven bien el patrón "cuando pasa esto, hacé aquello, decidiendo algo en el medio".
- Se rompen en tres lugares: volumen alto, lógica muy ramificada e integraciones inexistentes.
- El riesgo serio no es técnico: es el conjunto de flujos que nadie documentó y nadie se anima a tocar.
- Configurá el aviso de error el día uno. Fallan calladas.
Durante años, automatizar un proceso administrativo requería que alguien programara. Hoy una parte grande de eso se resuelve conectando bloques en una interfaz visual, y agregando un paso donde un modelo de lenguaje toma una decisión o transforma un texto.
Eso cambió quién puede hacerlo: en muchas empresas chicas, la persona que mejor arma estas automatizaciones es la que conoce el proceso, no la que sabe programar. Es una buena noticia con letra chica que conviene leer antes.
Qué resuelven bien
El patrón que estas herramientas manejan con soltura es: cuando pasa esto, hacé aquello, decidiendo algo en el medio.
| Cuando pasa | El sistema hace |
|---|---|
| Entra un formulario del sitio | Clasifica el tipo de consulta, la carga donde corresponde y avisa a quien la tiene que ver |
| Llega una factura por correo | Extrae los datos, los carga en la planilla y archiva el documento |
| Se completa una venta | Crea las tareas de entrega, prepara el correo de bienvenida y agenda el seguimiento |
| Alguien escribe por un canal de mensajes | Responde lo frecuente, toma los datos y deriva lo complejo |
| Se acerca un vencimiento | Arma el recordatorio con los datos del caso y lo envía |
La parte donde entra la IA suele ser una sola: clasificar, extraer datos de un texto libre, o redactar algo a partir de información estructurada. El resto es plomería entre aplicaciones.
Una regla de diseño que ahorra problemas: que el paso de IA haga una sola cosa. Un paso que clasifica, otro que redacta. Cuando un mismo paso hace tres cosas, cuando falla no se sabe cuál falló.
Dónde se rompen
Tres límites bastante predecibles.
1El volumen
Estas plataformas cobran por ejecución. A volumen bajo son baratísimas; a volumen alto el costo puede superar al de hacerlo con código propio. Conviene proyectar el gasto con el volumen de dentro de un año, no con el de hoy.
2La lógica ramificada
Un flujo con cuatro condiciones se lee bien en pantalla. Uno con veinte, no. Llega un punto donde la ventaja visual se convierte en desventaja y nadie puede seguir qué pasa en cada caso.
Cuando un flujo pasa de unas quince cajitas, casi siempre conviene partirlo en varios más chicos con nombres claros, en vez de seguir agregando.
3Lo que no se puede conectar
Si tu sistema de gestión no ofrece una vía de integración, el trabajo se complica. Antes de diseñar el flujo entero, verificá que todas las piezas se puedan conectar: descubrirlo a mitad de camino obliga a rediseñar todo.
El riesgo real: el castillo de naipes
Este problema aparece al año, no al mes, y es el que de verdad importa.
Una persona entusiasta arma quince automatizaciones. Funcionan. Cada una tiene un nombre como "Flujo 3" o "Copia de automatización nueva". Nadie más sabe qué hace cada una. Esa persona cambia de trabajo.
Lo que queda es un conjunto de procesos críticos que nadie entiende y nadie se anima a tocar. Cuando uno falla, la salida práctica termina siendo volver a hacerlo a mano.
Cuatro prácticas lo evitan y cuestan muy poco:
- Nombres descriptivos. "Facturas de proveedores: extraer y cargar" en vez de "Flujo 3".
- Una nota en cada flujo: qué resuelve, quién lo pidió, a quién avisar si falla.
- Dos personas con acceso, como mínimo, y que la segunda haya entrado alguna vez.
- Una lista en un documento con todos los flujos activos y qué proceso cubre cada uno.
Prueba honesta: si la persona que armó las automatizaciones se toma dos semanas de vacaciones y algo falla, ¿alguien más puede arreglarlo? Si la respuesta es no, ya tenés el problema, solo que todavía no se manifestó.
Que no fallen en silencio
Las automatizaciones tienen una característica incómoda: cuando se rompen, no avisan. Se rompe una integración, cambia el formato de un archivo, y el flujo deja de ejecutarse. Todo sigue pareciendo normal hasta que alguien nota que hace tres semanas no llegan los avisos.
Por eso el aviso de error se configura el primer día, no cuando pasa el primer problema. Y dirigido a una persona concreta: los avisos a casillas generales no los lee nadie.
Vale además una revisión mensual de cinco minutos: abrir el historial y ver si hay ejecuciones fallidas acumuladas. Es la tarea de mantenimiento más barata que existe y casi nadie la hace.
Cómo empezar sin complicarse
1Elegí un proceso de tres pasos
No de quince. Algo que pase seguido y cuyo resultado se vea de inmediato.
2Armalo primero sin IA
Solo moviendo información. Verificá que la plomería funcione. Este paso es el que más se saltea y el que más problemas evita: si armás todo junto y falla, no sabés si el problema es la conexión o la decisión.
3Agregá el paso de IA
Cuando el resto ya anda. Una sola tarea para ese paso.
4Dejalo avisando, sin actuar
Dos semanas donde el sistema dice qué haría pero no lo hace. Ahí se ven los casos raros sin costo.
5Soltalo, y solo en lo reversible
Lo irreversible sigue pasando por una persona.
Nos casamos con la lógica, no con la herramienta. Las herramientas cambian cada tres meses; el sistema que pensaste queda.
Seba Chuffer · LAB AI
El resumen
- Resuelven bien mover información entre aplicaciones con una decisión en el medio.
- Se rompen en volumen alto, lógica muy ramificada e integraciones inexistentes.
- Un paso de IA, una sola tarea.
- Documentá desde el primer flujo: nombres claros, nota y dos personas con acceso.
- Configurá el aviso de error el día uno, a una persona concreta.
- Empezá sin IA, agregala cuando la plomería ya funcione.
En el LAB salís con las tuyas andando
Doce semanas en vivo donde armás las automatizaciones de tu propio negocio, con el criterio de diseño puesto desde el principio. No un curso de la herramienta: tus procesos funcionando y documentados.
Conocer el LAB AI ›Preguntas frecuentes
¿Qué se puede automatizar sin programar?
Casi todo lo que consista en mover información entre aplicaciones con alguna decisión en el medio: cuando entra un formulario, clasificarlo y cargarlo donde va; cuando llega una factura, extraer los datos y archivarla; cuando se cierra una venta, crear las tareas y preparar el correo. Son la mayoría de los procesos administrativos de una empresa chica.
¿Cuáles son los límites de estas herramientas?
El volumen alto, donde el precio por ejecución se vuelve caro; la lógica muy ramificada, que se vuelve ilegible en una interfaz visual; y todo lo que necesite una integración que la herramienta no ofrece. Cuando un flujo pasa de unas quince cajitas, conviene revisar el diseño antes que seguir agregando.
¿Qué pasa si la persona que armó las automatizaciones se va?
Es el riesgo principal. Se trata desde el principio con nombres descriptivos en cada flujo, una nota que explique qué resuelve y a quién avisar si falla, y por lo menos otra persona que sepa entrar. Un flujo sin documentar es una caja negra que nadie se anima a tocar.
¿Cómo me entero si una automatización deja de funcionar?
Configurando el aviso de error desde el primer día, dirigido a una persona concreta y no a una casilla general. Las automatizaciones fallan en silencio: se rompe una integración, cambia un formato, y el proceso deja de ejecutarse sin que nadie note nada durante semanas.
Escrito a partir de lo que vemos en las sesiones del LAB AI, el programa en vivo donde cada participante implementa IA en los procesos reales de su negocio.