Recupero carrello con chatbot AI e webhook verso CRM: oltre l'email di recovery

Domenica sera, 22:47

Maria ha due bambini che dormono, un bicchiere di vino rosso accanto al MacBook e un carrello aperto su un negozio italiano di abbigliamento. Nel carrello c'è un cappotto da 289 euro. Lei non è sicura della taglia: tra una 42 e una 44 ha sempre avuto dubbi con questo brand. Clicca sulla guida taglie, torna indietro, legge le recensioni, apre la pagina spedizioni, torna al carrello. Sono passati undici minuti. Chiude la scheda.

Lunedì mattina alle 9:14 le arriva la prima email di recovery. La apre mentre aspetta il caffè, pensa ci penso stasera, archivia. Martedì alle 9:00 la seconda email. Non la apre. Giovedì la terza, con un codice sconto del 10%. Anche questa resta chiusa.

Sabato Maria compra lo stesso cappotto da un concorrente che le ha risposto in chat alle 22:49 di domenica sera, le ha detto che la 44 in quel modello veste leggermente larga e che con la spedizione prioritaria arriva in due giorni. Tredici minuti di conversazione, zero email, vendita chiusa.

Questo articolo spiega come costruire il secondo scenario con il piano Autopilot di TrueReply, e come il webhook HMAC verso il CRM sostituisca integralmente Zapier nella maggior parte dei casi e-commerce italiani di volume medio.

Il dato che inquieta tutti: 70,19%

Baymard Institute aggrega da dodici anni gli studi indipendenti sull'abbandono carrello nel retail online. La media ponderata nel 2024 è del 70,19%. Significa che su dieci utenti che aggiungono un prodotto al carrello, sette non completano mai l'acquisto. Il dato non è migliorato in quindici anni: era 69,23% nel 2010.

La distribuzione per settore è istruttiva:

• Moda e abbigliamento: circa 68-72%
• Elettronica di consumo: circa 73-76%
• Alimentare e grocery online: circa 50-55% (molto più basso, ordini frequenti e importi piccoli)
• Travel e booking: oltre 80%
• Lusso e orologeria: 75-85%

Le ragioni dichiarate dagli utenti nei questionari Baymard restano stabili negli anni: costi imprevisti (48%), obbligo di creare un account (24%), checkout troppo lungo (18%), insicurezza sui dati di pagamento (17%), consegna troppo lenta (16%), dubbi su taglia/compatibilità/caratteristiche (circa 12-15% a seconda della categoria).

La frazione che si recupera con le email classiche è modesta. SaleCycle, Klaviyo e i benchmark Mailchimp raccontano una storia simile: l'email di recovery a un'ora dall'abbandono ha apertura del 40-45% (inflata dalla curiosità iniziale), ma il click-through medio è del 6-10% e la conversione finale sul campione abbandonato oscilla tra l'1% e il 3% per la prima email, scende sotto l'1% per la seconda, sotto lo 0,5% per la terza. L'orizzonte temporale conta: dopo 24 ore la probabilità di recupero è dimezzata, dopo 72 ore è marginale.

Il problema non è l'email in sé, è la finestra temporale. L'utente era in modalità acquisto alle 22:47 di domenica. Alle 9:14 di lunedì è in modalità caffè.

Perché il chatbot AI cambia la finestra

Il chatbot piazzato sul sito non aspetta che l'utente se ne vada. Interviene mentre l'utente sta ancora decidendo. I trigger che TrueReply usa sui siti e-commerce integrati sono:

• Permanenza oltre 45 secondi sulla pagina carrello senza procedere al checkout
• Scroll ripetuto sulla pagina prodotto (spesso indica ricerca di informazioni)
• Apertura della pagina guida taglie o spedizioni da un carrello attivo
• Exit intent rilevato dal movimento del mouse verso la tab o il bordo alto
• Inattività di oltre due minuti con carrello non vuoto

Quando il bubble si apre con un messaggio pertinente ("Ti serve una mano sulla taglia?", "Posso controllarti i tempi di consegna?") il tasso di ingaggio che misuriamo sui clienti Autopilot oscilla tra il 12% e il 22% dei carrelli esitanti. Di questi, una porzione significativa chiude l'acquisto nella stessa sessione; una seconda porzione lascia email o telefono perche vuole essere ricontattata, conferma disponibilità di taglia, o chiede un preventivo per ordini B2B. E su questa seconda porzione che il webhook HMAC verso il CRM fa la differenza reale.

Il problema del passaggio lead: Zapier non basta

Lo schema classico nei piccoli e medi e-commerce italiani è: chatbot o form raccoglie dato, invia email al team, qualcuno copia-incolla nel CRM, qualcun altro assegna lo ticket, qualcuno chiama. Ogni passaggio aggiunge minuti o ore e almeno uno dei passaggi si rompe regolarmente.

La soluzione comune è Zapier. L'utente compila il form, Zapier riceve il webhook, Zapier crea il contatto su HubSpot o Pipedrive. Funziona, ma ha quattro problemi concreti:

1. Costo. Il piano Zapier Professional 2025 parte da 73 dollari al mese per 2.000 task multi-step; salire a 10.000 task/mese costa circa 243 dollari. Su un e-commerce con 300-500 conversazioni chatbot mensili e più step per conversazione (lead + tagging + notifica + log foglio Google) si bruciano 4-6 task a conversazione. I conti diventano rapidamente quattro cifre annue.
2. Latenza. Zapier ha polling e ritardi propri. I webhook diretti sono immediati (decine di millisecondi); Zapier aggiunge secondi, talvolta minuti nei piani bassi.
3. Fragilità. Ogni aggiornamento dello schema dati del CRM (campo rinominato, campo custom aggiunto) rompe lo Zap. Ogni rotazione di token API lo rompe. Chi lo ripara di solito non è chi lo ha creato sei mesi prima.
4. Ownership dei dati. I dati dei lead passano per server Zapier. Per alcuni contesti (dati sanitari, dati sensibili, sub-fornitori GDPR) è un problema formale o sostanziale.

Il webhook HMAC diretto elimina tutti e quattro i problemi.

Come funziona il webhook HMAC-SHA256

HMAC sta per Hash-based Message Authentication Code. L'idea è banale e robusta: mittente e destinatario condividono un segreto. Quando il mittente invia un payload, calcola un hash del payload usando il segreto come chiave. Il destinatario ricalcola l'hash con lo stesso segreto: se coincide con quello ricevuto nell'header, il payload e autentico e non e stato modificato in transito. Se non coincide, si rifiuta.

E lo standard che usano Stripe (firma in header Stripe-Signature con schema v1=hash, timestamp incluso per prevenire replay), Shopify (header X-Shopify-Hmac-Sha256, payload raw body), Slack (header X-Slack-Signature con schema v0=hash), GitHub (X-Hub-Signature-256). Autopilot di TrueReply adotta lo stesso pattern: header X-TrueReply-Signature con schema sha256=hash, include un timestamp in X-TrueReply-Timestamp per permettere al ricevente di rigettare payload troppo vecchi (difesa contro replay attack).

La cosa importante per un CTO: non devi fidarti di noi, verifichi tu la firma. Il segreto HMAC è configurato nell'area riservata, non viaggia mai in rete, e lo stesso endpoint CRM può rifiutare con HTTP 401 qualsiasi payload che non verifica. Se qualcuno si mette nel mezzo o scopre l'URL dell'endpoint, senza il segreto non può iniettare lead fasulli.

Estrazione variabili strutturate

Il passo precedente al webhook e piu interessante di quanto sembri. Il chatbot non invia il lead come blob di testo (L'utente ha detto di essere interessato al cappotto). Invia un JSON strutturato con variabili tipizzate estratte dalla conversazione. Questa è la feature che rende Autopilot qualitativamente diverso dai competitor e che sta dentro la categoria che OpenAI chiama function calling, Anthropic chiama tool use e Google chiama function calling: l'LLM non restituisce solo testo ma produce output conformi a uno schema JSON dichiarato.

Esempio concreto. Il bot nel carrello di Maria raccoglie, durante la conversazione naturale:

• Prodotto oggetto di interesse (SKU)
• Taglia discussa
• Dubbi espressi (vestibilità, tempi consegna, resi)
• Livello di urgenza (mi serve per sabato)
• Canale preferito per il follow up
• Email e/o telefono se forniti
• Consenso marketing esplicito

Questi campi sono definiti in uno schema JSON che l'admin configura una volta nell'area riservata di TrueReply. L'LLM, durante la conversazione, popola le variabili via via che emergono. A fine conversazione (o su trigger intermedio: lead qualificato) il bot invia il payload al webhook configurato.

Senza function calling strutturato avresti ottenuto una trascrizione da fare parsare a un secondo script di post-processing. Con function calling strutturato ottieni direttamente un oggetto pronto per l'API del CRM.

Esempio di payload reale

Ecco il formato tipico che Autopilot invia al tuo endpoint quando si verifica un lead qualificato da chatbot e-commerce:

\`\`\`json { "event": "lead.qualified", "event_id": "evt_01HRXK2Z9P7Q8M4N", "timestamp": "2026-04-22T21:03:17.284Z", "bot_id": "bot_ecommerce_moda", "session_id": "sess_8a4f2b9c1d", "contact": { "email": "maria.rossi@example.it", "phone": "+393471234567", "first_name": "Maria", "marketing_consent": true, "consent_timestamp": "2026-04-22T21:01:42.000Z" }, "cart": { "cart_id": "cart_woo_28471", "total_eur": 289.00, "items": [ { "sku": "CAPPOTTO-LANA-NERO-44", "product_name": "Cappotto lana double face", "size": "44", "quantity": 1, "price_eur": 289.00 } ] }, "qualification": { "lead_score": 78, "urgency": "high", "intent": "purchase_ready_with_sizing_doubt", "objections": ["sizing_uncertainty", "delivery_time"], "preferred_channel": "whatsapp", "preferred_contact_time": "evening", "language": "it" }, "conversation": { "duration_seconds": 412, "messages_count": 14 }, "source": { "page_url": "https://negozio.it/cart", "utm_source": "google", "utm_campaign": "cappotti-autunno-2026" } } \`\`\`

Il tuo endpoint riceve questo JSON in POST con due header significativi:

• X-TrueReply-Signature: sha256=9f3a2b8c1e4d5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a
• X-TrueReply-Timestamp: 1745349797

Per verificare la firma il server ricalcola HMAC-SHA256(secret, timestamp + punto + body_raw) e lo confronta con l'header. Se non coincide, HTTP 401. Se coincide, procede con la creazione del contatto sul CRM.

Confronto diretto: email + data entry vs webhook HMAC

Tabella sintetica del confronto a parità di volume lead mensile (stima: 250 lead qualificati/mese da chatbot e-commerce Autopilot):

A 10.000 lead/mese il gap costo diventa drammatico: Zapier passa facilmente sopra i 500 USD/mese, il webhook diretto resta incluso nel piano Autopilot a 399 euro/mese IVA esclusa senza overage sul numero di webhook.

Mappatura al tuo CRM: casi concreti

La pipeline dal payload Autopilot al CRM e una funzione serverless o un endpoint dietro un'app tua. Alcuni pattern per i CRM piu diffusi nel tessuto e-commerce italiano:

HubSpot. L'endpoint riceve il JSON Autopilot, chiama POST /crm/v3/objects/contacts con Authorization Bearer tuo_token, mappa email, phone, first_name sui campi standard, porta lead_score e intent su custom property. Poi crea un engagement di tipo NOTE con il link trascrizione. Oppure, ancora più pulito, crea direttamente un deal con dealstage qualified e lo associa al contatto. HubSpot accetta batch fino a 100 contatti per chiamata; per i volumi in esame non serve.

Pipedrive. POST /v1/persons con api_token in query string (o meglio, OAuth2). I custom field si creano una volta dall'UI e si popolano con il loro field_key hash. Lead di urgenza alta finiscono direttamente in una pipeline dedicata hot leads.

[ActiveCampaign](https://www.activecampaign.com/). POST /api/3/contacts con Api-Token header, tag automatici in base a intent e objections. ActiveCampaign è fortissimo sulle automation downstream: una volta creato il contatto parte la sequenza email coerente con l'obiezione rilevata (sizing, delivery, pricing).

[Salesforce](https://www.salesforce.com/). Pattern più elaborato: si usa Platform Events o Composite API. L'endpoint chiama REST /services/data/v60.0/composite/sobjects con Lead + Task. Per volumi e-commerce italiani medi bastano Platform Events e un Apex trigger minimo.

[Zoho](https://www.zoho.com/) CRM e Bitrix24. Entrambi hanno REST API pubbliche ben documentate. Pattern identico: POST con token, mappatura campi, ricezione ID risposta, log.

CRM italiani. Fluentis, Teamleader (molto usato in Italia), vTiger self-hosted, CRM.com hanno tutti endpoint REST o SOAP. Se hai un CRM senza API (succede) il workaround è un Google Sheet come staging + un Apps Script che legge e spinge manualmente, ma a quel punto tanto vale parlare di migrazione.

Nel nostro ecosistema Autopilot abbiamo clienti live su HubSpot, Pipedrive, ActiveCampaign, Zoho, Salesforce, Teamleader, vari CRM proprietari sviluppati internamente. Il pattern non cambia: un endpoint HTTPS con verifica HMAC davanti al CRM.

Retry, failure mode e tracciabilità

La domanda seria che mi fa ogni CTO è cosa succede se il mio CRM è giu. Risposta: Autopilot mantiene una coda di delivery con retry a backoff esponenziale. La sequenza di default è 0s (primo invio), 30s, 2m, 10m, 30m, 2h, 12h (totale sette tentativi su circa 15 ore). Ad ogni tentativo lo stesso event_id viene riproposto; il tuo endpoint deve essere idempotente per quell'event_id (ricevere due volte lo stesso event_id non deve creare due contatti duplicati). Il pattern standard è un upsert sul CRM con chiave naturale email + session_id, o il salvataggio dell'event_id ricevuto in una tabella di deduplica.

Se dopo sette tentativi il CRM è ancora irraggiungibile, l'evento resta nella coda in stato failed, visibile dall'area riservata dove l'admin può forzare il reinvio manuale. Nel frattempo in chat il lead è stato comunque catturato: la conversazione è salvata, il contatto è recuperabile via export CSV o via query API. Nessun dato si perde.

Ogni evento ha un audit log completo con timestamp di generazione, timestamp di ogni tentativo, risposta HTTP ricevuta (status code, primi 500 caratteri del body), latenza. Questo aiuta moltissimo in debugging: quando un cliente dice il lead X non è arrivato nel CRM in 30 secondi si vede se il payload è stato generato, se è stato spedito, con che risposta.

Consenso marketing e GDPR

Un chatbot che passa dati a un CRM è un trattamento. Il consenso deve essere esplicito, documentato, revocabile. Il campo marketing_consent nel payload non è decorativo: il bot chiede esplicitamente Posso ricontattarti a questa email per confermarti disponibilità e offerte sul cappotto? e registra timestamp e testo della risposta. Questo va conservato perché è la prova del consenso in caso di richiesta dell'interessato o ispezione del Garante.

Se il consenso è falso o non dato, il payload si invia comunque al CRM ma con marketing_consent: false e il tuo endpoint deve rispettare quella flag: creare il contatto in sales pipeline ma non iscriverlo alla lista marketing. È una riga di codice nel tuo endpoint, ma se la salti rischi una segnalazione.

Quando Autopilot basta, quando serve Custom

Autopilot a 399 euro/mese IVA esclusa copre benissimo i seguenti scenari:

• Fino a 2.000 conversazioni chatbot al mese, che nei nostri dati e-commerce italiani corrispondono circa a 300-500 lead qualificati
• Fino a 3 bot per account (puoi avere bot separati per shop B2C, shop B2B, assistenza post vendita)
• Webhook verso endpoint HTTPS tuoi o di CRM standard con auth token e firma HMAC
• Tool HTTP custom che il bot invoca durante la conversazione (es. check disponibilità taglia in tempo reale via API magazzino)
• Estrazione variabili strutturate via function calling con schema definito dall'admin
• 500 minuti di voce telefonica con numero italiano dedicato

Quando invece ha senso salire a Integrazioni custom o al piano Custom a consumo:

• Oltre 5.000 lead/mese o 5.000 conversazioni/mese
• Necessita di processare dati sanitari o finanziari con DPA dedicato e server dedicati
• Integrazione bidirezionale complessa (il CRM invia dati al bot per personalizzare le risposte, es. storico ordini, fedelta)
• Protocolli legacy non HTTP (SOAP vecchi, SFTP con PGP, code AS2, EDI)
• Requisiti di on-prem o single-tenant
• Necessita di possedere il codice del tool HTTP server-side (con Custom hai accesso al source code e puoi self-hostare)

Il 90% degli e-commerce italiani di volume medio (300-3000 ordini/mese) stanno comodi in Autopilot. Il resto ha bisogno di un progetto dedicato che discutiamo caso per caso.

Piano implementazione in 14 giorni

Per un e-commerce su WooCommerce o Shopify che parte da zero, un piano realistico di deploy Autopilot + webhook CRM è il seguente:

Giorni 1-2: onboarding e training del bot. Carichiamo catalogo prodotti, guida taglie, politiche resi e spedizioni, FAQ esistenti. Il bot impara tono di voce e informazioni specifiche del tuo shop.

Giorni 3-4: definizione schema variabili lead insieme al tuo team commerciale. Cosa serve al commerciale per chiudere? Email, telefono, SKU, urgenza, obiezione principale? Si definisce lo schema JSON una volta.

Giorni 5-7: sviluppo endpoint ricezione webhook. Funzione serverless (Vercel, Cloudflare Workers, AWS Lambda) o endpoint dietro la tua app Rails/Laravel/Node che valida HMAC, mappa payload al tuo CRM, gestisce idempotenza via event_id. Tempo effettivo circa 4-8 ore di sviluppo per un developer junior-mid.

Giorni 8-10: test end to end in staging. Si simulano 30-50 conversazioni tipiche, si verifica che tutti i lead arrivino al CRM con i campi giusti, si calibrano i trigger di ingaggio.

Giorni 11-14: go live con attivazione graduale (10% traffico, poi 50%, poi 100%). Monitoraggio giornaliero della prima settimana.

Dopo la prima settimana live si comincia a vedere il lift reale. Nei clienti Autopilot e-commerce italiani misuriamo in media un aumento del tasso di conversione da carrello esitante del 6-11% e un'aggiunta di 80-200 lead qualificati mensili sul CRM che prima si perdevano completamente.

Vuoi vederlo in azione

La differenza tra lead che arriva lunedi mattina e lead che arriva domenica sera alle 22:48 con SKU, taglia, urgenza e consenso gia nel CRM la misuri sul fatturato del mese successivo. Se stai gestendo un e-commerce italiano su WooCommerce o Shopify con volumi 300-3000 ordini mensili, il piano Autopilot e pensato esattamente per questo scenario.

Guarda la pagina Chatbot e-commerce per il dettaglio dei trigger e dei flussi, la pagina Settore e-commerce per i risultati tipici sui nostri clienti, e la pagina Integrazioni custom se gia sai che ti serve qualcosa di piu ampio.

Da noi il chatbot non e un orpello sulla home, e il primo anello di una pipeline dati che arriva nel tuo CRM in millisecondi, con firma crittografica, con variabili tipizzate, senza middleware che si rompe ogni tre settimane.