Servizio · AI per team ecommerce

Agenti AI costruiti sui processi del tuo team ecommerce

Sistemi ad agenti sui processi che costano più ore a un team ecommerce, collegati via MCP a Figma, Jira, Storybook e analytics già in uso. Agenti in produzione, regole scritte che restano al team, una persona che conferma ogni decisione.

Come funziona

Dai processi agli agenti, in cinque capitoli

01 / 05 · Dove finiscono le ore

Il lavoro che non chiede giudizio, solo una persona

Benchmark, ticket, report, regressioni: passaggi sempre uguali che nessuno aveva mai scritto. È la parte meccanica del lavoro di un team ecommerce, ed è quella che ho affidato agli agenti.

Ogni settimana si separa in due colonne: quello che richiede il giudizio di una persona e quello che richiede solo una persona. Agli agenti va la seconda.
- Giudizio
- Esecuzione
- Processi ripetuti
Settimana di un team ecommerceChi fa cosa
Richiede giudizio · persone 4
Decidere cosa testare e perché
Scegliere le priorità del backlog
Approvare un componente nuovo
Dire sì a un prototipo
Richiede solo una persona · agenti 4
1 giornoCatturare 15-20 concorrenti
1,5 oreTradurre mockup in ticket Jira
2-4 oreDiagnosi quando scende un KPI
ogni rilascioRegressione dopo ogni release
Tre processi misurati prima e dopo, in minuti. Gli agenti fanno i passaggi; il team legge il risultato e decide.
- Prima e dopo
- Tempi reali
- Minuti
Tempo per esecuzione · prima e dopoTre processi, in minuti
Benchmark UX su 15-20 siti1 giorno5-10 min
Handoff design → Jira1,5 ore4 min
Diagnosi comportamentale2-4 ore< 5 min
primadopo
Team ecommerce interni dove UX, frontend e delivery si sovrappongono. Chi possiede il processo, chi risponde della roadmap, chi decide come far entrare l'AI senza un sistema parallelo.
- UX e product lead
- Head of ecommerce
- CTO
A chi si rivolgeHa senso se
UX o product leadpossiede il processo e le regole
Head of ecommercerisponde della roadmap e dei tempi
CTOdecide come entra l'AI, senza sistemi paralleli
Brand che rifà l'esperienzalo stesso design system consegna i redesign in codice
Chi cerca una piattaforma pronta in un giornoqui il lavoro vero è scrivere il giudizio del team
Niente piattaforma nuova: gli agenti lavorano dentro Figma, Storybook, Jira, Contentsquare, GA4 e BrowserStack, collegati via Model Context Protocol.
- Figma
- Storybook
- Jira
- Contentsquare
- GA4
- BrowserStack
Lo stack del teamResta quello che c'è
01Figma e StorybookDesign system, mockup, commenti, componentiDesign
02JiraEpic, Story, Task e SubtaskDelivery
03Contentsquare e GA4Funnel, sessioni, segnali di frustrazioneDati
04BrowserStack e PlaywrightBrowser e dispositivi realiQualità
05Claude + MCPLo strato che li collega, con permessi dichiaratiAgenti

un benchmark UX su 15-20 siti, consegnato in Figma: 1 giorno → 5-10 min
dal file Figma a Jira, criteri di accettazione inclusi: 23 ticket in 4 min
una diagnosi comportamentale, già ordinata per priorità: 2-4 ore → < 5 min

Vedi i processi ottimizzati →

02 / 05 · Come un team adotta gli agenti

Quattro passaggi, in quest'ordine

Prima di scrivere una riga si decide su quale processo lavora l'agente, con quali regole, a quali strumenti accede e dove si ferma. L'ordine è la differenza tra un sistema che il team possiede e una demo.

Si parte dal processo che costa più ore e ha meno bisogno di giudizio, non da un ruolo o da uno strumento. Un sistema alla volta, misurato contro quello che sostituisce.
- Mappa dei processi
- Tempi reali
- Un sistema alla volta
Da dove partireOre a settimana · ripetitivo · senza giudizio · strumenti già collegabili
Benchmark Ticket Jira Regressione Priorità backlog
Ore a settimana 8 3 4 2
Passaggi sempre uguali 1 1 1 0
Non serve giudizio 1 1 1 0
Strumenti via MCP 1 1 1 1
Punteggio 11 6 7 3

	Benchmark	Ticket Jira	Regressione	Priorità backlog
Ore a settimana	8	3	4	2
Passaggi sempre uguali	1	1	1	0
Non serve giudizio	1	1	1	0
Strumenti via MCP	1	1	1	1
Punteggio	11	6	7	3

Le regole che il team applica senza accorgersene diventano testo: come si giudica una pagina, quali mercati, cosa non si fa mai. Restano al team, qualunque modello usi domani.

File di contesto
Regole di business
Ipotesi, non fatti

contesto/benchmark-ux.mdFile di contesto · Esempio

1# Come giudichiamo una PDP23## Mercati: IT, DE, FR, US · 15 lingue · prezzi per paese4## Criteri (Baymard, NN/g, riferimenti interni)5- Taglie: guida visibile prima dell'add to cart6- Prezzo barrato: mai più di un badge promozionale7- Resi e spedizione: dichiarati sopra la piega su mobile8## Problemi noti (ipotesi da verificare, non fatti)9- Abbandoni sulla selezione taglia da mobile10## Cosa non fare11- Non modificare file Figma, dati o campagne12- Non ordinare per priorità: proporre, poi chiedere

L'agente si collega via MCP agli strumenti già in uso, senza esportare dati. Dove basta leggere è sola lettura; dove si scrive, si scrive dopo una conferma.
- MCP
- Permessi dichiarati
- Sola lettura
- Scrittura dopo conferma
Permessi dell'agenteVia MCP
01Figma e StorybookMockup, commenti e comportamento reale dei componentiLettura
02Contentsquare e GA4Funnel, sessioni, segnali di frustrazione, segmentiSola lettura
03BrowserStack e PlaywrightFlussi eseguiti su browser e dispositivi realiEsecuzione
04JiraEpic, Story, Task e Subtask già scrittiScrittura dopo conferma
Un agente che ordina le priorità ha già preso una decisione di business, in silenzio. Ogni sistema raccoglie, sintetizza e propone; una persona conferma prima che si apra un ticket.
- Confine dichiarato
- Conferma umana
- Misura contro il prima
Dove si ferma l'agenteDue modi di costruirlo
Agente che decide
Legge i dati e sceglie cosa conta
Ordina le priorità da solo
Apre i ticket nel backlog
Il team lo scopre dopo
Agente che propone
Legge i dati e sintetizza
Propone un piano, con le evidenze
Una persona conferma
Solo allora apre i ticket
Un numero alto non è una priorità alta: prioritizzare resta a chi conosce il business.

per ogni sistema: il più pesante, misurato prima e dopo: 1 processo
per mettere in produzione il design system agentico: 2 settimane
su ogni azione che scrive, apre un ticket o decide: 1 conferma umana

Il processo: Claude + Figma + Jira →

03 / 05 · I sei sistemi

Sei agenti in produzione, per il lavoro che tolgono di mezzo

Design system agentico, Figma e Storybook via MCP, benchmark, Jira, PM agent, BrowserStack con Playwright. Ognuno collegato agli strumenti che il team usava già; per ognuno è scritto cosa riceve il team.

Token e un contratto per ogni componente, in un repository che leggono team e agente. Claude legge il file Figma e i componenti su Storybook: lavora sul design system vero, non su uno screenshot.
- Figma MCP
- Storybook
- Repository unico
- Articolo: design system agentico
Cosa riceve il teamDesign system agentico
Repository con token, contratti, codice e test
Playground per rivedere i prototipi nel browser
Connessioni MCP a Figma e Storybook, permessi dichiarati
Controlli automatici che decidono cosa entra
Costruito in 2 settimane sopra la libreria esistenteredesign da 1 mese a 1 settimana
Anni di criteri UX, da Baymard e NN/g, scritti in file che l'agente usa come giudizio. Cattura 15-20 concorrenti desktop e mobile, commenta e salva in Figma.
- Browser automation
- Figma MCP
- Articolo: benchmark con agente AI
Claude · benchmarkEsempio
Benchmark della selezione taglia su PDP: 15 concorrenti, desktop e mobile, con i nostri criteri.
15 siti · 30 screenshot · salvati in Figma
Guida taglie visibile prima dell'add to cart: 6 su 15. Do e don't commentati su ogni cattura.
Nessun sito risolve il caso taglia esaurita da mobile: ipotesi da verificare sui nostri dati.
Tempo: 8 minuti. Nessun file Figma modificato oltre la pagina del benchmark.
Vuoi che proponga tre test da questo benchmark?

Legge mockup e commenti da Figma, ricostruisce struttura, stati e interazioni, e propone Epic, Story, Task e Subtask con criteri di accettazione. La prima volta: 23 ticket in quattro minuti.

Figma MCP
Jira
Articolo: 23 ticket in 4 minuti

jira/proposta-sprint-14.md23 ticket · in attesa di conferma

1EPIC  Scheda prodotto mobile · nuova collezione2  STORY  Selezione taglia con guida visibile3    TASK  SizePicker: stati default, esaurita, selezionata4    TASK  SizeGuide: apertura in sheet, chiusura, focus5    SUB   Criteri: target touch ≥ 44 px, errore inline6  STORY  Spedizione e resi sopra la piega7    TASK  ShippingNote: varianti per mercato (IT, DE, FR, US)8  STORY  Prodotti correlati9    TASK  ProductCard: badge promozionale, massimo uno10...11Priorità: non assegnata. Conferma per aprire su Jira →

Il PM agent prende appunti nelle riunioni, propone ticket e bozze di documenti, passa in rassegna la posta. Playwright esegue i flussi critici su browser e dispositivi reali dopo ogni release.
- Jira
- n8n
- BrowserStack MCP
- Playwright
Dopo ogni releaseRegressione e follow-up
Release in produzioneDecisione
Flussi critici eseguiti su browser e device realiAutomatizzato
Report: cosa si è rotto, doveAutomatizzato
Scoperto da un clienteEliminato
PM agent propone i ticket dal reportAutomatizzato
Una persona confermaDecisione

ad agenti in produzione per il lavoro di un team ecommerce: 6 sistemi
alla prima esecuzione dell'agente Jira: 23 ticket in 4 min
Best Use of AI, Digital Experience Awards 2026 di Contentsquare: 1° premio

Leggi: 23 ticket in 4 minuti →

04 / 05 · Il design system agentico

Un design system che leggono le persone e gli agenti

Un design system tradizionale vive nelle review e nella testa di chi c'è da più tempo. Qui le regole si scrivono una volta, e il prototipo nasce in codice prima di Figma.

I token si estraggono dalla libreria Figma come valori e come significati. Poi un contratto per componente: scopo, stati, composizioni, cosa non fare mai, accessibilità.

Design token
Contratto di componente
Accessibilità

tokens/semantic.json · components/Card.contract.mdEsempio

1"surface.card.elevated": {2  "value": "{color.neutral.900}",3  "meaning": "sfondo di una card sollevata dal piano",4  "pairWith": ["text.onSurface", "elevation.2"]5}67## Card · contratto8- Scopo: raggruppare un contenuto autonomo e cliccabile9- Stati: default, hover, selezionata, in caricamento10- Mai: due badge promozionali sulla stessa card11- A11y: target touch ≥ 44 px, focus visibile

Claude compone usando solo i componenti che esistono. Se ne serve uno nuovo lo propone con il contratto: la decisione resta a una persona.
- Figma MCP
- Storybook
- Proposte, non invenzioni
Claude · composizioneEsempio
Componi la scheda prodotto mobile per il lancio della nuova collezione, con i componenti del design system.
Composta con 9 componenti esistenti
Gallery, Price, Swatches, SizePicker, Button, Accordion, ShippingNote, Badge, ProductCard (correlati).
Manca un componente per la guida alle taglie: non lo invento. Propongo SizeGuide, con contratto allegato, da approvare.
Tipi, test e controlli di accessibilità: passati.
Approvi il nuovo componente?
Il prototipo prende forma in un playground Next.js su Vercel, cliccabile da desktop e telefono con i prodotti del catalogo. Il team rivede e approva lì.
- Playground Next.js
- Brief, non prompt
- Revisione nel browser
Playground · scheda prodottoPrototipo in codice
Il sì si dà qui, nel browser; poi il lavoro arriva su Figma e Storybook già pronto per lo sviluppo.
Tipi, test e accessibilità devono passare prima che qualcosa entri nel repository. Figma e Storybook si aggiornano solo dopo il sì nel playground.
- TypeScript
- Test
- Approvazione esplicita
Cosa entra nel design systemIl cancello
Brief scritto da una personaDecisione
Composizione con componenti esistentiAutomatizzato
Tipi, test e accessibilità: devono passareAutomatizzato
Componente inventato senza contrattoEliminato
Approvazione del team nel playgroundDecisione
Figma e Storybook aggiornati dopo il sìAutomatizzato

per costruirlo sopra la libreria Figma che c'era già: 2 settimane
per un redesign completo, da 2-3 persone a una: 1 mese → 1 settimana
di lavoro recuperati su ogni redesign: 35-55 giorni

Leggi come è nato il design system agentico →

05 / 05 · Perché conviene

Un sistema sul processo, non una piattaforma da adottare

Una piattaforma AI o un'agenzia vendono un prodotto che il team deve adottare. Un sistema costruito sul processo parte da quello che il team fa già, e gli lascia regole, conoscenza e decisione.

La piattaforma lo impara dal brief e lo adatta al proprio prodotto. Qui il sistema nasce dalla mappa dei processi come girano davvero, con i tempi misurati prima.
- Mappa dei processi
- Tempi misurati
Da dove parte il sistemaPiattaforma o agenzia · sistema sul processo
Dal briefPiattaforma o agenzia
Dai tempi realiSistema sul processo
Un benchmark da un giorno a 5-10 minuti si misura solo se il giorno è stato misurato prima.
In file di testo nel repository del team, non nella piattaforma né nella testa di un consulente. Chi aggiunge un componente aggiunge il contratto, chi cambia una regola la cambia nel file.
- Repository del team
- File di contesto
- Nessuna licenza
Cosa resta al teamAlla fine del lavoro
File di contesto e criteri di giudizioal team
Contratti dei componenti e tokenal team
Permessi MCP dichiarati per strumentoal team
Agenti in produzione e formazioneal team
Licenza di piattaforma0
Configurazioni nel prodotto di un fornitore0
Conoscenza che se ne va a fine contratto0
Il valore sta in quello che il modello legge: contesto, regole, contratti, permessi. Cambiare modello è una configurazione, non un progetto da rifare.
- Modello intercambiabile
- Testo di proprietà del team
Esce un modello nuovoDue scenari
Piattaforma o agenzia
Si aspetta la roadmap del fornitore
Si rifà il progetto sul modello nuovo
Le regole vanno riscritte
Sistema sul processo
Si cambia una riga di configurazione
Il modello nuovo legge gli stessi file
Si misura contro il precedente
Stesso contesto, stesse regole, stessi permessi: il modello è il pezzo più facile da sostituire.
Una persona. L'agente raccoglie, sintetizza e propone; senza conferma non si apre un ticket e non entra un componente nel design system.
- Conferma umana
- Permessi revocabili
Governance degli agentiUltimo sprint · Esempio
Ticket aperti senza conferma0
Proposte in attesa di una persona3
Componenti proposti → approvati2 → 1
Permessi revocabili in qualsiasi momento100%

Best Use of AI, Digital Experience Awards 2026, per il workflow Contentsquare + Claude: 1° premio
da comprare: il costo è progettazione, scrittura e costruzione: 0 licenze
dove un dato diventa una decisione: 1 conferma umana

Vedi il workflow premiato →

Formati

Formato 01

Assessment dei processi

Mappa dei processi con tempi reali e lista di cosa automatizzare, eliminare o lasciare alle persone.

Alcune settimane

Formato 02

Un sistema sul processo più pesante

Agente in produzione via MCP, regole scritte di proprietà del team, misura contro il processo precedente.

Alcune settimane

Formato 03

Affiancamento continuativo

Un sistema in più a ogni ciclo, regole aggiornate quando cambia il business o il modello.

Fractional, a giornate nel mese

Domande frequenti

Che cos'è un design system agentico?

Un design system le cui regole leggono sia le persone sia gli agenti: token leggibili da una macchina e un contratto per ogni componente. L'agente compone a partire da quella specifica e i controlli automatici decidono cosa entra.

Questi agenti sostituiscono designer e ricercatori?

No: tolgono la parte già meccanica, come catturare schermate, scrivere ticket e rifare i controlli su ogni browser. Ogni priorità di business e intenzione di design resta a una persona.

Quanto ci vuole per vedere la differenza?

Il primo sistema nasce sul processo che costa più ore, quindi si vede subito. Il design system agentico ha richiesto due settimane; un redesign è passato da un mese a una settimana.

Funziona con gli strumenti che usiamo già?

È il presupposto: Figma, Storybook, Jira, Contentsquare, Google Analytics, BrowserStack e il repository, quasi sempre via MCP. Nessuno abbandona il proprio stack.

Cosa deve mettere sul tavolo il mio team per partire?

Conoscenza che esiste già ma che nessuno ha scritto: come giudicate una pagina, a cosa servono i componenti, in cosa sono diversi i mercati. Scriverla è il lavoro vero.

Per chi è?

Team ecommerce dove UX, frontend e delivery si sovrappongono: UX o product lead, head of ecommerce, CTO. E per i brand che rifanno l'esperienza: lo stesso design system consegna i redesign in codice. UX redesign in codice →

I dati restano nei nostri strumenti?

Sì: gli agenti leggono i dati dove stanno già, via MCP con permessi dichiarati per strumento. Niente database parallelo, e i permessi si revocano in qualsiasi momento.

Serve una piattaforma nuova?

No. Si aggiungono file di testo con le regole, le connessioni MCP e gli agenti che le usano: nessuna licenza né interfaccia nuova da imparare.

Cosa succede quando cambia il modello?

Il valore sta nei file che il modello legge: cambiare modello è una configurazione, non un progetto da rifare.

Chi mantiene gli agenti dopo?

Il team, con regole scritte, permessi documentati e formazione; resto finché il sistema non gira senza di me. Per estendere il metodo c'è l'affiancamento continuativo.