Fine Stagione Moda Senza Sprechi: l'Architettura n8n + Claude per Dynamic Pricing e Recovery Email su 2.000 SKU

19 agosto 2026 — Cosmio Team

Come costruire un workflow n8n che monitora il sell-through rate settimanale, applica dynamic pricing progressivo e invia email di recovery generate da IA, per ridurre lo spreco di margine sul residuo stagionale.

Due volte l'anno, un e-commerce di moda con 2.000 SKU affronta lo stesso momento critico: la fine stagione. Senza un sistema che monitori il sell-through in tempo reale, le decisioni sui saldi si basano sull'istinto del buyer, gli sconti partono in ritardo rispetto alla curva di domanda reale, e una parte consistente dello stock finisce svenduta sottocosto perché nessuno ha agito abbastanza presto. Il risultato è un margine bruciato che si ripete identico stagione dopo stagione, perché il processo resta manuale.

Questo articolo mostra come costruire un workflow n8n che collega Shopify (o WooCommerce), Klaviyo e Slack per automatizzare il monitoraggio del sell-through, il dynamic pricing progressivo e le email di recovery verso chi ha visto un prodotto più volte senza acquistarlo — con un modello linguistico che genera i testi delle email contestualizzati per segmento.

TL;DR — Executive Summary - Il sell-through rate per categoria/taglia/colore va monitorato settimanalmente via API, non stimato a occhio a fine stagione - Un workflow n8n può applicare sconti progressivi automatici (-10% → -20% → -30% → liquidazione) su soglie configurabili, evitando sia il ritardo sia l'eccesso di sconto - Le email di recovery generate da un LLM su segmenti comportamentali (visualizzato 2x, non acquistato) recuperano parte della domanda prima che serva il markdown più aggressivo - Il costo di mantenere lo stock invenduto in magazzino, secondo benchmark di settore, può arrivare al 30-40% annuo del valore dell'inventario per il fashion stagionale — un dato spesso non calcolato esplicitamente da chi gestisce il catalogo

Il tuo magazzino di fine stagione ha questo problema?

• Scopri lo stato reale del sell-through di una categoria solo quando il buyer fa un giro fisico in magazzino o guarda il report mensile, non settimanale?
• Le percentuali di sconto di fine stagione (-10%, -20%, -30%) vengono decise a tavolino una volta e restano fisse, indipendentemente da come si muove davvero lo stock?
• Non hai un elenco automatico di clienti che hanno visualizzato più volte un prodotto in saldo senza comprarlo, da recuperare con una comunicazione mirata?
• Il buyer scopre di avere 300+ pezzi fermi solo quando è già troppo tardi per intervenire con margine?

Se hai risposto Sì a 3 o più domande, il collo di bottiglia descritto in questo articolo sta probabilmente impattando la tua marginalità di fine stagione — le sezioni seguenti mostrano come quantificarlo e affrontarlo. Se hai risposto Sì a meno di 2, il tuo processo è già più maturo della media: le sezioni seguenti possono comunque rivelare ottimizzazioni incrementali sulla granularità del pricing.

Diagnosi del Collo di Bottiglia: Perché il Residuo Costa Così Tanto

Secondo un'analisi McKinsey sul retail moda, un brand in salute dovrebbe entrare in saldo con un sell-through full price tra il 50% e il 60%, e chiudere la stagione tra l'80% e l'85%. Sotto il 60% a fine stagione, la maggior parte dei buying team dovrebbe già aver attivato markdown; sotto il 40%, servono sconti aggressivi oltre il 50% per liquidare. Il problema non è il concetto — quasi tutti i buyer lo conoscono — ma la capacità di misurarlo per categoria/taglia/colore ogni settimana e reagire di conseguenza, invece che una volta al mese guardando il totale.

Su un fatturato stagionale di €400.000 con un residuo del 25% (€100.000 di stock immobilizzato), lo scenario tipico senza automazione del pricing vede circa il 40% finire in liquidazione sottocosto, il 35% restare fermo in magazzino tra un cambio stagione e l'altro, e solo il 25% vendersi con margine positivo. I benchmark di settore sul carrying cost per il fashion — tra il 20% e il 40% annuo del valore dell'inventario, spinto verso l'alto dall'alta stagionalità e dal rischio obsolescenza — significano che ogni settimana aggiuntiva di residuo fermo ha un costo reale, non solo un costo opportunità astratto. Aggiungendo il costo del capitale immobilizzato (€100.000 per 6 mesi al 4-6% annuo di costo del credito aziendale, circa €2.000-3.000), il conto complessivo della gestione reattiva del residuo cresce oltre la sola perdita di margine sullo sconto.

Soluzione Implementativa: il Workflow n8n Passo per Passo

L'architettura di riferimento per un catalogo tra 500 e 3.000 SKU su Shopify Plus o WooCommerce si basa su n8n self-hosted, orchestratore no-code/low-code che si collega via HTTP node alle API di Shopify Admin (endpoint Product e Price), Klaviyo per la segmentazione comportamentale e Slack per gli alert operativi. Make (ex Integromat) resta un'alternativa valida per prototipare il workflow rapidamente senza gestire infrastruttura, ma per dati comportamentali di clienti UE il self-hosting di n8n offre un controllo più diretto su dove risiedono i dati — un elemento rilevante ai fini GDPR.

Il workflow gira settimanalmente (es. domenica sera) e si articola in quattro nodi principali:

1. Nodo Trigger + Query Shopify API — recupera per ogni categoria/taglia/colore lo stock residuo e le vendite della settimana, calcola il sell-through rate corrente.
2. Nodo Decisione (soglie configurabili) — confronta il sell-through con le soglie definite (es. sotto il 5% a T+6 settimane dall'inizio fine stagione → sconto -15%); se la soglia è superata, procede allo step successivo.
3. Nodo Shopify API PATCH price — applica lo sconto sui SKU della categoria interessata.
4. Nodo Klaviyo + Slack — attiva il segmento comportamentale per la recovery email e invia il report al buyer.

Ecco un esempio concreto di esecuzione, domenica ore 23:00:

Input: query Shopify API sulla categoria "Giacche Primavera/Estate" — 340 pezzi rimasti, sell-through rate della settimana corrente 3,2% (target configurato: 8%), T-21 giorni alla chiusura stagione. Soglia di intervento configurata: sell-through inferiore al 5% dopo T+6 settimane.

{
  "trigger": "weekly_sunday_23:00",
  "category": "Giacche Primavera/Estate",
  "remaining_units": 340,
  "current_sell_through": 0.032,
  "threshold": 0.05,
  "weeks_since_start": 6,
  "action": "apply_discount",
  "discount_pct": -0.15,
  "skus_affected": 47
}

Nodo 1 — Shopify API PATCH price: -15% su tutti i 47 SKU della categoria. Nodo 2 — Klaviyo API: trigger sul segmento "Viewed Giacche >2x, no purchase last 30d", invio email generata con testo contestuale (subject e body). Nodo 3 — Google Sheets append: log di timestamp, SKU, prezzo precedente, nuovo prezzo, quantità residua — traccia storica utile per la stagione successiva. Nodo 4 — messaggio Slack: "#ecommerce-ops: 340 pz giacche P/E sotto soglia. Pricing -15% attivato su 47 SKU. Recovery rate stimata +18% vs baseline. Review lunedì mattina."

Questa architettura tecnica applica alla logistica dello sconto la stessa disciplina già descritta per la riduzione dei resi nei negozi di moda: dati granulari, soglie configurabili, intervento automatico invece di decisione reattiva.

Come usare l'IA Generativa per generare le email di recovery

Il nodo HTTP di n8n può chiamare l'API di un modello linguistico per generare il testo della recovery email contestualizzato per ogni segmento, invece di usare un template fisso per tutti i clienti. Il flusso è: input (lista SKU in promozione, segmento target — es. "visualizzato 2x, donna 30-45, area Milano", giorni rimasti a fine stagione) → prompt strutturato → output (3 varianti di subject line + corpo email HTML di circa 200 parole, con tono di urgenza calibrato sul segmento).

Un prompt tipo: "Genera 3 varianti di subject line (max 50 caratteri) e un corpo email HTML di 200 parole per il segmento [descrizione segmento], che ha visualizzato [prodotto] senza acquistare. Il prodotto è ora scontato del 15%, mancano [N] giorni a fine promozione. Tono: urgenza moderata, non aggressivo, in linea con un brand fashion di fascia media."

Per questo caso d'uso — testo breve, alto volume di varianti da generare in batch settimanale — l'ultimo modello Claude di Anthropic è indicato quando si vogliono email coerenti su decine di segmenti in un'unica chiamata batch grazie alla gestione di contesto esteso, mentre l'ultimo modello ChatGPT di OpenAI è una scelta altrettanto valida se il team ha già un'integrazione esistente via API OpenAI e preferisce non introdurre un secondo provider. Il software di settore (Klaviyo) resta il motore di invio e segmentazione: l'LLM colma solo il gap della personalizzazione del copy, che altrimenti richiederebbe un copywriter a intervenire ogni settimana per ogni segmento attivo.

Azioni immediate (questa settimana, senza cambiare software)

1. Esporta da Shopify o WooCommerce il report vendite/stock per SKU dell'ultima fine stagione ed calcola il sell-through per categoria: (venduto ÷ stock iniziale) nelle prime 8 settimane. Questo numero, non l'impressione del buyer, è la base per tarare le soglie di automazione.
2. Confronta il risultato con il benchmark di settore (target 80-85% a fine saldi secondo McKinsey): le categorie sotto il 60% a T+6 settimane sono quelle su cui il markdown sarebbe dovuto partire prima.
3. Scrivi su carta il decision tree delle soglie: sotto quale sell-through a T+4 scatta il primo sconto? A T+6? A T+8? Questo schema, anche in Excel, diventa direttamente la logica condizionale del nodo Decisione nel workflow n8n.

Se hai calcolato il sell-through delle ultime due stagioni e trovato categorie sistematicamente sotto soglia, il questionario di Analisi IA incrocia questi dati con benchmark tecnici di settore per stimare l'effort di automazione nel tuo caso specifico.

Quale approccio per la tua realtà

Per il monitoraggio competitor durante i saldi, Prisync (piani indicativi $59-179/mese, oltre 1.000 siti monitorati, repricing a regole con aggiornamento giornaliero) è la scelta pragmatica per chi ha meno di 3.000 SKU e vuole partire rapidamente senza un progetto di onboarding lungo. Omnia Retail, con repricing assistito da IA e integrazione nativa con comparatori come Google Shopping e marketplace europei, è preferibile per cataloghi enterprise con migliaia di SKU su più canali, a fronte di un pricing custom e un periodo di onboarding più lungo.

Dubbi Frequenti

"I dati comportamentali dei clienti (prodotti visualizzati, wishlist) sono dati personali: come si gestisce il GDPR?" Klaviyo va configurato con data residency EU quando disponibile, e l'email del cliente non va mai passata insieme all'ID prodotto a un LLM pubblico senza una fase di anonimizzazione preventiva. Per la generazione del copy email, il prompt inviato al modello deve contenere solo la descrizione del segmento aggregato (es. "donna 30-45, area Milano") e i dati del prodotto, mai identificativi diretti del singolo cliente. Vanno usate esclusivamente versioni Enterprise/Business degli LLM (Claude for Work, ChatGPT Enterprise, Gemini for Google Workspace), che non utilizzano i dati per l'addestramento dei modelli, e va verificato il DPA (Data Processing Agreement) del fornitore: l'azienda resta titolare del trattamento anche quando usa strumenti IA di terze parti.

"Il pricing dinamico può sbagliare e applicare sconti errati?" Il workflow descritto non decide in autonomia assoluta: le soglie sono configurate manualmente dal buyer e il nodo Slack invia sempre un alert prima che lo sconto diventi operativo se si imposta una fase di conferma. L'architettura human-in-the-loop resta la configurazione consigliata nelle prime stagioni di utilizzo, per validare che le soglie riflettano davvero la strategia commerciale.

"Serve un team tecnico interno per mantenere questo workflow?" n8n self-hosted richiede competenze base di gestione server (o un hosting gestito) e familiarità con API REST per configurare i nodi iniziali; una volta impostato, la manutenzione settimanale è minima. Per chi non ha risorse DevOps interne, Make riduce la complessità di setup a costo di minore flessibilità sulle logiche condizionali complesse.

Dove questo approccio ha dei limiti

Questa architettura non funziona bene su cataloghi sotto le 500 SKU, dove il volume di dati settimanali è troppo basso per soglie statisticamente affidabili: in quel caso conviene restare su decisioni manuali supportate da report semplici. Non è adatta a chi non ha ancora uno storico di almeno una stagione di vendite per categoria/taglia/colore, perché le soglie configurate senza dato storico rischiano di essere arbitrarie quanto la gestione manuale che sostituiscono. Infine, il pricing dinamico automatizzato non sostituisce una strategia di buying: se l'acquisto iniziale è sistematicamente sovradimensionato rispetto alla domanda, l'automazione accelera la liquidazione ma non risolve la causa a monte.

In Sintesi

L'esempio del workflow mostrato — dalla query settimanale del sell-through fino all'alert Slack per il buyer — dimostra che il problema del residuo di fine stagione non è la mancanza di strategia, ma la mancanza di un sistema che applichi quella strategia in modo coerente ogni settimana, categoria per categoria. Le aziende che hanno già mappato le proprie automazioni prioritarie per l'e-commerce moda trovano nel dynamic pricing di fine stagione uno dei workflow a ritorno più diretto, perché agisce su un evento che si ripete identico due volte l'anno. Chi vuole verificare come questa architettura si adatta al proprio catalogo, al proprio stack (Shopify, WooCommerce, gestionale interno) e al volume reale di SKU può usare il questionario di Analisi IA per ottenere un assessment tecnico personalizzato, partendo esattamente dai dati di sell-through calcolati nel punto 1 delle azioni immediate. Per una panoramica più ampia sulle automazioni possibili nel settore, la guida 2026 all'automazione IA per l'e-commerce di moda copre anche i processi a monte e a valle di quello descritto qui, mentre la sezione e-commerce del blog raccoglie i casi analoghi sviluppati per altri verticali di vendita online.