Casi reali

Business fisico — integrare due reti commerciali

Due reti commerciali nate con logiche differenti, responsabilità distribuite per canale e condizioni non sempre omogenee stavano rendendo più complessa la gestione del territorio, sia internamente sia nei rapporti con agenti e clienti.

Il lavoro è partito dalla struttura: superare un modello fortemente centralizzato, basato su responsabili di canale, e passare a una gestione più vicina al territorio attraverso Area Manager con responsabilità più chiare e una lettura complessiva delle rispettive aree.

Parallelamente è stato necessario intervenire sulle condizioni commerciali, sulle scontistiche e sulle eccezioni accumulate nel tempo, cercando un equilibrio tra continuità commerciale, sostenibilità e semplicità di gestione.

L'obiettivo non era semplicemente unire due reti, ma costruire un sistema più leggibile: meno sovrapposizioni, maggiore chiarezza delle responsabilità e condizioni più coerenti verso l'esterno.

Il risultato è stato un modello più semplice da governare internamente e più comprensibile per agenti e clienti, con meno ambiguità nella gestione quotidiana.

E-commerce — costruire un assortimento sostenibile

Portare un catalogo tradizionale su un canale e-commerce non significa semplicemente pubblicare più prodotti possibile.

In questo caso il punto di partenza era un assortimento molto ampio, con referenze profondamente diverse per prezzo, disponibilità, costi logistici e sostenibilità economica. Alcuni prodotti apparentemente interessanti diventavano poco competitivi una volta considerati spedizione, gestione e marginalità reale.

Il lavoro è consistito nel costruire criteri di selezione chiari, analizzare le referenze una per una e separare ciò che poteva funzionare realmente online da ciò che avrebbe generato vendite poco sostenibili o problemi operativi.

Sono stati incrociati prezzo, stock, costi di consegna, marginalità e caratteristiche del prodotto, creando un assortimento più ristretto ma più coerente con il canale.

Il risultato non è stato avere più prodotti online, ma avere quelli giusti: un assortimento più semplice da gestire, più competitivo e soprattutto sostenibile nel tempo.

Persone — aiutare qualcuno a ritrovare direzione

Quando una persona perde coinvolgimento, il problema non è sempre la motivazione.

In questo caso una risorsa che in precedenza aveva dimostrato capacità e affidabilità aveva progressivamente ridotto iniziativa, partecipazione e qualità del contributo. La reazione più semplice sarebbe stata aumentare il controllo o interpretare il comportamento come scarso interesse.

Il lavoro è partito invece dal confronto diretto e dall'ascolto, cercando di capire cosa fosse cambiato nel rapporto tra la persona, il ruolo e il contesto.

Sono emersi elementi che difficilmente sarebbero comparsi attraverso obiettivi, report o KPI: perdita di chiarezza, percezione di scarso impatto e distanza crescente dalle decisioni.

Il percorso è stato quindi costruito insieme, ridefinendo responsabilità, aspettative e spazio di autonomia.

Non si è trattato di “motivare” qualcuno, ma di rimuovere ciò che gli impediva di tornare a funzionare bene.

Il risultato più importante non è stato soltanto il recupero della performance, ma il ritorno di iniziativa e responsabilità personale.

Software / Beta testing — portare un prodotto nuovo davanti al mercato

Un prodotto può funzionare perfettamente dal punto di vista tecnico e avere comunque problemi quando incontra utenti reali.

In questo caso il lavoro ha riguardato una piattaforma ancora in fase di sviluppo, utilizzata in condizioni reali per individuare problemi che non emergevano nei test tradizionali.

Il testing non si è limitato a verificare se le funzioni previste fossero presenti, ma ha osservato il comportamento complessivo del prodotto: flussi poco intuitivi, incoerenze tra interfaccia e logica, aggiornamenti che modificavano comportamenti precedenti e situazioni in cui l'utente poteva trovarsi senza capire cosa stesse realmente accadendo.

Ogni problema è stato documentato partendo dall'esperienza d'uso: cosa stavo cercando di fare, cosa mi aspettavo succedesse, cosa è successo realmente e quale conseguenza avrebbe avuto per un utilizzatore normale.

Il valore del beta testing, in questo caso, non è stato semplicemente trovare bug.

È stato rappresentare il punto di vista del mercato prima che il prodotto arrivasse davvero sul mercato.

AI — Red Teaming narrativo su sistemi conversazionali

Testare un sistema di intelligenza artificiale non significa soltanto cercare di fargli dire qualcosa che non dovrebbe.

Nel Red Teaming conversazionale, il problema interessante arriva quando il sistema viene portato fuori dalla situazione ideale: conversazioni lunghe, richieste ambigue, cambi di ruolo, informazioni parziali, pressioni dell'interlocutore e tentativi di spostare progressivamente i confini delle regole iniziali.

Il lavoro è stato condotto su differenti modelli conversazionali, tra cui Gemini e Claude, costruendo scenari narrativi realistici invece di utilizzare semplici prompt isolati.

L'obiettivo era verificare come il sistema reagisse nel tempo: se mantenesse le proprie regole, se iniziasse a contraddirsi, se inventasse informazioni per mantenere coerente la conversazione o se fosse possibile portarlo gradualmente verso comportamenti che una richiesta diretta non avrebbe ottenuto.

Il metodo prevedeva la costruzione di un contesto credibile, l'evoluzione progressiva della conversazione e l'osservazione dei punti in cui il modello iniziava a cedere: non necessariamente con una violazione evidente, ma attraverso piccole concessioni, interpretazioni sempre più elastiche o perdita delle condizioni iniziali.

L'AI è stata utilizzata anche dall'altra parte del tavolo, come supporto nella costruzione degli scenari, nell'analisi delle risposte e nella ricerca delle contraddizioni.

Questo ha trasformato il test in un processo iterativo: attacco, risposta, analisi, modifica dello scenario e nuovo tentativo.

Il risultato non è stato semplicemente capire se un modello fosse vulnerabile a un determinato prompt, ma osservare come cambiasse il suo comportamento dentro una conversazione realistica e sufficientemente lunga.

Perché, spesso, un sistema non si rompe con una domanda sbagliata.
Si rompe dopo venti domande apparentemente innocue.