Qué es Make (antes Integromat) y para qué sirve en una empresa

El dolor no es “no tenemos automatizaciones”, es el trabajo pegamento que nadie contabiliza

En casi toda empresa mediana hay tareas que existen solo porque los sistemas no se hablan entre ellos. Alguien exporta el reporte del CRM y lo sube a una hoja compartida. Otro revisa el correo de contacto y crea el ticket a mano. Administración copia los datos del formulario web al ERP. Ninguna aparece en un organigrama ni en un KPI, pero todas consumen horas de gente contratada para pensar, no para transcribir.

Es un costo invisible hasta que alguien lo mide, porque cada persona cree que su parte es pequeña: quince minutos acá, media hora allá. Sumado en el mes y multiplicado por el equipo, suele equivaler a una plaza completa. Y cuando gerencia decide atacarlo, la conversación arranca por la herramienta y no por el proceso. Los proyectos de automatización que veo fracasar no fracasan por la plataforma: fracasan porque nadie mapeó el proceso antes de conectarlo.

Qué es Make de verdad, sin el discurso de la página de ventas

Make es una plataforma visual de automatización que conecta aplicaciones de negocio y encadena acciones entre ellas sin escribir código. Nació como Integromat, con fama de ser la más potente y la más difícil de su categoría, y en 2022 cambió de nombre junto con un rediseño completo. Ese cambio confunde a quien busca documentación vieja: Integromat y Make son la misma plataforma.

Su vocabulario es corto y conviene entenderlo, porque toda decisión de costo depende de él. Un escenario es un flujo de trabajo completo. Un módulo es cada paso, y pertenece a una aplicación conectada: leer un correo, crear una fila en una hoja, actualizar un contacto en el CRM. Un disparador es el módulo inicial que decide cuándo corre el escenario. Lo que diferencia a Make es que el lienzo es de verdad visual: puedes abrir cualquier ejecución pasada e inspeccionar qué entró y qué salió en cada paso. Esa trazabilidad es su ventaja real.

Para qué tipo de proceso rinde de verdad

Make rinde cuando el proceso es determinista, tiene volumen medio y cruza varias herramientas: las reglas se escriben sin ambigüedad, el trabajo se repite lo suficiente para justificar el esfuerzo, y el valor está en que tres o cuatro sistemas se sincronicen solos. Ahí una empresa recupera horas reales sin abrir un proyecto de desarrollo.

• Captura y ruteo de leads: entra el formulario web, se crea el registro en el CRM, se asigna al vendedor por territorio y se notifica al equipo. En manual, ese proceso pierde leads por olvido todas las semanas.
• Sincronización entre sistemas sin integración nativa: mantener alineados el ERP, la facturación y la hoja que mira gerencia, sin que nadie exporte a mano.
• Procesamiento de documentos entrantes: leer el correo, extraer el adjunto, pasarlo por un modelo que saca los campos clave y crear la tarea de revisión.
• Alertas operativas: avisar cuando una orden lleva días sin moverse o cuando un ticket supera el SLA, sin depender de que alguien revise una pantalla.
• Reportería recurrente: armar el reporte semanal juntando varias fuentes, en lugar de que un analista dedique el lunes a copiar y pegar.

El modelo de consumo por operaciones y por qué sorprende en la factura

Acá está la parte que casi ningún tutorial explica y que después aparece en la factura. Make no cobra por usuario ni por tiempo de uso: cobra por operación, lo que hoy la plataforma llama crédito. Cada acción de cada módulo consume una unidad. Si tu escenario tiene ocho módulos y corre quinientas veces al día, son cuatro mil operaciones diarias. El precio del plan es lo de menos: lo que define tu factura es el producto entre cantidad de pasos y frecuencia de ejecución.

El efecto es contraintuitivo para quien viene de comprar software por licencia: en Make, mejorar un escenario suele encarecerlo. Agregas un paso de validación, sumas un módulo de registro, metes un filtro con una consulta extra, y cada mejora que hace el flujo más confiable también lo hace más caro por ejecución. He visto equipos optimizar al revés, quitando controles para ahorrar operaciones, y quedarse con automatizaciones frágiles que fallan en silencio.

La consecuencia de negocio es que el costo escala con el volumen de la operación, no con el valor que genera. Mientras la empresa es chica no se nota. Cuando crece, el gasto crece en la misma proporción, y llega un punto donde pagas cada mes por algo que en un desarrollo propio sería costo fijo. No es un defecto oculto, es su modelo de negocio explícito. El error es no proyectarlo antes de amarrarle procesos críticos.

Qué NO es Make y qué problema no te va a resolver

Make automatiza tareas, no rediseña procesos. Esa distinción parece semántica y es la diferencia entre un proyecto que devuelve horas y uno que solo mueve el desorden de lugar. Si el proceso de fondo tiene pasos que no deberían existir o datos que se capturan tres veces, Make ejecuta esa ineficiencia con obediencia perfecta y a mayor velocidad.

• No es un sistema. Un conjunto de escenarios sueltos no es una arquitectura. Sin datos ordenados, sin reglas escritas y sin dueño, tienes parches que un día se contradicen entre sí.
• No arregla datos sucios. Si el mismo cliente está cargado cuatro veces con nombres distintos, la automatización propaga esas cuatro versiones a todos los sistemas conectados.
• No es gobierno ni control. Quién puede crear escenarios, con qué credenciales y qué pasa cuando la persona que los armó renuncia lo define la empresa, no la herramienta.
• No reemplaza un backend. Cuando el flujo necesita transacciones o lógica con estado, estás usando una herramienta de integración para el trabajo de una aplicación.
• No es inteligencia por sí sola. Puede llamar a un modelo como un paso más, pero decidir qué contexto recibe y cómo se valida su salida sigue siendo diseño de arquitectura.

El techo honesto: qué pasa cuando el escenario se vuelve complejo

Esta es la parte que las páginas de producto no cuentan y que veo repetirse en empresas reales. Los primeros escenarios se arman rápido y funcionan bien. A los seis meses hay treinta, algunos con veinte o más módulos, rutas condicionales anidadas y variables que dependen de otro escenario que armó alguien que ya no trabaja ahí. En ese punto dejaste de configurar una herramienta: estás programando en un lenguaje visual.

Lo que se rompe al cruzar ese umbral es concreto: no hay control de versiones real, así que nadie puede ver quién cambió qué ni volver atrás con confianza; probar un cambio significa dispararlo sobre datos reales; y la lógica queda repartida entre docenas de campos que nadie puede leer completos de un vistazo. Ahí la automatización deja de ser un activo y pasa a ser riesgo operativo. Si quieres ver cómo se compara ese techo con el de una plataforma que corres en tu propia infraestructura, esa conversación está en la comparativa de Make frente a n8n.

Cuándo conviene Make y cuándo conviene otra cosa

La decisión no se toma comparando listas de funciones. Se toma respondiendo tres preguntas del negocio: qué volumen vas a mover, quién va a mantener esto en un año, y qué exige tu área legal sobre dónde viven los datos.

Señales de que Make es la elección correcta

• Necesitas resultados en semanas y quien va a construirlo no es un equipo de desarrollo.
• Los procesos cruzan muchas herramientas de nube y el valor está en las integraciones ya listas.
• El volumen es medio y predecible, y ya hiciste el cálculo de operaciones de un mes pico.
• Quieres validar si vale la pena automatizar un proceso antes de invertir en construirlo bien.

Señales de que necesitas otra cosa

• El volumen es alto y creciente, y la proyección de operaciones supera lo que costaría un desarrollo con costo fijo.
• Compliance exige control sobre la infraestructura donde se procesan los datos.
• La lógica de negocio es central para tu producto: lo que te diferencia no se terceriza a una capa de integración.
• El proceso necesita garantías de transaccionalidad que una herramienta de integración no está diseñada para dar.

Cómo medir si la automatización en Make sirvió de algo

La métrica que casi todos usan es la cantidad de escenarios activos, y es exactamente la equivocada. Treinta escenarios corriendo pueden significar treinta procesos resueltos o treinta parches que nadie revisa. Lo que importa es si la operación cambió, y eso se mide con números que ya existían antes de la herramienta.

• Horas devueltas por proceso: cuánto tomaba la tarea manual y cuánto toma ahora, medido con el equipo que la hacía.
• Tasa de ejecuciones fallidas: qué porcentaje termina en error y cuánto tarda alguien en enterarse cuando eso pasa.
• Costo por proceso automatizado: operaciones consumidas al mes por escenario, traducidas a dinero, contra el costo de la tarea manual que reemplazó.
• Errores de datos posteriores: si subieron los registros duplicados o inconsistentes, estás propagando un problema de fondo más rápido.
• Tiempo de ciclo de punta a punta: si el lead llega al CRM en dos segundos pero el vendedor llama al día siguiente, el cuello de botella nunca fue la integración.

Si a los tres meses ninguno de esos números se movió, el problema rara vez es Make. Es que se automatizó un proceso que no valía la pena, o que estaba mal diseñado desde antes. La pregunta de qué proceso merece ser automatizado sigue siendo tuya, y ninguna plataforma la responde por ti.