Cuándo no automatizar un proceso: la auditoría que evita gastar 20.000€ en algo roto

Entre el 30% y el 50% de los proyectos iniciales de automatización fracasan, y casi siempre por la misma razón: alguien automatizó un proceso que no estaba listo. Este es el checklist que aplicamos en Aoware antes de tocar una línea de código, y los cuatro casos en los que decimos al cliente que pare.

20.000€ en automatizar un proceso que nadie usaba

Hace seis meses un cliente nos pagó casi 20.000€ por automatizar un flujo de aprobación de descuentos. Se ejecutaba cuatro veces al mes. Tres minutos cada vez. Hicimos los cálculos cuando ya estábamos a mitad de proyecto: al ritmo de uso real, el ROI llegaba en el año 2051.

El cliente tenía el presupuesto, el sponsor interno y el caso de uso "claro". Lo que no tenía era volumen. Y nadie en la cadena —ni nosotros al principio, ni su equipo de operaciones, ni el director financiero que firmó— se había sentado una hora a contar veces y minutos antes de aprobar el gasto.

Ese proyecto cambió cómo arrancamos cualquier conversación de automatización. La primera pregunta ya no es "¿qué automatizamos?". Es "¿debemos automatizar esto?". Y muchas veces la respuesta honesta es no.

El dato que nadie quiere mirar: la mitad de los proyectos no llega al primer año

Los números llevan una década siendo malos y nadie del sector los pone en portada. EY estimó hace años que entre el 30% y el 50% de los proyectos iniciales de RPA fallan. Forrester midió que solo el 52% de las empresas consigue pasar de los primeros 10 bots, y que el 45% sufre roturas de bots con frecuencia semanal.

La causa raíz casi nunca es la tecnología. Deloitte la atribuye en buena parte a problemas de gestión del cambio y varianza de proceso. Traducido: el proceso de debajo era inconsistente, raro, o solo lo conocía una persona. Encima de eso, ninguna herramienta aguanta. Es el mismo patrón que aparece cuando el forecast comercial se desvía un 30% trimestre tras trimestre: la herramienta amplifica lo que ya estaba mal definido debajo.

La regla de Bill Gates que el sector finge no conocer

En 1996, Bill Gates escribió una frase que el sector cita poco porque incomoda: "The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency." (Bill Gates, The Road Ahead, 1996).

Treinta años después, el principio es el mismo. Si montas Make, n8n o HubSpot Workflows encima de un proceso caótico, no obtienes orden: obtienes caos a 10x la velocidad y con 10x más superficie de error. Los integradores no suelen decirlo porque cobran por construir, no por desaconsejar. Nosotros también cobramos por construir. Pero hemos visto suficientes proyectos rotos como para saber que decir "esto todavía no" suele ahorrar más dinero del que cuesta una auditoría. Lo mismo aplica cuando llega el momento de decidir entre una automatización a medida y un Zapier o Make estirados al límite: no es la herramienta lo que rompe el proyecto, es el proceso de debajo.

El checklist de Aoware: 5 preguntas antes de tocar una línea de código

Antes de proponer una arquitectura, validamos cinco cosas. Si alguna falla, el proyecto se para o se redimensiona.

1. Volumen: ¿el proceso ocurre al menos 20 veces a la semana?

Por debajo de 20 ejecuciones semanales, casi cualquier automatización tarda más de un año en recuperar la inversión. Y en menos de un año el proceso habrá cambiado.

2. Frecuencia: ¿es regular o errático?

Veinte veces a la semana repartidas de lunes a viernes no es lo mismo que 80 ejecuciones concentradas un día al mes. La frecuencia regular permite detectar fallos pronto. La errática hace que el primer bug se descubra cuando ya hay un atasco.

3. Varianza: ¿el 80% de los casos se hace igual?

Esta es la pregunta que más proyectos tira por tierra. Si cada ejecución tiene "su matiz", el equipo cree que hace lo mismo cuando en realidad hace 14 versiones del mismo proceso. La regla operativa: si no podemos describir un happy path que cubra al menos el 80% de los casos, todavía no es momento de automatizar. Hay que definir antes.

4. Trigger claro: ¿quién o qué dispara el proceso?

"Cuando llega un lead bueno" no es un trigger. "Cuando un contact en HubSpot pasa a lifecyclestage = sales-qualified y country = ES" sí lo es. Si no podemos escribir el trigger como condición lógica, el proceso no está listo para automatizarse: está listo para definirse. Un CRM con campos limpios y triggers observables es justo lo que convierte una automatización en un activo y no en un foco de tickets — exactamente lo que tratamos en por qué un CRM limpio es un activo invisible.

5. ROI mínimo: ¿5x en 12 meses?

Pedimos un retorno mínimo de 5x sobre el coste del proyecto en los primeros 12 meses. Ejemplo rápido: si un proceso ocurre 100 veces a la semana, ahorra 10 minutos cada vez y el coste-hora cargado es de 30€, el ahorro anual ronda los 26.000€. Para una automatización de 5.000€, es 5,2x. Sigue. Si el mismo cálculo da 1,5x, es mejor invertir esos 5.000€ en otra cosa.

Los 4 casos en los que decimos no

No son hipotéticos. Son los cuatro patrones que hemos visto fallar más veces.

Caso 1: el proceso vive en la cabeza de una sola persona

Hay un comercial sénior que cualifica leads "de oídas", o una responsable de operaciones que decide qué pedido va por la vía urgente según un criterio que no ha escrito nadie. Automatizar eso es automatizar a una persona, no a un proceso. Y cuando esa persona se va o cambia el criterio, la automatización se cae.

Qué hacer en su lugar: documentar el criterio durante dos semanas, hasta que la propia persona pueda explicarlo en una página. Después automatizar.

Caso 2: la varianza del proceso supera el 40%

Cuando más del 40% de los casos no encaja en el happy path, lo que llamamos "automatización" termina siendo un árbol de excepciones más largo que el proceso original. Mantenerlo cuesta más que hacerlo a mano.

Qué hacer en su lugar: sentarse con el equipo, revisar los últimos 50 casos reales, y forzar una decisión: ¿cuáles son excepciones legítimas y cuáles son simplemente desorden? Reducir la varianza primero.

Caso 3: el trigger es ambiguo

"Cuando el cliente parece interesado." "Cuando el deal está avanzado." Si el trigger depende del juicio humano y nadie ha traducido ese juicio a una condición observable en HubSpot, Salesforce o Pipedrive, no hay nada que disparar.

Qué hacer en su lugar: definir el trigger en términos de campos, etapas o eventos concretos. Probarlo manualmente una semana. Si el equipo está de acuerdo en que el trigger funciona, entonces automatizar.

Caso 4: el volumen no aguanta el coste

Volvemos al caso del flujo de descuentos: cuatro veces al mes, tres minutos cada vez. 144 minutos al año. Ninguna automatización de casi 20.000€ se justifica con 2,4 horas anuales ahorradas.

Qué hacer en su lugar: dejar el proceso manual y, si molesta, mejorar la plantilla o el formulario que lo soporta. A veces la respuesta correcta es un Google Form bien hecho, no un workflow.

Qué hacemos en la auditoría de una semana

La auditoría es un sprint corto, con coste fijo y entregable concreto. No es una propuesta comercial disfrazada.

• Día 1–2: shadow y entrevistas. Nos sentamos con las personas que ejecutan el proceso. Lo vemos en vivo. Hacemos las cinco preguntas del checklist con datos reales delante, no con suposiciones.
• Día 3: medición. Contamos volumen, tiempo por ejecución, varianza y puntos de fallo. Salimos con números, no con impresiones.
• Día 4: ROI por escenario. Modelamos al menos dos opciones: automatización completa con la herramienta más cara, automatización parcial con HubSpot Workflows, Make o n8n, y "no automatizar, arreglar el proceso primero". Cada escenario con su número.
• Día 5: entregable. Un documento de 8–12 páginas con diagnóstico, recomendación, coste estimado y, si aplica, plan de implementación.

El documento se lo lleva el cliente, lo use con nosotros o no. Esa es la parte que cambia la conversación: no estás comprando una propuesta, estás comprando criterio.

El impacto: clientes que ahorran los primeros 20.000€ antes de gastarlos

Estos son dos patrones que vemos repetirse cuando la auditoría llega antes que el contrato de implementación.

Patrón 1: la empresa que quiere automatizar el alta en varios sistemas. Al medir, descubre que dos de esos sistemas llevan meses con datos contradictorios y que el equipo los arregla a mano antes de cada alta. La recomendación: arreglar la sincronización primero, automatizar después. Coste evitado: una integración que habría amplificado el desorden y seguido sumando tickets de soporte cada semana.

Patrón 2: la empresa que quiere un agente de IA para cualificar leads entrantes. Al medir el volumen real, el ROI a 12 meses no llega ni a 1,5x. La recomendación: no automatizar todavía, redistribuir el trabajo entre el equipo comercial existente y revisar la conversación cuando el volumen se duplique. Coste evitado: un agente que se habría mantenido infrautilizado y con coste fijo mensual.

Lo que estos dos casos tienen en común no es que se hayan ahorrado dinero. Es que la siguiente vez que tienen un proceso que automatizar de verdad, nos llaman a nosotros. Decir que no en el momento adecuado vende mejor que prometer automatizarlo todo.

Qué hacer ahora

Antes de pedir una propuesta de automatización —a nosotros o a cualquiera—, pásale a tu proceso estas cinco preguntas:

1. ¿Ocurre al menos 20 veces a la semana?
2. ¿Tiene una frecuencia regular?
3. ¿El 80% de los casos se hace exactamente igual?
4. ¿Puedo escribir el trigger como una condición lógica observable en mi CRM?
5. ¿El retorno estimado es al menos 5x el coste en 12 meses?

Si has respondido que sí a las cinco, el proceso está listo y conviene automatizarlo cuanto antes. Si has respondido que no a una o más, automatizar ahora es comprar deuda operativa.

Antes de automatizar nada, hacemos una auditoría de proceso de una semana. Si el proceso no está listo, te lo decimos y te explicamos qué arreglar primero. Escríbenos y empezamos por ahí.