Qué es un automatizador y por qué el mercado ya no paga igual por serlo

El trabajo funciona, y aun así te regatean la tarifa

Conozco el patrón porque lo vi desde los dos lados de la mesa. Alguien entra a una empresa, monta quince o veinte automatizaciones en tres meses, elimina tareas manuales que llevaban años ahí, y todo el mundo agradece. Seis meses después, cuando toca renovar, aparece la frase: “estamos evaluando alternativas más económicas”. La reacción natural es sentirse subvalorado. La lectura correcta es otra: el cliente no está regateando el resultado, está regateando la actividad, porque la actividad de conectar herramientas ya la cotiza tres personas más a la mitad del precio.

Lo mismo pasa del lado de la empresa. Un gerente me muestra un tablero con cuarenta flujos activos y me dice que el área sigue igual de saturada. Ahí el problema no es que el automatizador trabaje mal. Trabaja bien. El problema es que nadie tomó la decisión previa: qué proceso valía la pena rediseñar y cuál había que eliminar antes de tocarlo. Se compró ejecución cuando lo que faltaba era criterio, y ejecutar rápido sobre un proceso mal pensado solo produce un proceso mal pensado que ahora corre solo.

Esta página es la tesis más incómoda de todo este sitio, y la escribo sin adornos: el trabajo de automatizar se está comoditizando y el trabajo de decidir no. No es una crítica a quien automatiza. Es una advertencia sobre hacia dónde se está moviendo el dinero, y una ruta de salida para quien todavía está a tiempo de moverse con él.

Qué es un automatizador de verdad, sin el marketing del rol

Un automatizador es quien construye flujos que hacen que una tarea repetitiva ocurra sin que una persona la ejecute. Recibe un pedido concreto (“que cuando llegue un formulario se cree el registro en el CRM, se avise por Slack y se envíe el correo de bienvenida”) y lo convierte en un flujo que corre solo. Su herramienta de trabajo suele ser una plataforma de automatización visual, un puñado de integraciones, algo de lógica condicional y, cada vez más, una llamada a un modelo de lenguaje en medio del flujo.

Es un rol legítimo y necesario. Sin alguien que sepa hacer esto, ninguna idea de proceso llega a producción. El problema no está en la habilidad, está en el contrato implícito del rol: el automatizador cobra por hacer lo que le piden, no por decidir qué se debe pedir. Esa frontera parece administrativa y es la que define el techo del ingreso. Quien está del lado de la ejecución compite contra todos los que ejecutan. Quien está del lado de la decisión compite contra muy pocos.

Vale la pena decirlo con precisión porque hay mucha confusión de títulos: alguien que se presenta como “consultor de IA” pero cuya conversación entera con el cliente es sobre qué herramienta usar y cuántos flujos entrega, es un automatizador con otro nombre en la tarjeta. Y alguien que se presenta como automatizador pero que llega a una reunión con un mapa del proceso y una recomendación de no automatizar la mitad de lo que le pidieron, ya dejó de serlo, aunque su tarifa todavía no se haya enterado.

Cómo se ve el trabajo en la operación real

Para no discutir en abstracto, así se ve una semana típica de este rol dentro de una empresa mediana. Reconocerlo importa, porque la ruta de salida empieza por ver con claridad dónde estás parado hoy:

• Recibir pedidos ya formulados como solución: “necesito que esto se automatice”. El pedido llega con la respuesta incluida, y el rol lo toma como especificación en vez de como síntoma.
• Mapear la integración, no el proceso: revisar qué sistemas hay que conectar, si tienen API, qué campos se mapean con qué. El trabajo se hace sobre el diagrama de herramientas, no sobre el diagrama de decisiones del negocio.
• Construir y probar el flujo: disparadores, condiciones, manejo de errores, reintentos. Acá es donde vive la habilidad real y donde un buen automatizador se distingue de uno malo.
• Apagar incendios cuando algo se rompe: la API cambió, el proveedor actualizó un endpoint, alguien renombró una columna. Buena parte del tiempo se va en mantenimiento silencioso que nadie ve ni valora hasta que falla.
• Reportar cantidad: cuántos flujos activos, cuántas ejecuciones al mes, cuántas horas “ahorradas” calculadas con una regla de tres. El reporte habla de actividad porque el rol fue contratado por actividad.

Nada de esto está mal hecho. Todo esto es exactamente lo que se pidió. Y ahí está el punto: un rol que se define por ejecutar bien lo que le piden queda a merced de la calidad de los pedidos que recibe. Si el gerente pide mal, el resultado es malo aunque la implementación sea impecable, y el que carga con la percepción de fracaso suele ser quien implementó.

Por qué el mercado ya no paga igual por conectar herramientas

Tres cosas están pasando al mismo tiempo, y ninguna se va a revertir. Primero, las plataformas de automatización bajaron la barrera de entrada de forma brutal: lo que hace cinco años exigía leer documentación de APIs hoy se arma con plantillas y con un asistente que sugiere el nodo siguiente. Segundo, hay muchísima más gente formada en esto: cada mes salen nuevas cohortes de cursos de automatización, y la oferta creció más rápido que la demanda de esa habilidad específica. Tercero, los modelos de lenguaje se comieron una parte del trabajo de pegamento que antes se hacía a mano.

Cuando la oferta de una habilidad crece y la dificultad de ejecutarla baja, el precio de esa habilidad cae. No es una opinión sobre el rol, es aritmética de mercado. Lo mismo pasó con el diseño de páginas web cuando aparecieron los constructores visuales: el que solo maquetaba perdió tarifa, y el que entendía de conversión y de negocio la subió. La habilidad no desapareció, se movió de ser el producto a ser un insumo del producto.

Del otro lado, lo que sí escasea es el criterio para decidir. Los reportes serios sobre adopción empresarial de IA vienen señalando lo mismo desde hace varios ciclos: el valor no aparece por la cantidad de herramientas implementadas, sino en las organizaciones que rediseñan el flujo de trabajo alrededor de la tecnología en vez de pegarla encima del proceso existente. Rediseñar el flujo es una decisión de negocio, no una tarea de configuración. Y las decisiones de negocio siguen siendo caras porque siguen siendo difíciles.

Lo que un automatizador no es, y lo que su trabajo no resuelve

Acá va la parte que incomoda a las dos partes, al que contrata y al contratado. Es necesaria porque casi todos los proyectos que fracasan lo hacen por confundir estas fronteras desde la primera reunión:

• No es responsable del resultado del negocio, salvo que se lo pongan por escrito. Su compromiso contractual habitual es que el flujo funcione. Si el área no vende más ni ahorra tiempo real, técnicamente cumplió. Esa asimetría es la raíz de la mayoría de las decepciones.
• No arregla un proceso mal diseñado, lo acelera. Automatizar un proceso confuso produce confusión más rápida y más difícil de auditar. La velocidad no corrige la dirección.
• No sustituye el gobierno de datos ni la responsabilidad sobre información sensible. Un flujo que mueve datos de clientes entre cuatro plataformas es una decisión de riesgo que le corresponde a la empresa, no al que lo configuró.
• No decide qué NO se hace. Y esa es, en la práctica, la decisión que más dinero salva. Un catálogo de veinte automatizaciones donde doce no debieron existir cuesta más caro de mantener que el trabajo manual que reemplazó.
• No es lo mismo que construir un sistema. Un conjunto de flujos sueltos, sin memoria compartida, sin datos comunes y sin dueño, no es una arquitectura: es un montón de piezas que se rompen por separado y que nadie sabe apagar cuando el proveedor sube el precio.

Ninguno de estos puntos es un reproche al rol. Son las funciones que el rol nunca incluyó y que alguien en la empresa tiene que asumir. Cuando nadie las asume, el proyecto entero descansa sobre una persona que fue contratada para otra cosa, y el día que esa persona se va, nadie sabe por qué existe la mitad de lo que quedó corriendo.

La ruta concreta: del automatizador al que decide

No es un salto de identidad ni un cambio de título en LinkedIn. Es un cambio en el orden de las preguntas y en la naturaleza del entregable. Se puede hacer desde adentro de un empleo o desde una posición externa, y no exige aprender ninguna tecnología nueva.

1. Cambia la primera pregunta de la reunión

Deja de preguntar “¿qué quieres automatizar?” y empieza a preguntar “¿dónde pierde plata o tiempo tu área, y cómo lo mides hoy?”. La primera pregunta te convierte en proveedor de una lista de pedidos. La segunda te sienta en la conversación donde se decide el presupuesto. Es literalmente la misma reunión, con otro punto de entrada, y cambia por completo cómo te percibe quien firma.

2. Entrega decisiones, no configuraciones

El entregable de más valor no es el flujo funcionando: es el documento corto donde dice qué proceso se rediseña, qué se automatiza, qué se elimina y qué se deja manual a propósito, con la razón de cada caso. Cuando ese documento existe y está firmado, la implementación se vuelve la parte fácil y la conversación de precio deja de ser una subasta.

3. Amárrate a un indicador y defiéndelo

• Elige un solo número del área antes de tocar nada: tiempo de respuesta a un lead, días de cierre contable, costo por ticket atendido, porcentaje de pedidos con error.
• Mide ese número dos o cuatro semanas antes de implementar, aunque sea a mano. Sin línea base no hay conversación posible sobre valor, solo opiniones.
• Comprométete públicamente con moverlo, no con entregar flujos. El compromiso es lo que cambia tu posición en la mesa.
• Aprende a decir que no a los pedidos que no impactan ese número, aunque sean fáciles de hacer y aunque el cliente los pida con entusiasmo.
• Documenta lo que decidiste no hacer y por qué. Ese registro, con el tiempo, es tu mejor argumento de tarifa.

4. Aprende el idioma del área, no otra herramienta

El salto de ingreso más grande que he visto en gente de este perfil no vino de dominar una plataforma nueva. Vino de entender cómo se arma el presupuesto del área con la que trabajan, qué le miden a ese gerente sus jefes y qué lo hace quedar mal en la reunión mensual. Quien puede hablar de eso deja de ser un proveedor de flujos y pasa a ser alguien con quien se planifica el año. Ese es, en el fondo, el trabajo de un Gerente de IA.

Errores que veo repetirse, en quien automatiza y en quien contrata

• Cotizar por cantidad de automatizaciones. Es la forma más rápida de convertirte en commodity: pones tu trabajo en una unidad que cualquiera puede replicar y comparar.
• Medir éxito en horas ahorradas calculadas en una hoja de cálculo. Si esas horas no se convirtieron en más ventas, menos costo o más capacidad atendida, no existieron fuera del reporte.
• Acumular flujos sin dueño. Cada automatización que nadie mantiene es deuda futura. Llega el día en que el equipo le tiene más miedo a tocar el sistema que a hacer la tarea a mano.
• Confundir volumen de trabajo con valor entregado. Estar ocupado todo el mes no es evidencia de nada; en muchos casos es evidencia de que se aceptaron pedidos que no debieron aceptarse.
• Del lado de la empresa: contratar implementación antes de tener diagnóstico. Es comprar la solución antes de definir el problema, y luego culpar a la tecnología del resultado.
• Del lado de la empresa: dejar que el automatizador decida solo qué se automatiza. No es su función ni tiene la información del negocio para hacerlo bien. Si no hay nadie del lado del cliente tomando esa decisión, el proyecto ya empezó a fallar.

Cómo saber si te estás moviendo hacia donde está el valor

Estas son las señales que uso para saber si alguien está saliendo de la zona de comoditización o si solo cambió el título en su perfil. Sirven igual para evaluar a un proveedor externo que para evaluarte a ti mismo si estás en este rol:

• En la última reunión con el cliente o con el área, ¿se habló primero del proceso y del número, o de la herramienta y de la cantidad de flujos?
• ¿Puedes nombrar el indicador de negocio que se movió con tu último trabajo, con su valor antes y después, sin tener que estimarlo?
• ¿Cuántas veces en los últimos tres meses recomendaste no hacer algo que te habrían pagado por hacer? Si la respuesta es cero, todavía estás vendiendo ejecución.
• Cuando te piden cotización, ¿te comparan contra otros por precio unitario, o la conversación es sobre alcance y responsabilidad?
• ¿Tu trabajo sobrevive si tú no estás? Un sistema documentado, con dueño interno asignado, vale más que un experto insustituible, y paradójicamente sube tu tarifa en vez de bajarla.
• ¿Quién responde cuando el resultado no llega? Si la respuesta es “el cliente”, todavía no tienes el rol que quieres.

Si la mayoría de las respuestas te incomodan, es buena señal: significa que estás mirando el problema real y no la excusa cómoda de que el mercado no valora el trabajo técnico. El mercado sí lo valora. Lo que ya no paga como antes es venderlo suelto, sin diagnóstico y sin nadie que responda por el resultado. Esa parte sigue escaseando, y por eso sigue siendo cara.