Cómo evoluciona un sistema de análisis de automatizaciones
Hace ya más de 3 años monté mi primera automatización y fue precisamente un sistema para recoger y evaluar las peticiones de automatización de procesos de mis compañeros, de modo que todo quedara canalizado y además agilizara la toma de requisitos de cada solicitud. La idea eran 3 sencillos pasos: el usuario rellenaba un formulario básico con su petición, cada nueva solicitud se enviaba a un LLM que la evaluaba y me enviaba una propuesta de cómo automatizar ese proceso. Lo cierto es que funcionó pero hoy lo montaría completamente distinto.
A estas alturas de mi carrera tengo claro que con independencia de que tu equipo sea más o menos numeroso, lo cierto es que siempre va a haber tareas que son repetitivas, que no aportan nada a quien las hace pero que son necesarias dentro de la compañía.
A menudo esto se hace más notorio cuando los equipos son pequeños y las tareas se acumulan, porque las que tienen ese caracter repetitivo son percibidas cada día como más “robatiempo” frente a otras en las que sí hay valor añadido.
En este contexto, un equipo con muchas tareas y muchas de ellas sistemáticas, decidimos lanzarnos a automatizar procesos para aligerar la carga en todos los departamentos pero para evitar convertirme en un cuello de botella y poder controlar todos esos nuevos procesos, comencé por crear una herramienta que me ayudara en la primera parte, para recoger las peticiones, evaluarlas y proponer el modo más óptimo de llevar a cabo esa automatización.
Cómo fue la versión inicial
El flujo como se puede ver era bastante sencillo:
Lo primero el Formulario: aprovechando que usábamos Slack como herramienta básica de comunicación, monté un formulario sencillo allí, de modo que todo el mundo tenía siempre disponible el gestor de peticiones; ese formulario almacenaba los envíos en un sheets y a la vez enviaba un webhook al escenario en el que sucedía la “magia”.

Cada vez que se recibía una petición el escenario arrancaba: el sistema miraba la información volcada en el sheets y a partir de ahí, se recorría dos caminos: por un lado, enviaba un mensaje al usuario de que se había recibido correctamente su formulario y por otro, enviaba la información a ChatGPT para que la evaluara, elaborara una propuesta de acción y me devolviera un mensaje a mí con dicha propuesta, para finalmente actualizar el sheets con el análisis inicial. Esta es la foto:

Lo que funcionaba bien:
- Era un sistema completamente automático, sin intervención manual
- El equipo lo tenía disponible siempre y podía usarlo sin fricción
- El modelo LLM era suficiente para el nivel de análisis que se pedía.
Lo que no funcionaba tan bien:
- Google Sheets como base de datos: sé que esto es lo habitual en muchísimas organizaciones y lo entiendo, es de Google, se incluye con el Workspace y es hermano de Excel. ¿A quién no le va a gustar?, sin embargo, siendo realistas, una hoja de cálculo nunca será una base de datos, no tienes trazabilidad real, no puedes moldearla y su capacidad de lanzar avisos complejos pasa por escribir scripts en código e implementarlos.
- No había un sistema de fallback de modo que si alguna petición no se procesaba como debía el escenario se paraba.
- No había panel de control: para ver el estado de todas las solicitudes tenías que ir a la hoja.
Cómo es la versión que tengo funcionando hoy
Hoy tengo una base de datos formal: Airtable; sigo usando sheets en mi día a día pero no como base de datos ni para procesos complejos. A partir de ahí todas las piezas encajan mejor y además me permite ajustarlo a las herramientas de cada organización, si usan Slack puedo mantener el formulario allí y enviar los datos a Airtable; si no, uso un formulario directamente en AT. En ambos casos, una vez que se recibe la petición, se envía directamente desde allí a Make y partir de ahí de nuevo el proceso funciona solo:
- Primero miramos si es una petición nueva o una actualización de información.
- Si es nueva petición, Claude revisa la información y si no hay suficiente detalle solicita más información usuario o genera una propuesta que me envía a mí.
- Si es una respuesta de usuario, analiza la información y genera la propuesta que me envía.
- Actualiza el estado de la solicitud en Airtable.
- En el caso de que alguno de los módulos falle, está configurado para que no se pare el circuito, actualiza el estado de la petición y todo se mantiene funcionando para que el siguiente registro pueda procesarse.
Qué gana cada cambio:
- Airtable frente a Sheets: panel de control real, vistas personalizadas y filtradas, formulario nativo, registro histórico, etc.
- Claude frente a GPT-4o-mini: esto reconozco que es evolución personal y que cada uno tendrá su modelo preferido; en mi caso Claude es me da prompts más ricos, mejor razonamiento técnico, respuestas más estructuradas y específicas para Make.
- Control de errores: aquí sí está implementado el error handler en los módulos críticos para evitar un bloqueo ante posibles fallos puntuales del proceso.


Esta es la foto final del sistema:

Mi conclusión:
Es un sistema mucho más robusto y seguro, está preparado para soportar peticiones de 1 a n usuarios y ahora mismo está funcionando a coste cero incluso el modelo de IA. Por supuesto, se puede llevar más allá pero por ahora es lo que necesito.
Si quieres probarlo, aquí tienes el enlace al formulario: solicitud de automatización y si quieres que te comparta alguno de los blueprints, escríbeme y te lo envío.
¿Qué cambiarías tú de tus primeras automatizaciones a las actuales?
¿Te ha resultado útil? Compártelo: