La pregunta que más recibimos al arrancar un proyecto no es "¿se puede automatizar X?". Es "¿por dónde empiezo?". Cualquier empresa con más de diez personas tiene decenas de procesos candidatos, y el costo real no es técnico: es el costo de oportunidad de elegir mal. Un proyecto chico y bien elegido genera confianza interna y libera horas reales. Uno grande y mal elegido quema presupuesto, frustra al equipo y deja la automatización con mala fama por años.
Este post explica el framework de cuatro preguntas que usamos con todos nuestros clientes para priorizar. Es lo primero que hacemos antes de tocar n8n o abrir un editor.
Por qué "lo más doloroso" casi siempre es la respuesta equivocada
La intuición natural es empezar por el proceso que más duele. Si el equipo de finanzas se queja del cierre de mes, automatizá el cierre de mes. Si atención al cliente está desbordado, metele IA a atención al cliente. Suena razonable y es casi siempre una mala decisión.
El problema es que los procesos más dolorosos suelen ser los más caóticos. Muchas excepciones, inputs inconsistentes, criterios que cambian cada semana. Son los peores candidatos para automatizar primero, no porque sean imposibles, sino porque requieren haber resuelto antes el problema organizacional que los hace caóticos. Si automatizás sobre caos, lo único que lográs es automatizar el caos a mayor velocidad.
Los buenos primeros candidatos son procesos aburridos. Repetitivos, bien definidos, con entradas razonablemente estructuradas. Nadie se queja de ellos porque ya los internalizó como "así es el trabajo". Son justamente los que tienen ROI más claro y menos riesgo.
Las 4 preguntas
Para cada proceso candidato, respondé estas cuatro preguntas antes de hacer cualquier otra cosa. Las respuestas no tienen que ser exactas; una estimación razonable alcanza.
1. ¿Cuántas veces por mes se ejecuta?
Es la pregunta más simple y la más importante. Un proceso que corre 2 veces al mes y toma 4 horas tiene un techo de 8 horas mensuales que podés recuperar. Un proceso que corre 500 veces al mes y toma 5 minutos tiene un techo de más de 40 horas. Aunque el primero suene más "dramático", el segundo casi siempre tiene mejor ROI.
Nuestra regla: procesos con menos de 20 ejecuciones mensuales rara vez justifican automatización custom. La excepción son los procesos de alta criticidad donde automatizar reduce riesgo, no tiempo.
2. ¿Cuánto tiempo humano consume cada ejecución?
Multiplicá por la respuesta anterior y tenés las horas mensuales que está consumiendo el proceso. Es la base del cálculo de ROI. Pero hay un matiz importante: no todas las horas valen lo mismo. Cinco minutos robados al director financiero cuestan mucho más que cinco minutos robados a un administrativo junior, aunque el calendario no los distinga.
Cuando hacemos este cálculo, ponderamos por costo por hora del rol involucrado. Un proceso que consume 10 horas mensuales de un gerente medio puede ser más prioritario que otro que consume 30 horas de alguien al que se le paga un cuarto.
3. ¿Qué tan estructurada es la entrada?
Esta pregunta determina la viabilidad técnica. Un proceso cuya entrada es siempre el mismo tipo de archivo, con los mismos campos, llegando por el mismo canal, es casi trivial de automatizar. Un proceso cuya entrada son correos libres de clientes pidiendo cosas distintas cada vez es un proyecto de IA, no una automatización de reglas, y tiene un costo distinto.
Lo importante acá no es descartar los procesos no estructurados: son justamente donde los LLMs aportan más valor. Lo importante es saber en qué categoría cae cada uno antes de estimar costo. Automatizar con IA un proceso desestructurado puede costar 3 a 5 veces más que automatizar con reglas un proceso estructurado, y tener mantenimiento más caro.
4. ¿Cuál es el costo de un error?
La última pregunta, y la más ignorada. Automatizar implica que alguna vez el sistema va a hacer algo mal, sea por un bug, por un input raro o por un cambio de la API upstream. La pregunta es: si el proceso produce un output incorrecto, ¿cuánto cuesta repararlo?
Un workflow que genera borradores de mail para revisión humana tiene costo de error casi cero: el revisor lo descarta. Un workflow que manda esos mails directamente al cliente tiene un costo de error mucho mayor. Uno que dispara cobros a tarjetas de crédito tiene un costo que puede destruir la confianza del cliente.
Para procesos con costo de error alto, la automatización sigue siendo posible, pero el diseño cambia por completo: más validaciones, revisión humana en el loop, rollback automatizado, alertas tempranas. Esto multiplica el esfuerzo de implementación.
El cálculo implícito
Con estas cuatro respuestas, el ROI aproximado emerge solo. Horas mensuales recuperables (1 × 2), ponderadas por costo del rol, divididas por el esfuerzo de implementación (función de 3 y 4). Si el resultado da "el proyecto se paga solo en menos de 6 meses", es un buen candidato. Si da "se paga en 18 meses", probablemente hay candidatos mejores primero.
No le ponemos fórmulas elegantes porque la estimación es gruesa por diseño. El objetivo es eliminar los candidatos malos rápido, no calcular un número preciso.
Lo que el framework no captura
Hay dos cosas que este framework no mide y que a veces pesan más que el ROI directo.
La primera es el efecto moral. Algunos procesos son tan odiados por quienes los hacen que automatizarlos, aunque el ROI puro sea modesto, mejora retención y clima interno. Hemos visto equipos enteros revivir después de quitarles una tarea repetitiva y frustrante. Eso no aparece en una planilla.
La segunda es el efecto estratégico. Automatizar un proceso puede desbloquear capacidad para algo nuevo que hoy no existe. Si tu equipo de ventas dedica 20 horas semanales a armar propuestas a mano, automatizar eso no solo recupera 20 horas: permite atender un 30% más de leads. Ese crecimiento no es ROI de reducción de costos, es ROI de ingreso, y es mucho más grande.
Cuando uno de estos dos efectos aplica, los candidatos que el framework descartaría vuelven a la mesa.
Un ejemplo real
Un cliente nos pidió automatizar tres cosas: el cierre mensual contable, el reporte semanal a dirección y la clasificación de tickets de soporte. Los tres dolían. Les pasamos el framework.
- Cierre mensual: 1 vez por mes, 8 horas, entrada semi-estructurada, error alto. ROI directo bajo, complejidad alta, riesgo alto. Descartado para v1.
- Reporte semanal: 4 veces por mes, 2 horas, entrada estructurada (queries a Postgres), error bajo. ROI modesto, complejidad baja. Buen candidato pero no el mejor.
- Clasificación de tickets: 300 por mes, 3 minutos cada uno, entrada no estructurada, error bajo (se revisa). 15 horas mensuales recuperables, viable con IA, poco riesgo. El mejor candidato.
Arrancamos por la clasificación de tickets. Tres semanas de trabajo, ahorro real observado desde el primer mes, y el equipo ganó confianza suficiente para encarar el reporte semanal dos meses después. El cierre mensual quedó para v3, cuando ya había infraestructura y el equipo sabía cómo intervenir cuando algo fallara.
El punto
El framework no es especialmente sofisticado. Su valor es forzar la conversación antes de que alguien se enamore de un proyecto puntual. Responder estas cuatro preguntas con números concretos, escritos, cambia radicalmente el orden de prioridades en la mayoría de los casos. Y ese orden es lo que separa un programa de automatización exitoso de una acumulación de proyectos abandonados.