Make o Zapier: cuándo un filtro cambia el coste

Para elegir entre Make y Zapier, importa tanto cuántos registros llegan como qué pasos atraviesan antes de ser descartados. La guía de Make indica que el primer módulo consume una operación por ejecución, que la mayoría de las operaciones usa un crédito y que filtros y routers no generan operaciones. También fija en 1.000 créditos mensuales el cupo gratuito. La medición de tareas de Zapier excluye los disparadores, sus sondeos, Filter, Paths y Formatter; cuenta las acciones completadas correctamente.

Por eso, un filtro temprano puede cambiar mucho el consumo de un flujo de Make si evita que un módulo procese cientos de registros. En Zapier también detiene las acciones posteriores, aunque el propio filtro no gaste tareas. La elección exige mirar además el plan: la tabla de planes de Zapier ofrece Zaps de dos pasos en el plan gratuito y reserva los flujos de varios pasos para planes superiores. Un crédito y una tarea tampoco tienen el mismo precio.

Qué cuenta cada plataforma antes de guardar un registro

En un escenario programado de Make, el módulo inicial se ejecuta cada vez que toca comprobar la aplicación de origen. Puede entregar varios registros en esa ejecución, pero los módulos siguientes realizan una operación por cada registro que procesan. Si una comprobación no encuentra novedades, el primer módulo ya se ha ejecutado; si encuentra muchos registros juntos, su coste inicial se reparte entre todos ellos.

La posición del filtro determina qué módulos posteriores llegan a trabajar. Si el dato necesario para decidir ya viene en el disparador, Make puede descartar un registro sin añadir una operación de filtro. En cambio, una transformación hecha mediante otro módulo antes de esa condición se ejecutará también para los registros que finalmente se rechacen. Un router permite separar recorridos sin sumar operaciones por la bifurcación; las acciones de cada rama sí cuentan cuando se ejecutan.

Zapier parte de otra base: el sondeo del disparador no consume tareas y una condición que detiene el Zap impide que se ejecuten las acciones siguientes. Formatter puede preparar datos sin gastar tareas. Esa ventaja contable tiene un límite práctico: si para decidir hay que consultar otra aplicación mediante una acción de búsqueda, su consumo depende de la configuración de esa búsqueda. La comparación debe incluir las consultas reales, no solo el filtro visible.

Flujo simple: detectar y guardar

Tomemos un ejemplo hipotético sin IA: una comprobación encuentra un cliente potencial y el flujo lo guarda en un CRM. Con un disparador programado ordinario y un módulo de escritura, Make emplearía un crédito en la comprobación y otro en la escritura: dos créditos. Zapier no cobraría una tarea por el disparador; la escritura completada usaría una tarea. El recorrido cabe en un Zap de dos pasos.

La relación cambia si una sola comprobación de Make entrega cien registros y cada uno requiere una escritura. Bajo los mismos supuestos, Make usaría un crédito inicial y cien para guardar, es decir, 101 créditos; Zapier usaría cien tareas por las escrituras completadas. Ese cálculo mide consumo, no dinero. Para convertirlo en coste hay que considerar el cupo incluido, el precio del plan y si la aplicación que actúa como disparador entrega los registros juntos o de uno en uno.

Flujo ramificado: la transformación marca la diferencia

Supongamos ahora diez clientes potenciales recibidos en una comprobación. Hay que normalizar un campo y repartirlos entre dos rutas: seis necesitan dos acciones finales cada uno y cuatro necesitan una. El resultado funcional suma dieciséis acciones. Si Make normaliza los diez registros con un módulo antes del router, la cuenta hipotética es un crédito por la comprobación, diez por la transformación y dieciséis por las acciones: 27 créditos.

En Zapier, si la normalización equivalente se puede hacer con Formatter, ese paso y Paths no añaden tareas. Las dieciséis acciones finales completadas consumirían dieciséis tareas. La diferencia procede de ejecutar una transformación facturable en Make y una interna sin tareas en Zapier, no de que una plataforma tenga ramas y la otra carezca de ellas. El flujo de Zapier requiere además acceso a varios pasos, una condición distinta del número de tareas consumidas.

Si el campo ya llega normalizado, desaparecen las diez operaciones de transformación del ejemplo: Make baja a diecisiete créditos y Zapier permanece en dieciséis tareas. Si alguna rama necesita buscar información externa antes de actuar, habrá que añadir esa consulta al recorrido correspondiente. Colocarla antes de la bifurcación hace que alcance a todos los registros; situarla solo en la rama que la necesita limita sus ejecuciones.

Quinientos descartes: el orden puede cambiar el plan

Consideremos un tercer ejemplo hipotético, con 500 registros recibidos de uno en uno en 500 comprobaciones programadas. La condición de aceptación ya está en los datos de entrada: 480 registros se descartan y veinte se guardan. Con el filtro inmediatamente después del disparador, Make emplearía 500 créditos en comprobaciones y veinte en escrituras, un total de 520. Zapier consumiría veinte tareas por las escrituras; sus sondeos y los registros detenidos no añadirían tareas.

Si Make transforma primero todos los registros mediante un módulo y filtra después, suma 500 operaciones de transformación. El total pasa a 1.020 créditos. Adelantar el filtro evita las 480 transformaciones innecesarias: en este supuesto, la diferencia sitúa el flujo a un lado u otro del cupo gratuito de Make. Zapier mantendría veinte tareas si la transformación equivalente pudiera resolverse con Formatter, pero el filtro y la escritura forman un Zap de varios pasos, sujeto al plan que permita publicarlo.

La frecuencia de llegada puede pesar tanto como el orden. Si esos mismos 500 registros llegan en una sola comprobación de Make y solo veinte pasan directamente a la escritura, el cálculo sería de 21 créditos: uno inicial y veinte escrituras. Esta variante presupone que el disparador entrega todos los registros y el campo de aceptación sin consultas adicionales. Un módulo que deba buscar ese campo para cada registro rechazado volvería a cambiar la cuenta.

Cuando entra la IA, cambia la unidad relevante

Una clasificación con IA antes del filtro procesaría todos los registros del ejemplo; después del filtro, solo los aceptados. La documentación de créditos de Make distingue los módulos conectados a un proveedor externo, que suelen gastar un crédito por operación más el coste de tokens cobrado por el proveedor, de funciones propias cuyo consumo puede depender de operaciones, tokens y otros factores. Por ello no hay una cantidad fija de créditos que sirva para cualquier paso de IA.

Las tarifas de AI by Zapier asignan, para una ejecución sin herramientas, una tarea al nivel Standard, tres a Advanced y cinco a Premium; cada llamada a una herramienta añade consumo con el multiplicador del nivel elegido. Si la clasificación se aplica solo a los veinte registros aceptados, serían veinte, sesenta o cien tareas de IA, además de las veinte escrituras. Premium es el nivel predeterminado para pasos nuevos en planes de pago, de modo que elegir el modelo también puede alterar la cuenta.

Qué decisión deja cada recorrido

Un flujo lineal con pocas acciones permite comparar Make y Zapier por facilidad de configuración y coste completo del plan; la pequeña diferencia entre créditos y tareas del primer ejemplo no establece por sí sola cuál saldrá más barato. En un flujo con muchas comprobaciones y pocos registros útiles, Zapier evita tareas por el sondeo, mientras Make puede aprovechar llegadas agrupadas. En uno ramificado, el coste depende sobre todo de las transformaciones y consultas que se ejecutan antes de decidir cada ruta.

El caso de los descartes muestra el efecto más concreto del filtro temprano: puede impedir que Make cruce su cupo mensual al evitar operaciones sobre datos que no llegarán al CRM. Para valorar la factura entre plataformas sigue siendo necesario incluir el plan que admite la estructura del flujo, las acciones externas y el modelo de IA elegido. Las unidades facturables revelan dónde se consume el presupuesto; el precio del plan determina cuánto cuesta ese consumo.