WhatsApp Business Marketing per l'ecommerce italiano: campagne automatizzate via Spoki

WhatsApp Business è diventato in Italia uno dei canali con il miglior rapporto costo-conversione per l’ecommerce, soprattutto nei segmenti dove il pubblico ha bassa familiarità con email o dove il pagamento in contrassegno (COD) resta significativo. Tra le piattaforme italiane che integrano l’API WhatsApp Business, Spoki si è ritagliata uno spazio importante per la combinazione di template approvati, gestione campagne e webhook real-time. Quando l’integrazione viene fatta bene, una campagna WhatsApp produce risultati che difficilmente si ottengono con altri canali; quando viene fatta male, brucia template, irrita clienti e, nel caso peggiore, fa sospendere il numero business.

In questo articolo descrivo l’architettura che ho costruito per un brand pet care con un catalogo di circa milleduecento SKU, una customer base di sessantamila contatti raggiungibili via WhatsApp e una percentuale rilevante di ordini COD. L’obiettivo era avere una piattaforma di campagne WhatsApp integrata con il CRM ecommerce, con throttling automatico per non saturare la quota giornaliera di template e con un flusso di order confirmation in grado di ridurre i tassi di reso COD.

Il problema: WhatsApp non è email

Il primo errore quando si imposta una strategia WhatsApp è trattarlo come email. WhatsApp ha vincoli operativi diversi: i template devono essere pre-approvati da Meta, ogni invio extra-finestra-conversazionale ha un costo per messaggio, esistono quote orarie sul tier del numero, e una percentuale anomala di “reported as spam” può portare a un downgrade del rating della numerazione, fino al blocco. Questo significa che l’architettura tecnica deve gestire approval status, throttling, audience filtering, e — soprattutto — deve impedire al marketing team di lanciare campagne con un click che potrebbero bruciare l’asset numerazione.

Architettura: tre livelli che lavorano insieme

L’architettura che funziona si articola su tre livelli: gestione dei template, materializzazione delle audience, invio controllato.

Il livello template è la fonte di verità sui template WhatsApp approvati. Spoki espone l’API per leggere status, language e variabili dei template. Sincronizzando questa informazione localmente, l’UI di creazione campagna può prevenire scelte errate (es. selezionare un template in stato “Pending” o con variabili mancanti). Sembra ovvio, ma è la fonte numero uno di errori operativi nel team marketing.

Il livello audience è dove vive l’integrazione con il CRM ecommerce. La differenza tra una campagna mediocre e una efficace è il segmento. Per il brand di cui parlo abbiamo definito quindici segmenti dinamici basati su comportamento di acquisto (es. “ha comprato cibo umido negli ultimi sessanta giorni”, “ha un ordine COD in attesa di consegna”, “carrello abbandonato sopra i quaranta euro”). Quando il marketing lancia una campagna, il sistema materializza l’audience in quel preciso momento, salvando lo snapshot dei contatti e degli eventuali parametri (es. nome animale, prodotto suggerito). Questa materializzazione è fondamentale perché evita che un cambio del segmento durante l’invio scombussoli i risultati e perché rende la campagna ripetibile e auditable.

Il livello sender è il worker che esegue l’invio. Qui sta il pezzo tecnico più importante: il throttling intelligente. Spoki impone un limite di invii per minuto/ora basato sul tier della numerazione. Superare questo limite genera errori 429 e — peggio — incide negativamente sulla reputation. Il worker che ho costruito calcola dinamicamente il rate di invio sulla base di tre variabili: tier attuale del numero, percentuale di template già usata nelle ultime ventiquattro ore, e timezone della destinazione (non spedire alle tre di notte). Se la campagna è grande — diciamo trentamila destinatari — il worker la distribuisce in modo intelligente su sei-otto ore, mantenendo throughput sostenibile e finestre di delivery in orari sensati.

Il flusso order confirmation: il caso COD

Il caso d’uso che produce il ROI più chiaro su WhatsApp non è la campagna promozionale, è la conferma ordine, soprattutto in mercati con peso COD elevato. La meccanica è semplice ma il dettaglio operativo fa la differenza.

Quando arriva un ordine COD, Shopify emette un webhook. L’integrazione cattura l’evento, taggata l’ordine come COD, e — se il cliente ha consenso WhatsApp e numero verificato — invia un template di conferma con riepilogo ordine, indirizzo di spedizione, importo e una call-to-action per confermare o modificare. Il cliente risponde all’interno della conversazione, e questa risposta apre la finestra delle ventiquattro ore in cui si possono mandare messaggi liberi senza costo template.

L’effetto sui resi COD è significativo. Su un volume mensile di circa milleottocento ordini COD, l’introduzione del flusso di conferma WhatsApp ha portato a una riduzione misurabile dei pacchi rifiutati alla consegna, perché l’indirizzo viene verificato prima della spedizione e il cliente è “scaldato” alla consegna imminente. Il risparmio in costi di logistica e gestione resi copre largamente il costo dei template.

Backfill conversazioni e sync contatti: la parte noiosa ma indispensabile

Una piattaforma WhatsApp ecommerce ha bisogno di due funzioni meno glamour ma critiche: il sync contatti bidirezionale tra CRM e Spoki, e il backfill conversazioni per numero quando il customer service apre una scheda cliente. Senza queste due, l’agente CS che riceve una chiamata da un cliente WhatsApp non sa cosa è stato detto nelle ultime conversazioni e tratta il cliente come nuovo.

Il sync contatti deve essere idempotente e gestire i conflitti: il numero in Spoki è la chiave naturale, ma la fonte di verità sui dati di anagrafica (nome, lingua, marketing consent) è il CRM ecommerce. Il backfill conversazioni invece è interrogazione on-demand: quando l’agente apre la scheda, il sistema recupera dalla API Spoki lo storico messaggi per quel numero e lo presenta in cronologia.

Stack tecnico e scelte di design

Lo stack che ho usato: Supabase Edge Functions in Deno per il backend, React/Lovable per l’UI di gestione campagne e template, Spoki API per l’integrazione WhatsApp Business, un background worker dedicato per il sender throttled, Shopify webhook per la triggerizzazione degli order confirmation. Il database Postgres ospita lo stato delle campagne, l’audience materializzata, la conversation history sintetica e i metadati di throttling.

La scelta di mettere il sender su worker dedicato anziché su Edge Function è stata dettata dal pattern: il sender deve mantenere stato di rate (quanti template inviati negli ultimi 60 minuti, quanti negli ultimi 24h) e questa stato fuori-richiesta è scomodo da gestire in Edge Function. Un worker che gira in loop con backpressure è molto più semplice e affidabile.

Take-away

Tre cose da ricordare se state valutando di automatizzare WhatsApp Business in un ecommerce italiano. Primo: il throttling non è un’opzione, è un requisito. Una campagna che brucia il tier della vostra numerazione vale molto meno del danno che fa. Costruite il sender con throttling dinamico fin dal primo giorno. Secondo: la fonte di valore principale non è la campagna outbound, è il flusso transazionale (conferma ordine, spedizione, follow-up post-acquisto). Iniziate da lì, è dove il ROI si vede subito e dove i tassi di engagement giustificano l’investimento. Terzo: trattate i template come asset versionati. Mantenete uno staging dei template, fate review prima di sottoporli a Meta per approvazione, e mantenete un log di quale campagna ha usato quale versione. Senza questo, sei mesi dopo nessuno saprà perché un certo template performa diversamente da prima.