Make.com: la guida completa in italiano

Make.com non è «un altro Zapier». È una piattaforma di automazione visuale con un modello di esecuzione completamente diverso, un sistema di error handling che devi progettare tu, e una curva di apprendimento che paga. Questa guida copre tutto quello che serve per costruire scenari che reggono in produzione: il modello a consumo, le integrazioni, i pattern collaudati, e la scelta onesta tra Make, n8n e Zapier. Se stai valutando la piattaforma o hai già qualche scenario attivo ma non sei sicuro di starlo usando bene, sei nel posto giusto.

Cos’è Make.com e dove si posiziona nello stack

Make (ex Integromat) è un automation builder visuale basato su scenari. Un scenario è una sequenza di moduli collegati: ogni modulo esegue un’operazione su un’app — legge dati, li trasforma, li scrive da qualche parte. La logica si costruisce trascinando i moduli sulla canvas e collegandoli con percorsi condizionali, iteratori, aggregatori, rotte di errore.

Nello stack di un infobusiness o di un’agenzia, Make di solito vive nel mezzo: riceve dati da un CRM o da un webhook, li elabora, li manda a tre o quattro destinazioni diverse. Non è un CRM, non è un database, non è un tool di email marketing. È il connettivo tra strumenti che non parlano tra loro nativamente.

Make è il connettivo del tuo stack: non sostituisce i tool, decide cosa succede quando uno parla e l’altro non ascolta.

Il vantaggio principale rispetto ad altri builder è la granularità. Puoi mappare esattamente ogni campo, gestire array, usare funzioni di trasformazione inline, costruire rotte parallele. Il prezzo di questa granularità è la complessità: uno scenario Make fatto bene richiede tempo di progettazione, non solo tempo di clic.

Scenari, moduli e operazioni: il modello a consumo prima che ti presenti il conto

Il piano gratuito di Make include 1.000 operazioni al mese. Un’operazione è ogni volta che un modulo esegue qualcosa — non ogni scenario, non ogni run. Questo è il punto che brucia quasi tutti alla prima bolletta.

Esempio concreto: hai uno scenario che si attiva a ogni nuovo lead, aggiorna il contatto su HubSpot, lo aggiunge a una lista Mailchimp e manda un messaggio Slack. Sono tre moduli attivi più il trigger. Ogni run consuma quattro operazioni. Con 500 lead al mese arrivi a 2.000 operazioni — già fuori dal piano gratuito, e siamo su un flusso minimale.

Prima di attivare uno scenario in produzione, calcola le operazioni attese: (numero di run mensili) × (numero di moduli attivi per run). Se usi un iterator su un array di 50 elementi, ogni iterazione è un’operazione separata. Un aggregator che ricompatta quell’array costa un’operazione in più. I moduli Router e i percorsi di errore non costano operazioni da soli, ma i moduli dentro quei percorsi sì.

I piani a pagamento di Make partono da 10.400 operazioni al mese sul Core, con incrementi progressivi. Il piano Teams aggiunge collaboratori e team. Il modello è prevedibile se lo pianifichi prima, opaco se lo scopri a posteriori.

Le integrazioni che rendono Make forte

Make conta oltre 1.500 integrazioni native. Per la maggior parte dei casi d’uso di un infobusiness o un’agenzia, le integrazioni che contano davvero sono meno di venti.

Sul lato CRM: HubSpot, GoHighLevel, Salesforce, Pipedrive. Sul lato pagamenti: Stripe, PayPal, ThriveCart. Sul lato email: Mailchimp, ActiveCampaign, ConvertKit. Sul lato dati: Google Sheets, Airtable, MySQL, PostgreSQL. Sul lato comunicazione: Slack, Telegram, Gmail, Outlook. Sul lato AI: OpenAI, Anthropic, tramite moduli HTTP per le API non ancora native.

Dove Make batte Zapier in modo netto è sui moduli HTTP e JSON. Se un tool non ha un’integrazione nativa, usi il modulo HTTP per fare chiamate API dirette e il modulo JSON per parsare la risposta. Non hai bisogno di aspettare che Make costruisca l’integrazione ufficiale. Questo apre l’80% degli strumenti esistenti, inclusi quelli di nicchia che nessuna piattaforma mainstream coprirà mai.

Gli iterator e gli aggregatori meritano un paragrafo a parte. L’iterator spezza un array in elementi singoli da processare uno a uno. L’aggregator ricompatta elementi separati in un array o in un testo unico. Insieme ti permettono di lavorare su batch di dati — liste di contatti, righe di un foglio, ordini di un giorno — con la stessa logica che useresti su un singolo record. Questa combinazione da sola vale metà della potenza della piattaforma.

Error handling: rotte di errore, retry, e perché il default non basta

Il comportamento default di Make quando un modulo fallisce è interrompere lo scenario e segnalarti l’errore via email. Questo va bene in sviluppo. In produzione è pericoloso.

Un modulo che chiama un’API esterna può fallire per mille motivi che non dipendono da te: timeout, rate limit, risposta malformata, servizio temporaneamente giù. Se lo scenario si ferma, il dato che doveva processare rimane non processato. Se non hai un sistema di monitoraggio attivo, non te ne accorgi finché il problema è già grosso.

Un’automazione senza rotte di errore esegue sbagliato con la stessa sicurezza con cui esegue giusto.

Make ti dà tre strumenti per gestire l’errore a livello di modulo: Retry, Resume e Ignore. Retry ritenta il modulo fallito un numero configurabile di volte con un intervallo. Resume salta il modulo fallito e continua con il bundle successivo. Ignore ignora l’errore e va avanti come se il modulo avesse avuto successo — usalo solo se sai esattamente cosa stai facendo e l’operazione fallita è davvero irrilevante.

Il pattern corretto per gli scenari in produzione è costruire una rotta di errore esplicita su ogni modulo critico. La rotta di errore è un percorso alternativo che si attiva solo quando il modulo fallisce: puoi usarla per loggare il dato su un Google Sheet, mandare un avviso su Slack, o accodare il record in un Data Store per riprocessarlo dopo.

Il Data Store di Make funziona da coda persistente leggera. Quando un’API esterna è giù, scrivi il dato nel Data Store invece di perderlo. Uno scenario separato svuota periodicamente il Data Store e riprova. Non è una soluzione enterprise, ma per la maggior parte dei volumi di un infobusiness regge senza problemi.

Il monitoraggio va costruito fuori da Make. Un webhook in uscita verso un Google Sheet che logga ogni run con timestamp, stato e numero di bundle processati è il minimo. Se una notte uno scenario smette di girare in silenzio, senza log esterni non lo sai finché non guardi manualmente la dashboard.

Make vs n8n vs Zapier: la scelta onesta per caso d’uso

Nessuno dei tre tool vince su tutto. La scelta dipende dal contesto, non dal fatto che uno sia «migliore».

Zapier è il tool più semplice da usare e ha il catalogo di integrazioni più esteso. Il suo limite è la rigidità: ogni Zap è un flusso lineare, la logica condizionale è limitata, la gestione degli errori è elementare. Funziona bene per automazioni semplici su tool standard. Appena vuoi fare qualcosa di non lineare, ti scontri con i limiti dell’interfaccia. Il costo per operazione è il più alto dei tre su volumi medi.

Make.com è il punto di equilibrio per chi vuole potenza senza gestire infrastruttura. La canvas visuale permette flussi complessi, la granularità dei moduli è alta, e il modello a operazioni è prevedibile se pianificato. È la scelta giusta per infobusiness e agenzie che hanno flussi non banali ma non vogliono un DevOps in casa.

n8n è open source e si auto-ospita. Il vantaggio principale è il costo: una volta che paghi il server, non paghi per operazioni. Per volumi alti — decine di migliaia di run al mese — il risparmio è reale. Lo svantaggio è la complessità operativa: devi gestire aggiornamenti, backup, uptime. Se non hai qualcuno in grado di fare questo, n8n in produzione diventa un rischio. La libreria di integrazioni native è più piccola di quella di Make, anche se il nodo HTTP copre molto.

La regola pratica: se fai meno di 50.000 operazioni al mese e non vuoi gestire server, Make è la scelta più solida. Se superi quella soglia con flussi stabili e hai competenze tecniche, n8n torna economicamente. Zapier ha senso solo se i tuoi flussi sono genuinamente semplici e usi tutti tool del suo catalogo premium.

I pattern collaudati: webhook, iterator/aggregator, data store

Tre pattern coprono il 90% dei casi d’uso reali in produzione.

Webhook come trigger

Un webhook in ingresso è il modo più affidabile per avviare uno scenario in tempo reale. Qualunque tool che può fare una chiamata HTTP POST può triggerare un flow Make senza polling. Il vantaggio sul trigger a polling — «controlla ogni X minuti» — è la latenza: il dato arriva quando succede l’evento, non al giro successivo del polling.

La prima cosa da fare con un webhook trigger è validare il payload in ingresso. Make ti permette di definire la struttura del dato atteso. Se il payload non corrisponde, il modulo fallisce subito invece di passare dati malformati a valle. Meglio fallire in ingresso con un errore chiaro che produrre output silenziosamente sbagliati.

Iterator e aggregator su array

Quando il payload contiene un array — una lista di prodotti, un batch di contatti, le righe di un report — l’iterator lo spezza e ti permette di applicare la stessa logica a ogni elemento. L’aggregator ricompatta i risultati. Questo pattern è fondamentale per lavorare su dati batch senza costruire scenari separati per ogni record.

Un caso concreto: ricevi da un webhook un array di 30 nuovi iscritti. L’iterator processa ognuno, aggiunge il contatto al CRM, iscrive alla lista email, logga su Sheets. L’aggregator alla fine raccoglie tutti gli ID creati e manda un unico riepilogo su Slack. Senza iterator/aggregator dovresti fare una chiamata separata per ogni operazione e gestire manualmente il loop.

Data store come coda e memoria

Il Data Store di Make è un database chiave-valore integrato nella piattaforma. Non sostituisce un database reale, ma per pattern specifici è molto utile: accodare record da riprocessare in caso di errore, tenere traccia dello stato di un processo multi-step, deduplicare eventi ricevuti più volte.

Un pattern che uso per la gestione degli errori: ogni volta che un modulo critico fallisce, la rotta di errore scrive il bundle nel Data Store con timestamp e motivo del fallimento. Uno scenario schedulato ogni ora legge il Data Store, riprova i record falliti, e li cancella se il retry va a buon fine. Zero perdita di dati, zero intervento manuale.

Da dove partire con Make.com

La prima cosa da costruire non è lo scenario più ambizioso che hai in testa. È il più piccolo flusso utile che tocca due sistemi che già usi.

Il motivo è pratico: Make ha una curva. La canvas visuale sembra intuitiva, ma i concetti di bundle, iterator, data mapping richiedono esperienza per essere usati bene. Parti semplice, costruisci il muscolo, poi aggiungi complessità. Uno scenario da dieci moduli costruito bene vale più di tre scenari da trenta moduli costruiti male che si rompono in silenzio.

Definisci il processo su carta prima di aprire Make. Chi fa cosa, quando, con quali dati, con quale output atteso. Se non riesci a descrivere il flusso in linguaggio naturale senza ambiguità, non sei pronto a costruirlo nello strumento. Il tool non risolve l’ambiguità di processo — la nasconde, e poi ti si presenta come bug.

Aggiungi il monitoraggio dal primo giorno. Un Google Sheet che logga ogni esecuzione con stato e timestamp non richiede più di un modulo in fondo allo scenario. Il costo è basso, il valore quando qualcosa smette di funzionare è alto.

Se vuoi iniziare, puoi attivare la prova gratuita di Make da questo link e lavorare con 1.000 operazioni mensili senza limiti di tempo sul piano free.

Domande frequenti

Make.com è gratuito?

Sì, esiste un piano gratuito con 1.000 operazioni al mese e scenari illimitati. Per la maggior parte degli usi in produzione non basta: i piani a pagamento partono da circa 9 dollari al mese per 10.400 operazioni. Il costo scala con le operazioni, non con il numero di scenari.

Make funziona in italiano?

L’interfaccia di Make è in inglese. La documentazione ufficiale è in inglese. Il supporto è in inglese. Puoi costruire scenari che lavorano su contenuti in italiano senza problemi, ma la piattaforma stessa non ha una localizzazione italiana.

Cosa sono le operazioni in Make e come si calcolano?

Un’operazione è ogni esecuzione di un modulo attivo in uno scenario. Se uno scenario ha cinque moduli e gira 200 volte al mese, consuma 1.000 operazioni. Gli iterator moltiplicano: se itero su un array di 50 elementi, ogni modulo nell’iterazione conta 50 operazioni per run.

Make.com è meglio di Zapier?

Per flussi semplici su tool comuni, Zapier è più rapido da configurare. Per automazioni non lineari, con gestione degli errori, logica condizionale e trasformazione dati, Make è più potente. La scelta dipende dalla complessità del processo, non da quale piattaforma abbia più integrazioni.

Trasparenza: in questo articolo c’è un link di affiliazione. Se ti iscrivi da lì io ricevo una commissione, per te non cambia niente. Linko solo strumenti che uso in produzione.