Una startup B2B italiana, verticale HR tech, ha scritto al nostro supporto a inizio 2026 con un problema che riassume bene la categoria. Avevano costruito la loro pipeline lead in modo classico: chatbot sul sito, ogni conversazione qualificata veniva inoltrata via middleware no-code a una catena di 8 automazioni. Prima creavano il contatto nel CRM, poi aggiornavano un campo custom, poi mandavano una notifica Slack al commerciale, poi aggiungevano una riga in un foglio di reporting, poi un altro passaggio per assegnare il lead tramite round-robin, poi una email di conferma al prospect, poi un tag di tracciamento, poi un ping al sistema di scoring. Otto automazioni distinte, una fattura mensile del middleware intorno ai 79 euro, una pipeline che a 400 lead al mese stava in piedi e nessuno guardava.
Poi il prodotto ha cominciato a crescere. In sei settimane i lead sono passati da 400 a 1.100 al mese. Uno dei passaggi ha iniziato a fallire in modo intermittente: il CRM rifiutava chiamate ogni tanto per un rate limit di cui il team non era al corrente. Il middleware provava a rifare il passaggio, ma il passaggio successivo nella catena era già partito con dati incompleti. Risultato: lead duplicati, lead scomparsi, notifiche Slack senza contatto CRM associato, commerciali che si lamentano. Il CTO si è trovato a fare reverse engineering su una pipeline che non aveva scritto lui, in un ambiente visuale, senza log strutturati, senza test. Alla fine ha deciso di buttarla via e ricostruirla.
Questo articolo parla di perché lo ha fatto, di cosa ha ricostruito al posto, e di quando invece ha ancora senso tenere un middleware. Non parliamo di un singolo prodotto: parliamo di una categoria. Middleware no-code significa strumenti visuali che stanno fra due sistemi, fanno da traduttore, si pagano a operazioni. Zapier è il nome più conosciuto, Make.com è il secondo, n8n è la variante self-hosted. Condividono una promessa: collegare tutto con tutto senza scrivere codice. E condividono un problema: a un certo punto della crescita smettono di essere la soluzione e diventano il collo di bottiglia.
Cosa compri quando paghi un middleware
Prima di parlare di alternative vale la pena capire cosa stai comprando. Un middleware no-code ti vende tre cose. La prima è una libreria di connettori pre-costruiti: 6.000 o 7.000 integrazioni pronte, da Gmail a Salesforce a WooCommerce a Notion. La seconda è un orchestratore visuale: trascini i blocchi, colleghi i campi, decidi cosa fare se qualcosa fallisce. La terza, quella che molti sottovalutano, è un runtime che gira 24/7: qualcuno tiene i server accesi, fa retry, logga, scala.
Questi tre pezzi insieme funzionano benissimo quando sei all’inizio. Il connettore pre-costruito ti evita di leggere la doc API. L’orchestratore visuale ti evita di stendere codice. Il runtime ti evita di pensare a dove gira il codice. Il problema è che nessuno dei tre vantaggi cresce con te. Più volumi fai, più ti accorgi che il connettore pre-costruito copre solo l’80 percento dei casi che ti servono, che l’orchestratore visuale diventa illeggibile oltre 10 passaggi, e che il runtime ti manda conti che aumentano in modo non lineare.
Il conto del middleware, numeri alla mano
Facciamo l’esercizio che quasi nessuno fa al momento dell’acquisto: proiettare il costo su scala. Prendiamo come base i prezzi pubblici più diffusi nel 2026. Il piano entry del middleware leader parte intorno ai 20 euro al mese per circa 750 task, il piano intermedio sta sui 69 euro al mese per 2.000 task, e da lì si sale. Un task corrisponde a un’azione: se il tuo flow ha 8 passaggi, ogni conversazione qualificata brucia 8 task. Gli overage scattano in automatico, con tariffe pay-per-task tre volte più care del piano annuale incluso.
Ipotizziamo una pipeline chatbot con 8 passaggi. Ecco come evolve il conto.
500 conversazioni qualificate al mese: 4.000 task. Ti servono il piano da 69 euro al mese circa più overage, oppure un tier superiore. Fatto sta che pagherai intorno ai 70-100 euro al mese, non i 20 euro del piano base.
2.000 conversazioni qualificate al mese: 16.000 task. Il piano team non basta, serve il professional con add-on. Parliamo di 200-300 euro al mese a prezzo di listino.
10.000 conversazioni qualificate al mese: 80.000 task. Qui si entra nella zona dei piani company o enterprise, con prezzi che vanno dai 600 ai 1.500 euro al mese.
Aggiungi che ogni filter step, ogni trasformazione, ogni ramificazione brucia task. Aggiungi che le piattaforme credit-based come Make.com sono più economiche a parità di volume ma consumano crediti anche per operazioni che pensavi fossero gratis. Aggiungi che se devi chiamare un webhook di uscita da un flow, paghi anche quello. Il risultato è che una pipeline che a 400 lead costa 60 euro al mese, a 4.000 lead ne costa 400, e non perché tu abbia aggiunto feature, ma solo perché hai più volume.
C’è un altro livello di costo che non compare in fattura: il tempo del team. Ogni volta che un passaggio fallisce e il middleware manda una email di errore, qualcuno deve aprire l’interfaccia visuale, capire dove si è rotto, rimetterlo in piedi. A scala, questo tempo diventa un lavoro a tempo parziale che nessuno ha messo nel budget.
La latenza che non vedi
Oltre al costo c’è un problema tecnico più sottile: la latenza. Un middleware no-code sta in mezzo fra l’assistente AI e il CRM. Ogni evento fa un saltino. Il sistema chiude la conversazione, manda un payload al middleware, il middleware lo riceve, lo accoda, lo processa, chiama il CRM, aspetta risposta, passa al prossimo step. Ogni hop aggiunge tempo.
Nei piani bassi la latenza è particolarmente alta perché la piattaforma non fa partire subito il tuo flow: polla a intervalli fissi. Se sei su un piano entry, il polling può essere ogni 15 minuti. Questo significa che una conversazione chiusa alle 10:00 può finire nel CRM alle 10:14. Per un lead B2B forse va bene. Per una notifica di carrello abbandonato o per una richiesta urgente a un centralino medico no, non va bene.
Anche passando ai piani premium, che lavorano in modalità push, la latenza end-to-end di un flow a 8 passaggi difficilmente scende sotto i 5-15 secondi. Un webhook diretto fra chatbot e CRM, senza intermediari, gira in 200-400 millisecondi. La differenza sembra teorica, ma si sente. La sente il prospect che riceve l’email di conferma 10 secondi dopo il click. La sente il commerciale che vede il lead in CRM quando il prospect è già andato via. La sente il reparto supporto quando una richiesta urgente arriva 3 minuti dopo che il cliente ha chiamato.
Il punto di rottura in più
Ogni sistema nella tua pipeline è un potenziale punto di rottura. Senza middleware hai chatbot e CRM: se uno dei due cade, sai cosa è caduto. Con middleware hai chatbot, middleware, CRM: se qualcosa non funziona, il primo lavoro è capire chi ha sbagliato. Un errore 429 dal CRM può arrivare al middleware sotto forma di retry silenzioso, sotto forma di errore bloccante, sotto forma di task completato ma con dati sbagliati, a seconda di come hai configurato il flow. Debuggare questo in un’interfaccia visuale senza log strutturati è un incubo.
Aggiungi che il middleware è un servizio di terze parti. Quando loro hanno un disservizio (e capita: qualsiasi piattaforma ha downtime), tu hai un disservizio anche se chatbot e CRM funzionano perfettamente. Lo stato sulle status page di queste piattaforme racconta cento piccoli incidenti all’anno. Non sono drammi, ma ciascuno di quegli incidenti è un momento in cui la tua pipeline non funziona per un motivo su cui non hai nessun controllo.
Integrazioni native: cosa significa davvero
Quando parliamo di integrazione nativa intendiamo una connessione diretta fra due sistemi, senza orchestratore in mezzo. Il chatbot chiama direttamente l’API del CRM. Oppure, meglio ancora, l’assistente emette un evento, il CRM lo riceve come webhook firmato, reagisce. Niente terzo attore. Niente task da contare. Niente interfaccia visuale da mantenere.
Questo modello non è nuovo. È il modello dei grandi SaaS. Stripe non ti chiede di passare da un middleware per notificare un pagamento: ti manda un webhook firmato direttamente. Shopify non ti obbliga a usare Zapier per sincronizzare gli ordini: espone una API REST e una GraphQL, più webhook per ogni evento rilevante. Gli app store dei prodotti enterprise seri sono costruiti su integrazioni native, non su middleware. Il middleware è una comodità per chi non ha tempo di scrivere codice; a un certo livello di maturità tecnica, non è più una comodità, è un peso.
In TrueReply abbiamo scelto di dare a TrueReply la capacità di parlare direttamente con i sistemi dei nostri clienti. TrueReply include, in tutte le linee, tre capacità che sostituiscono quasi tutti gli usi tipici di un middleware no-code.
Tool HTTP custom. Lo strumento può invocare qualsiasi endpoint HTTP durante la conversazione. Se la tua piattaforma espone una API, l’agente AI la chiama: per leggere uno stato ordine, creare un ticket, controllare disponibilità, registrare un contatto. Non c’è un terzo servizio in mezzo. La chiamata parte dal bot e arriva al tuo endpoint.
Webhook HMAC illimitati. Quando un evento importante accade nel bot (conversazione chiusa, lead qualificato, carrello recuperato), il sistema invia un webhook firmato al tuo endpoint. Puoi riceverlo dove vuoi: un tuo backend, una function serverless, una Lambda, un endpoint del CRM. La firma HMAC-SHA256 garantisce che il payload è autentico e non è stato alterato. Niente coda intermedia, niente task contati, nessun limite sul numero di webhook al mese.
Estrazione variabili strutturate. Il sistema capisce la conversazione ed estrae automaticamente campi strutturati: nome, email, azienda, settore, budget, urgenza, qualsiasi variabile tu definisca. Questi campi finiscono nel payload del webhook. Il tuo endpoint riceve JSON pulito, non un testo da parsare.
Le integrazioni native che copriamo out-of-the-box
Non tutti i clienti vogliono scrivere un endpoint. Per i casi più comuni abbiamo integrazioni dirette già pronte, senza nessun middleware da configurare.
WooCommerce e Shopify. L’assistente legge carrello, ordini, stato spedizione, resi direttamente dall’API della piattaforma. Quando un cliente chiede "dov’è il mio ordine", TrueReply interroga WooCommerce in tempo reale e risponde con il numero di tracking. Nessun foglio Excel intermedio, nessun middleware di sincronia. Documentazione e dettagli in chatbot e-commerce.
[Google Calendar](https://calendar.google.com/). Lo strumento legge la disponibilità reale del calendario aziendale e prenota slot direttamente. Nessuna coda intermedia: quando il prospect conferma l’appuntamento, lo slot è fissato. Il cliente apre il suo calendario e vede l’evento.
Webhook HMAC verso qualsiasi sistema. Se usi Pipedrive, HubSpot, Salesforce, Zoho, un CRM italiano verticale, un ERP, un gestionale custom: la logica è sempre la stessa. Tu esponi un endpoint, noi ti mandiamo webhook firmati, tu decidi cosa fare con il payload. Questa è la strada che scegliamo per tutte le integrazioni che non sono pacchettizzate.
Il caso dei gestionali italiani
Una delle ragioni principali per cui molte aziende italiane hanno finito per usare middleware no-code è che nessun grande middleware internazionale ha connettori nativi per i gestionali usati in Italia. Se il tuo CRM è un prodotto verticale da 3.000 clienti, sviluppato da una software house di Modena, non lo trovi su Zapier. Gli integratori lo sanno, e per evitare di scrivere codice hanno costruito architetture a catena: middleware internazionale, poi script intermedio, poi connettore artigianale al gestionale. Risultato: tre sistemi da mantenere al posto di uno.
Noi affrontiamo questo scenario in modo diverso. Quando un cliente ha un gestionale italiano, apriamo il documento dell’API del gestionale (se esiste), scriviamo un tool HTTP custom che parla direttamente con quel sistema, e integriamo la logica nel prompt dell’agente AI. Il sistema chiama l’endpoint del gestionale in modo diretto, riceve il dato, continua la conversazione. Zero middleware, zero overhead. Per i casi più complessi o se serve riconciliare più sistemi, passiamo al pacchetto integrazioni custom in cui progettiamo end-to-end la pipeline di dati, con codice di proprietà del cliente e infrastruttura sotto il suo controllo.
Confronto diretto: middleware no-code vs webhook nativo
| Dimensione | Middleware no-code | Webhook nativo HMAC |
|---|---|---|
| Latenza tipica | 5-15 secondi (push), fino a 15 minuti (polling) | 200-400 millisecondi |
| Costo mensile a 2.000 eventi/8 step | 200-300 euro | Incluso in TrueReply |
| Costo mensile a 10.000 eventi/8 step | 600-1.500 euro | Incluso in TrueReply |
| Retry e gestione errori | Logica della piattaforma, spesso opaca | Controllo totale lato endpoint |
| Sicurezza payload | Dipende dal connettore | HMAC-SHA256 con timestamp |
| Ownership pipeline | Condivisa con terza parte | 100 percento del cliente |
| Debugging | Interfaccia visuale, log limitati | Log strutturati nel backend cliente |
| Punti di rottura | Tre (chatbot, middleware, CRM) | Due (chatbot, CRM) |
| Vendor lock-in | Forte, logica vive nel middleware | Assente, la logica vive nel tuo codice |
Quando un middleware ha ancora senso
Saremmo in malafede se dicessimo che il middleware è sempre sbagliato. Ci sono scenari in cui ha ancora senso.
Il primo è quando stai prototipando. Devi testare se un certo flow funziona, se il commerciale apre davvero le notifiche, se i lead sono qualificati come pensi. Per le prime settimane un middleware ti permette di montare e smontare pipeline in minuti, senza scrivere codice. È un costo di validazione, non di produzione.
Il secondo è quando hai volumi stabilmente bassi e destinati a restare tali. Se fai 50 eventi al mese e li farai per sempre, 20 euro al mese di middleware sono meno di un’ora di sviluppo custom. La matematica è a favore del middleware.
Il terzo è quando devi collegare sistemi che nessuno dei due espone webhook o API consumer-friendly, ma esistono connettori pre-costruiti. Se devi sincronizzare due prodotti legacy in cui l’unico modo di prendere dati è un cron su un CSV FTP, il middleware ti evita di costruire quella pipeline FTP a mano.
Il quarto è quando la pipeline ha solo 2-3 passaggi e cambia raramente. Un flow con tre step che gira da due anni senza modifiche può stare benissimo su un middleware: paghi poco, non tocchi quasi mai.
Fuori da questi scenari, quando i volumi crescono, quando i passaggi aumentano, quando la pipeline diventa critica per il business, il middleware è un debito tecnico che si paga a compound interest.
Piano di migrazione in due settimane
Parliamo con diversi team che arrivano a questo punto e ci chiedono come si smonta una pipeline middleware senza far cadere il business. Il playbook è abbastanza stabile. In due settimane, con uno sviluppatore mid-level, si passa da catena di middleware a webhook nativi.
Settimana 1, giorno 1-2. Inventario. Scrivi ogni step del flow attuale, cosa fa, dove legge, dove scrive, che errori gestisce. Non fidarti dell’interfaccia visuale: sono spesso pieni di step che nessuno ricorda perché esistono.
Settimana 1, giorno 3-4. Consolidamento. In una pipeline tipica da 8 step, 3 o 4 sono trasformazioni di dati che non servono più (filtri obsoleti, campi custom creati per risolvere problemi non più attuali). Li elimini.
Settimana 1, giorno 5. Progettazione endpoint. Scrivi un endpoint HTTP nel tuo backend, o una function serverless, che riceve il webhook e fa tutta la logica rimanente in un colpo solo. Una chiamata al CRM, una chiamata a Slack, un upsert al foglio di reporting, una notifica email. Codice che vive nel tuo repo, sotto il tuo controllo versione.
Settimana 2, giorno 1-2. Puntamento. Configuri il webhook dell’assistente verso il nuovo endpoint. Fai partire entrambi in parallelo: il flow middleware continua a girare, il tuo endpoint riceve lo stesso payload e scrive in ambienti di test.
Settimana 2, giorno 3. Verifica. Confronti i risultati delle due pipeline per 48 ore. Se producono gli stessi effetti, procedi.
Settimana 2, giorno 4-5. Cutover. Spegni il middleware. Il nuovo endpoint diventa l’unico responsabile della pipeline. Cancelli l’abbonamento.
Al netto di complicazioni specifiche (connettori custom, gestionali italiani con API povere), questo playbook si chiude in 10-12 giorni lavorativi. Il risparmio operativo è immediato: il mese successivo la fattura del middleware sparisce. Il risparmio tecnico è più lungo ma più grosso: hai ripreso controllo della pipeline, hai log nel tuo backend, hai deploy versionati, hai la possibilità di scrivere test automatici.
Sicurezza dei webhook: HMAC non è opzionale
Il principale controargomento al modello webhook diretto è la sicurezza. "Se il chatbot chiama il mio endpoint, chiunque può farlo." Ha senso come obiezione, ma la risposta è vecchia di 15 anni e si chiama HMAC.
Ogni webhook che inviamo porta un header con la firma HMAC-SHA256 del payload, calcolata con una chiave segreta condivisa fra noi e il cliente. Il cliente, all’arrivo del webhook, ricalcola la firma sul payload ricevuto e verifica che coincida con l’header. Se non coincide, rifiuta la richiesta. Questa è la stessa tecnica che usa Stripe per i suoi webhook di pagamento, la stessa che usa GitHub per i webhook delle repo. Funziona.
Per evitare replay attack (qualcuno intercetta il payload valido e lo riinvia), includiamo un timestamp nella firma. Il cliente accetta solo webhook con timestamp recente, tipicamente entro 5 minuti. Oltre quel tempo, anche una firma valida viene rifiutata. Con questi due accorgimenti la superficie d’attacco è, in pratica, quella di una richiesta autenticata con API key.
Rispetto al middleware la sicurezza migliora su un altro fronte: il payload non transita più da un sistema di terze parti che potrebbe loggarlo, salvarlo, analizzarlo per fini di billing. Il dato va dal chatbot al tuo backend e basta. Per dati sensibili (sanitario, finanziario, dati personali con obblighi GDPR forti) questo non è un vantaggio di performance, è un vantaggio di compliance.
Ownership della pipeline come asset strategico
L’ultimo punto non è tecnico ma strategico, ed è quello che cambia la valutazione per chi ragiona in termini di azienda, non di singola integrazione. Quando la tua pipeline chatbot-CRM vive in un middleware, non è un asset tuo. È un asset che affitti. Se il middleware cambia prezzi (succede), se cambia policy (succede), se viene acquisito (succede), se chiude (è successo), la tua pipeline si è fermata. Non c’è un file di codice in un repo che puoi portare altrove.
Quando la pipeline vive come codice nel tuo backend, è tua. Puoi cambiare chatbot, puoi cambiare CRM, puoi cambiare infrastruttura, e quel codice continua a essere rilevante e a evolvere. Nel tempo la documentazione diventa il repo, i test coprono i casi limite, le persone che si aggiungono al team possono fare reverse engineering leggendo codice invece che guardando screenshot di un’interfaccia visuale di un prodotto a cui potrebbero non avere accesso.
Per chi costruisce un prodotto SaaS o un servizio B2B, avere la pipeline dati come asset interno non è un dettaglio. È la stessa differenza che c’è fra affittare un magazzino e possederlo. Entrambe le opzioni hanno senso in fasi diverse. A maturità, quasi nessuno continua ad affittare.
Cosa include TrueReply per sostituire un middleware
Le linee di TrueReply sono pensate esattamente per il cliente che sta facendo questo ragionamento, con i volumi di conversazioni e minuti voce del tier scelto (vedi prezzi). Dentro ci sono tool HTTP custom invocati dal bot, webhook HMAC-SHA256 in uscita senza limite sul numero, estrazione variabili strutturate, accesso API, fino a 3 bot per account, supporto prioritario.
Per i casi in cui il nostro standard non basta (integrazioni con 5 sistemi, riconciliazione fra data warehouse e gestionale, logiche di routing complesse che meritano codice dedicato) esiste la strada agente AI custom oppure integrazioni custom in cui progettiamo l’architettura insieme al team tecnico del cliente, con codice che resta di proprietà del cliente e infrastruttura che sta dove la vuole lui.
Quello che non facciamo è pagare altri middleware al posto tuo. La promessa è semplice: chi prende TrueReply non ha più bisogno di un middleware no-code per la pipeline chatbot. Le integrazioni più comuni sono native, quelle meno comuni si fanno con webhook HMAC, quelle esotiche con tool HTTP. Il risparmio è sulla bolletta del middleware, sul tempo del team tecnico, sul tasso di fallimento della pipeline. Chi vuole vedere come funziona il tutto prima di decidere, può passare 30 minuti di call tecnica con noi. Portate il diagramma della vostra pipeline attuale; in mezz’ora vi diciamo se TrueReply la sostituisce o se serve il pacchetto custom.
