Aziende di distribuzione/e-commerce con customer service su Zendesk
Succede spesso: un'azienda con un volume alto di richieste clienti — resi, tracking, domande sui prodotti — guarda il proprio Zendesk e vede un numero che cresce ogni trimestre. La reazione istintiva è "ci serve un chatbot AI che risponda ai ticket". È la richiesta più comune che ricevo, ed è quasi sempre la domanda sbagliata.
Il primo passo dell'AI Grounding Assessment, in questi casi, non è tecnico. È capire perché il volume cresce. In diversi casi che ho osservato, la causa non era il numero di clienti — era che il 40-50% dei ticket riguardava le stesse tre o quattro domande, sintomo di un problema a monte: pagina prodotto poco chiara, policy di reso non comunicata, tracking non aggiornato in tempo reale. Un chatbot AI su quei ticket avrebbe automatizzato la sintomatologia, non risolto la causa.
Il Business Understanding chiede sempre: stiamo cercando di ridurre il volume di richieste, o di rispondere più velocemente a quelle che restano? Sono due problemi diversi, con soluzioni diverse. Il People Understanding aggiunge un secondo livello: spesso il team customer service ha già escogitato risposte standard non ufficiali — una forma di shadow process — che raccontano meglio di qualsiasi ticket dove sta il vero attrito.
Solo dopo questa mappatura ha senso parlare di automazione: a volte il caso d'uso giusto è un assistente che aiuta l'operatore umano a rispondere più velocemente (non a sostituirlo), altre volte è correggere tre pagine del sito e il problema si dimezza prima ancora di toccare l'AI.
Aziende B2B con CRM strutturato (HubSpot o Salesforce) e rete commerciale
Un pattern che vedo spesso in aziende B2B con una rete vendita strutturata: il CRM è pieno — contatti, interazioni, note, stadi di trattativa — ma le decisioni commerciali continuano a essere prese sull'intuito del venditore più esperto, non sui dati che l'azienda già possiede. La richiesta iniziale è tipicamente "vogliamo l'AI per fare lead scoring".
Il problema, quasi sempre, non è la mancanza di un modello predittivo. È che i dati nel CRM sono incompleti o incoerenti — campi lasciati vuoti, stadi di trattativa aggiornati in ritardo, criteri di qualificazione che cambiano da venditore a venditore. Il Data Understanding, nel mio metodo, è dedicato proprio a questo: non un audit tecnico, ma una verifica onesta se il dato esistente è abbastanza affidabile da alimentare qualcosa che poi guiderà decisioni commerciali reali.
Quando la risposta è "non ancora", il progetto AI più corretto — controintuitivamente — non è costruire un modello, ma disegnare un processo minimo di raccolta dati più coerente per 60-90 giorni, e poi tornare a parlare di scoring predittivo. Investire prima in un modello su dati deboli produce una black box che il team commerciale non si fiderà mai di usare — e il progetto muore silenziosamente dopo il lancio, con l'AI "colpevole" di un problema che esisteva già prima di lei.
PMI manifatturiera con ERP legacy (SAP o simili)
Nelle aziende manifatturiere con un ERP consolidato da anni, l'AI viene spesso vista come l'occasione per "finalmente rifare tutto" — un'ambizione capibile ma pericolosa. L'ERP è quasi sempre il sistema più critico e più fragile dell'azienda: cambiarlo o affiancargli un livello AI ambizioso senza una validazione preventiva è uno dei modi più rapidi per bruciare budget e fiducia interna.
Il Business Understanding, in questi contesti, deve fare una domanda scomoda alla Leadership: stiamo cercando di migliorare un processo specifico, o stiamo proiettando sull'AI la frustrazione accumulata per un sistema che tutti odiano da anni? Sono due mandati completamente diversi, e confonderli è la causa più comune di progetti che si arenano.
Il caso d'uso più difendibile che emerge, quasi sempre, non è "sostituire l'ERP con l'AI" ma isolare un singolo processo ad alto attrito — tipicamente la reportistica per la direzione, che nei sistemi legacy richiede ore di estrazione ed elaborazione manuale — e costruire lì un intervento mirato: uno strumento che legge i dati esistenti (senza toccare l'ERP) e produce sintesi comprensibili in linguaggio naturale per chi deve decidere. Piccolo, verificabile, e soprattutto: non richiede di convincere nessuno a "cambiare il gestionale", la resistenza più difficile da vincere in una PMI manifatturiera.
Retail o E-commerce con catalogo ampio (Shopify o piattaforme simili)
Le aziende con cataloghi prodotto ampi — centinaia o migliaia di SKU — arrivano spesso con una richiesta molto concreta: "vogliamo generare le descrizioni prodotto con l'AI, ci fa risparmiare tempo". È vero, e in questi casi è uno degli use case più rapidi da validare. Ma il People Understanding rivela quasi sempre un problema più interessante di quello dichiarato.
Chi scrive oggi le descrizioni prodotto — spesso una persona sola, o un piccolo team — porta con sé una conoscenza tacita del catalogo che non è mai stata scritta da nessuna parte: quali prodotti si somigliano, quali si vendono insieme, quali argomentazioni funzionano per quale tipo di cliente. Automatizzare la scrittura senza prima raccogliere quella conoscenza produce testi tecnicamente corretti ma piatti — l'AI scrive bene la sintassi, ma non sa cosa quella persona sa.
L'intervento più efficace, in questi casi, comincia con poche ore di intervista strutturata con chi gestisce il catalogo oggi, per trasformare quella conoscenza tacita in indicazioni esplicite dentro il prompt. Il risultato non è "l'AI ha sostituito la persona che scriveva le schede" — è che quella persona ora supervisiona e corregge un output che parte già dal suo modo di ragionare sul catalogo, con un risparmio di tempo reale invece che una standardizzazione impoverita.
