Un fornitore ti mostra una demo. Legge fatture, smista email o risponde ai clienti, a seconda di cosa ti serve. Sembra perfetta: veloce, pulita, nemmeno un errore. Firmi, la colleghi alla tua operatività reale e tre settimane dopo qualcuno del team ti dice che non ci si può fidare. Il fornitore giura che il prodotto è lo stesso. Ha ragione, ed è proprio questo il problema: tra la demo e la produzione non è cambiato il sistema, è cambiato il materiale su cui è stato provato.
La tesi in una riga: la demo non fallisce per malafede, fallisce per selezione del campione. I documenti che hai mandato erano quelli puliti, i ticket erano quelli scritti bene, e i casi che fanno saltare il business case non sono mai entrati. Quello che hai visto non era un test, era una prova generale.
Perché la demo di IA non assomiglia alla produzione
Perché qualcuno ha scelto i casi. Quasi sempre tu, con le migliori intenzioni. Ti chiedono esempi per la prova e mandi quelli che hai sottomano: i documenti ben scansionati, i ticket scritti con frasi complete, i clienti che seguono il processo esattamente come l’hai disegnato sulla carta. Con questi, qualunque sistema ragionevole fa bella figura. E il fornitore si prepara proprio su quelli: ritocca il prompt, affina le regole, risolve le stranezze che emergono. Quando arriva la demo, il sistema ha già visto l’esame.
La produzione non è quel campione. È l’intera distribuzione, con le sue code: la scansione storta, la mail di tre righe senza contesto, il cliente con due ragioni sociali, la fattura di rettifica che arriva un venerdì pomeriggio. Un sistema valutato solo sulla parte facile della distribuzione non è collaudato, è provato a memoria. È la stessa logica per cui una percentuale di accuratezza non basta in produzione: il numero dipende da quali casi entrano nel conto.
Cosa lascia fuori una demo, e perché è proprio ciò che costa denaro
- I documenti brutti. Foto fatte col telefono, PDF scansionati al contrario, tabelle spezzate su due pagine, formati di cinque anni fa che nessuno ha mai dismesso.
- I messaggi scritti male. Frasi a metà, due lingue nella stessa mail, riferimenti a una conversazione precedente che il sistema non ha.
- Le eccezioni del business. Il cliente con condizioni speciali, l’ordine che mescola due listini, il caso che conosce solo la persona che ricopre quel ruolo da dieci anni.
- Il raro e l’ostile. Input vuoti, duplicati, allegati che non sono ciò che dicono di essere, qualcuno che mette alla prova i limiti del sistema.
C’è qualcosa di peggio della frequenza: i casi rari non costano come quelli normali. Un errore su un ticket semplice si corregge in un minuto. Un errore nella fattura di un cliente importante, o nella risposta che arriva alla direzione, si paga in fiducia. Per questo una demo perfetta sui casi facili dice poco sul costo reale di mettere in moto il sistema.
Il numero che conta non è la media, è la coda cattiva
Se ti dicono che il sistema ci azzecca «quasi sempre», chiedi: su cosa? Una media alta può nascondere che i casi facili vanno quasi tutti bene e quelli difficili quasi tutti male, e che il tuo business case dipende dai difficili. Se il processo si giustifica perché oggi qualcuno perde ore con le eccezioni, un sistema che risolve ciò che era già facile non ti fa risparmiare nulla. Guarda il tratto peggiore: cosa succede con i casi più complicati, che errori commette e quanto spesso, quali intercetta da solo e quali arrivano fino al cliente. È ciò che misurare le prestazioni delle tue automazioni richiede fin dal primo giorno.
Cosa chiedere al posto di una demo: un metodo d’acquisto in cinque passi
- Un campione casuale, scelto da te. Prendi gli ultimi casi reali di un periodo, senza filtrare né ripulire, e non mostrarli al fornitore prima della prova. Se li sceglie lui, si torna al punto di partenza.
- Con i casi rari dentro. Aggiungi a mano quelli che fanno più male: quelli che sono andati in escalation, quelli finiti in reclamo, quelli che risolve solo una persona del team.
- Il criterio prima di vedere il risultato. Decidi per iscritto quale errore è accettabile per ogni tipo di caso e quale non lo è mai. Se fissi l’asticella dopo, finisci per difendere ciò che hai già visto.
- Leggi i fallimenti, non solo la percentuale. Rivedi a mano i casi che falliscono. Errori sparsi a caso ed errori sempre concentrati sullo stesso tipo di cliente sono problemi diversi, anche con la stessa percentuale.
- Provalo con i tuoi dati, nel tuo ambiente. Con i tuoi permessi, i tuoi formati e i tuoi sistemi collegati. Una valutazione della qualità degli agenti di IA esiste proprio per ripetere questa prova ogni volta che qualcosa cambia, non solo prima di comprare.
Quando la demo serve davvero
Non è tutta diffidenza. Una demo è utile per capire se l’interfaccia si adatta al modo di lavorare del tuo team, se le integrazioni esistono davvero e se il flusso ha senso. Basta anche quando il costo di un errore è piccolo e reversibile: una bozza che una persona rivede prima di inviarla non ha bisogno di un protocollo di valutazione. La demo risponde a «si può fare?». Non risponde a «regge nella mia operatività?», che è la domanda per cui si firma.
Cosa leggere nella reazione del fornitore
Quando proponi la prova con campione casuale e casi difficili, la reazione ti dice più della demo. Un fornitore serio accetta, ti aiuta a progettarla e ti mostra i fallimenti insieme ai successi. Uno che si mette a negoziare il campione, a chiedere «un caso rappresentativo» o a cambiare il criterio di successo ti ha appena mostrato com’è il rapporto quando in produzione qualcosa si rompe.
Se stai confrontando alternative, come scegliere uno strumento di automazione con IA ti dà gli altri criteri. E se hai già vissuto un pilota che ha brillato e non è mai arrivato in produzione, la demo non è il progetto racconta cosa viene dopo la firma.
La frase da portarsi via: una demo non prova che il sistema funziona, prova che esiste un insieme di casi per cui funziona. Il tuo lavoro, prima di firmare, è scoprire quali casi non sono in quell’insieme.