Ejercicios resueltos de Make y Zapier

Question 1

Un escenario en Make revisa un buzón de correo cada 15 minutos: Watch Emails (1 operación) → Router → la rama que corresponda (2 módulos) → Google Sheets (1 módulo). Llegan unos 300 correos al mes y el plan trae 10.000 operaciones. ¿Alcanza? ¿Y si se programa cada minuto?

Accepted Answer

Primero se cuentan las corridas, no los correos. Cada 15 minutos son 4 corridas por hora: 4 × 24 × 30 = 2.880 corridas al mes. El punto que decide el ejercicio: un disparador de sondeo consume 1 operación cada vez que pregunta, haya correo nuevo o no. Entonces esas 2.880 corridas ya cuestan 2.880 operaciones, aunque el buzón esté vacío todo el mes. Ahora las corridas con trabajo. El Router no consume operaciones (solo decide por dónde seguir), así que cada correo procesado suma 2 módulos de la rama + 1 de Google Sheets = 3 operaciones adicionales. Por los 300 correos: 300 × 3 = 900 operaciones. Total del mes: 2.880 + 900 = 3.780 operaciones. Con un plan de 10.000, alcanza de sobra. Cada minuto: 60 × 24 × 30 = 43.200 corridas, más las mismas 900 de procesamiento = 44.100 operaciones. No alcanza ni con cuatro veces el plan, y lo grave es en qué se gastan: 43.200 operaciones son puras preguntas al buzón, no trabajo hecho. La conclusión de diseño es cambiar el modo de disparo. Si el servicio ofrece webhook (disparador instantáneo), se pasa a eso: cuesta 1 operación cuando de verdad llega algo y cero mientras no pasa nada. Además llega al instante, no hasta 15 minutos después. Respuesta: Cada 15 minutos: 3.780 operaciones al mes, sí alcanza. Cada minuto: 44.100 operaciones, no alcanza. Lo que consume el plan es la frecuencia del sondeo, no el volumen de correos.

Question 2

Un Zap hace: nueva respuesta de Google Forms → crear cliente en el CRM → enviar correo de bienvenida. A veces el cliente queda creado dos veces y a veces sale el correo de bienvenida aunque el CRM haya fallado. Arréglalo.

Accepted Answer

Los dos síntomas vienen de la misma raíz: el Zap ejecuta acciones que no son idempotentes y encadena pasos que no verifican el resultado del anterior. Se arreglan por separado. El duplicado sale de la palabra «crear». Si hay un reintento por error de red, o si la respuesta del formulario se vuelve a disparar, la acción «crear cliente» crea otro cliente: es su trabajo. Se reemplaza por la acción de búsqueda con creación condicional (Find Customer, marcando «create if it doesn't exist») usando el correo como clave única. Así, correr el Zap dos veces deja un solo cliente. El correo enviado sin cliente sale de suponer que el paso anterior funcionó. Se mete un paso Filter entre el CRM y el correo, con la condición «el id del cliente existe». Si el CRM no devolvió id, el Zap se detiene ahí y no manda nada. Se revisa el disparador. Zapier no repite una misma respuesta de formulario, pero si el origen es una hoja de cálculo sí vuelve a disparar cuando alguien edita la fila; en ese caso se agrega una columna «procesado» y un filtro que solo deje pasar las filas vacías en esa columna. Y se cierra el ciclo de operación: activar las notificaciones de error del Zap y revisar el Zap History cada tanto. Zapier apaga un Zap que falla repetidamente, y si nadie está mirando, la empresa descubre a la semana que no se creó ningún cliente. Respuesta: Reemplazar «crear cliente» por «buscar o crear» con el correo como clave única, poner un Filter que exija el id del CRM antes de enviar el correo, controlar el disparador para que no se repita, y activar las alertas de error.

Make y Zapier