Perché le startup AI devono presidiare i workflow e non i mercati

“Stiamo nel mercato della compliance”. È la frase di apertura più frequente che ho sentito negli ultimi 18 mesi nei pitch di startup AI in fase early. La variante cambia di volta in volta (legal tech, sales enablement, customer service automation, procurement intelligence) ma la struttura resta quella: un mercato indicato come territorio di operazione.

Confrontatela con un’apertura diversa, sentita in un pitch di un founder italiano qualche settimana fa: “Riduciamo del 50% il tempo di verifica delle clausole non standard nei contratti di fornitura per aziende manifatturiere con più di 200 fornitori”.

Le due frasi sembrano vicine, parlano grosso modo dello stesso ambito. Solo che la prima descrive un territorio e la seconda descrive un punto di lavoro. E nell’AI applicata questa differenza decide chi costruisce posizione e chi resta una funzionalità sostituibile.

Per anni la strategia digitale si è insegnata in termini di mercato. Si sceglieva una categoria, si presidiava un segmento, si difendeva una fetta. Era un linguaggio abbastanza utile finché il software era stabile, le funzionalità si accumulavano nel tempo, le integrazioni erano costose, i contratti enterprise duravano anni. Quel linguaggio funziona ancora in molti ambiti, ma quando si parla di AI applicata sta diventando insufficiente, perché descrive bene cosa una startup vende e male cosa una startup occupa.

Una startup AI che si presenta dicendo “stiamo nel mercato X” si espone a una comparazione orizzontale con tutti gli altri concorrenti dello stesso mercato. Una startup AI che si presenta dicendo “occupiamo questo punto preciso del workflow Y e lo occupiamo meglio di chiunque altro” si sottrae alla comparazione, perché parla una lingua che il mercato astratto non sa usare per misurarla. È un piccolo spostamento di vocabolario che cambia la struttura del problema strategico.

Startup AI, il presidio di un workflow

Un workflow è una sequenza di attività, decisioni, controlli, documenti e passaggi di mano che trasformano una richiesta in un risultato. Quando un’azienda lavora una pratica di credito, un sinistro, una proposta commerciale, un onboarding cliente, un ordine di acquisto, sta eseguendo un workflow.

Quel workflow ha tappe precise, attori definiti, eccezioni note, soglie di approvazione, documenti che si producono e si scambiano, momenti in cui qualcuno decide e momenti in cui qualcuno controlla. Presidiare un workflow non vuol dire fornire un tool che lo accompagna, vuol dire occupare uno o più tratti di quella sequenza in modo che, senza il sistema, il workflow rallenti o si fermi.

C’è una differenza concreta tra essere accanto al lavoro ed essere dentro il lavoro. Un assistente che genera testi su richiesta, e che l’utente apre quando gli serve, sta accanto al lavoro: è un tool, lo si chiama, lo si usa, lo si chiude. Un sistema che riceve automaticamente un certo tipo di documento in ingresso, lo classifica, lo arricchisce con informazioni dal CRM, segnala eventuali incompletezze, instrada il caso al ruolo competente, e poi assiste la preparazione della risposta, sta dentro il lavoro: il workflow non funziona senza di lui, o funziona molto peggio.

Le due posizioni hanno destini diversi. Lo strumento che sta accanto al lavoro è facilmente sostituibile, perché il lavoro continua a girare anche con un altro strumento equivalente. Il sistema che sta dentro il lavoro è molto più difficile da rimuovere, perché rimuoverlo significa riscrivere il workflow, ridistribuire responsabilità, ricostruire il contesto che il sistema aveva accumulato. È un costo che le aziende, una volta superata una certa soglia di integrazione, non sono disposte a pagare per cambiare fornitore.

Dal suggerimento all’esecuzione

Una distinzione che mi è utile per valutare un prodotto AI è quella tra punto di consultazione e punto di azione. Un sistema che suggerisce e informa, riassume contenuti o classifica in apparenza, sta in un punto di consultazione: produce conoscenza che l’umano poi userà per agire. Un sistema che prepara un documento, instrada una richiesta, compila un campo critico, attiva un controllo automatico, apre un’escalation quando una soglia viene superata, sta in un punto di azione: incide direttamente sul passo successivo del workflow.

I prodotti AI più deboli che vedo restano bloccati nel punto di consultazione. Sono intelligenti, talvolta sorprendenti, ma non spostano il lavoro. Le persone li usano per informarsi e poi tornano agli strumenti di sempre per fare le cose. I prodotti più forti riescono ad avanzare verso il punto di azione, sempre rispettando le soglie di rischio che l’organizzazione tollera, e in quel modo entrano nel flusso e cominciano a costruire dipendenza positiva.

Provo a renderlo concreto. Un sistema che dice “questo ticket di assistenza potrebbe essere una richiesta di rimborso, suggeriamo di gestirlo come tale” è nel punto di consultazione. Un sistema che classifica automaticamente il ticket come richiesta di rimborso, lo instrada al team competente, precompila la bozza di risposta usando i dati del cliente dal CRM, segnala se la pratica richiede un’approvazione di secondo livello sopra una certa soglia, e tutto questo in coerenza con le procedure interne dell’azienda, è nel punto di azione.

Entrambi usano le stesse capability tecniche di base, gli stessi modelli linguistici, le stesse API. La differenza tra i due, in termini di posizione di mercato, è enorme: il primo è un assistente che il cliente può sostituire in trenta giorni, il secondo è un nodo del processo che il cliente può sostituire solo riprogettando il processo stesso.

Una conferma dalla survey McKinsey

Spostare il fuoco dal mercato al workflow non è un’osservazione personale isolata. La survey McKinsey State of AI di novembre 2025, condotta su quasi duemila partecipanti in centocinque paesi, identifica come fattore critico di successo proprio il ridisegno del workflow attorno all’AI.

Secondo i dati, gli high performer (definiti come le aziende che attribuiscono almeno il cinque per cento del loro EBIT all’AI) hanno una probabilità quasi tre volte maggiore di aver ridisegnato fondamentalmente i propri workflow rispetto al resto del campione. La maggior parte delle aziende, invece, mette l’AI sopra processi esistenti senza ripensarli, e ottiene benefici a livello di singolo caso d’uso che non si traducono in impatto di bilancio.

Il punto, qui, vale tanto per chi costruisce quanto per chi compra. Chi costruisce un prodotto AI ha più probabilità di sopravvivere se sceglie un workflow specifico e lo presidia in profondità, invece di proporsi come tool generico applicabile a un mercato vasto. Chi compra ha più probabilità di vedere ritorni concreti se compra prodotti che ridisegnano un workflow, invece di prodotti che si limitano ad accelerare un workflow rotto. La stessa tecnologia, applicata nelle due modalità, produce risultati diversi di un fattore tre.

Questo dato dovrebbe avere conseguenze pratiche su come le aziende valutano gli investimenti in AI. Quando il management di una corporate chiede “quanto stiamo spendendo in AI quest’anno”, la domanda è già sbagliata. La domanda giusta è “quali workflow stiamo ridisegnando con l’AI quest’anno, e cosa dovrebbe cambiare nel modo in cui quelle persone lavorano?”. Se il management non sa rispondere, probabilmente l’investimento è frammentato in dieci pilot che non si parlano tra loro, e che difficilmente porteranno a un impatto enterprise-level.

I workflow su cui possono lavorare le startup AI

Identificato il workflow giusto, resta da capire quale workflow vale davvero la fatica di presidiare. Non hanno tutti lo stesso valore strategico, e su questo le startup sbagliano spesso la prima scelta. I workflow su cui costruire bene hanno cinque caratteristiche che ricorrono.

Sono frequenti, perché senza ripetizione il sistema non accumula apprendimento. Hanno un costo riconoscibile, che si misura in tempo, denaro o rischio, perché senza un beneficio chiaro nessuno riprogetterà mai il workflow attorno al sistema. Coinvolgono più informazioni o più ruoli, perché se il workflow è già semplice e gestibile da una persona sola, l’AI difficilmente trova spazio per generare valore concreto. Contengono una quota di giudizio o ripetizione tale da meritare attenzione, perché i workflow puramente meccanici sono già automatizzabili senza AI, e quelli puramente di giudizio non si lasciano automatizzare. E sono abbastanza confinati da poter essere ridisegnati in tempi ragionevoli, perché un workflow troppo ampio diventa un progetto enterprise multi-anno che pochi clienti hanno la capacità di portare a termine.

Quando questi cinque criteri convergono, il workflow è un buon candidato per l’AI applicata. Quando uno o più di questi criteri manca, è probabile che il pilot funzioni in dimostrazione e si fermi nel deployment, perché la struttura economica dell’investimento non regge.

Un caso concreto chiarisce il punto. Una società finanziaria gestiva la lavorazione di pratiche di credito con un workflow che prevedeva raccolta documentale, verifica di completezza, confronto con policy interne, poi scoring e infine preparazione del dossier per il deliberante. Quando un sistema AI è entrato in quel workflow partendo dal controllo di completezza documentale, in pochi mesi ha cominciato a sedimentare conoscenza sulle eccezioni più frequenti, sui motivi di rimbalzo delle pratiche, sulle differenze di trattamento tra filiali. Il tempo medio di lavorazione per pratica si è ridotto del quaranta per cento circa, e i rimbalzi per incompletezza sono scesi dal venticinque all’otto per cento.

A quel punto, quando un competitor ha proposto una soluzione alternativa con un’interfaccia migliore e un prezzo più basso, la risposta del direttore operativo è stata semplice: non possiamo migrare senza perdere mesi di apprendimento sulle eccezioni delle nostre filiali. Il vantaggio era nel contesto che il sistema aveva costruito stando dentro il processo, non nell’algoritmo in sé.

Il rischio di un perimetro troppo largo

Quando una startup mi dice che gestisce “tutto il customer service” o che “automatizza la compliance”, la mia attenzione cala. Non perché le ambizioni siano sbagliate, ma perché la formulazione tradisce una scelta strategica troppo larga. Customer service è una funzione organizzativa, non un workflow. Compliance è un’area, non un punto operativo. Un workflow utile è un passaggio abbastanza definito da poter essere osservato e misurato con precisione. Triage dei ticket in ingresso, analisi preliminare di clausole fuori standard nei contratti di fornitura, classificazione documentale all’arrivo della pratica, generazione assistita di ordini standard sopra una certa soglia, verifica della completezza della documentazione di onboarding di un nuovo fornitore.

Partire stretti non vuol dire pensare in piccolo. Vuol dire scegliere un punto d’attacco abbastanza preciso da diventare bravi rapidamente, e abbastanza connesso ad altri punti del workflow da consentire un’espansione naturale per adiacenze. Una startup che si specializza nel triage dei ticket può, una volta consolidata quella posizione, espandersi alla preparazione delle risposte di secondo livello, alla gestione delle escalation, all’analisi delle cause ricorrenti, all’identificazione di pattern che generano insoddisfazione cliente. Ognuno di questi passi è un’estensione coerente del primo, e raccoglie segnali che il primo punto da solo non avrebbe raccolto.

La trappola opposta esiste, e la vedo anche, è quella della nicchia troppo stretta. Un workflow così specifico da avere un mercato indirizzabile di duecento aziende in tutto il mondo, di cui solo trenta sufficientemente grandi da pagare un prezzo che sostiene l’azienda, è un workflow che permette di costruire un business solido ma piccolo, non una startup ad alta crescita. La scelta del workflow giusto richiede di stimare in anticipo la dimensione del mercato indirizzabile e la traiettoria di espansione, e queste due cose vanno ragionate insieme, non separatamente.

Le metriche del presidio

Quando un workflow è davvero presidiato, le metriche che contano sono diverse da quelle che si usano per misurare un prodotto SaaS tradizionale. Numero di utenti attivi mensili, ARR, churn, retention generica: tutti utili, ma insufficienti per capire se il sistema sta diventando parte del processo o se viene usato solo episodicamente. Le metriche più informative, in questa fase, sono quattro o cinque, e sono molto più aderenti al lavoro reale.

La percentuale di casi del workflow coperta dal sistema, perché un sistema che gestisce il dieci per cento dei casi è ben diverso da uno che ne gestisce il settanta. La riduzione del tempo medio di lavorazione, perché senza compressione misurabile il sistema non sta producendo valore strutturale. Il tasso di output accettati al primo passaggio senza modifiche, perché è la migliore proxy della qualità reale del sistema in produzione. La frequenza d’uso nei momenti critici, perché un sistema che le persone usano nei momenti facili e abbandonano nei momenti difficili non sta presidiando il workflow, sta solo galleggiando. La velocità di onboarding di nuovi operatori che usano il sistema, perché un sistema che riduce il tempo di formazione dei nuovi assunti sta accumulando conoscenza operativa che prima viveva solo nelle persone esperte.

Quando queste metriche migliorano nel tempo, e migliorano insieme, il sistema sta diventando parte del lavoro. Quando migliora solo l’adozione, ma non la profondità, il sistema è ancora un tool, e la posizione che sembra solida è in realtà fragile davanti al primo competitor che proponga qualcosa di equivalente con un prezzo più basso.

Cambiare un workflow ha un costo politico

Ogni workflow esistente incorpora abitudini consolidate, gerarchie operative ed eccezioni che rappresentano piccole razionalità sedimentate da anni di pratica. Cambiarlo ha un costo che è insieme tecnico, organizzativo e politico. Un buon prodotto AI non finge che questo costo non esista, lo riduce. Trova punti in cui il beneficio è abbastanza alto da giustificare il cambiamento, e rende quel cambiamento il più naturale possibile, evitando rotture brusche di responsabilità o di flusso.

Le startup che funzionano meglio in questa fase, e questo è un pattern che ho visto ripetersi anche tra startup italiane di buon livello, sono quelle che dedicano tempo a capire come il workflow viene eseguito oggi nei dettagli. Con tutte le sue imperfezioni, le scorciatoie, le piccole deviazioni dalla procedura ufficiale, le abitudini sedimentate. Questo lavoro di osservazione antropologica del processo precede la scrittura del codice, e separa una soluzione che entra dentro il workflow senza creare attrito da una che richiede al cliente di adattarsi al prodotto invece del contrario.

Le startup che falliscono nel deployment, anche quando hanno una tecnologia eccellente, sono quasi sempre quelle che arrivano con una soluzione perfetta sulla carta e indifferente alla realtà del flusso. Si presentano dicendo “il nostro prodotto funziona così, voi dovete riorganizzarvi attorno”, e si scontrano con una resistenza che nessuna demo può superare. Il workflow, nelle aziende mature, ha una sua intelligenza distribuita, e quell’intelligenza va rispettata anche quando dall’esterno sembra inefficiente.

Un test rapido di posizionamento per una startup AI

Un test pratico per capire se la propria startup sta ragionando in termini di mercato o di workflow è semplice. Provate a riformulare la frase di apertura del pitch eliminando la parola “mercato” e sostituendola con “workflow”. Se la frase non regge senza il mercato, probabilmente la posizione è più astratta di quanto sembri.

Se la frase regge e diventa più precisa, c’è una struttura sotto, e quella struttura è ciò che gli investitori cercano davvero quando ascoltano un pitch AI nel 2025-2026. Lo stesso test, applicato dal lato del cliente che valuta un fornitore, prende la forma di una domanda diretta da fare durante la prima conversazione: quale tratto preciso del nostro processo il vostro sistema occupa, e dove si ferma l’automazione lasciando spazio all’umano?

Se il fornitore non sa rispondere a quel livello di dettaglio, probabilmente sta ancora ragionando in termini di prodotto, non di sistema. E un prodotto, da solo, raramente sopravvive al primo riallineamento di budget.

La prossima puntata entra dentro un altro pilastro dell’accumulazione, ed è il contesto. Workflow e contesto sono i due lati dello stesso meccanismo: il workflow è dove il sistema lavora, il contesto è quello che il sistema sa per lavorarci bene. Senza contesto il workflow resta una sequenza di automazioni superficiali, senza workflow il contesto resta un archivio inerte. La trattazione completa del framework, con i sette loop e gli strumenti operativi associati, è nel libro Da Zero a Loop.