Come aggiungere funzioni di IA a un SaaS che ha già realizzato

C'è una pressione molto particolare che oggi colpisce ogni fondatore di un SaaS. Un membro del consiglio, un cliente, o semplicemente la voce nella sua testa ripete le stesse tre parole: «ci serve l'IA». Il prodotto già funziona. Le persone pagano per averlo. Eppure all'improvviso sembra mancargli qualcosa che tutti gli altri sembrano avere. Così apre uno sprint, collega un'API, rilascia un chatbot in un angolo, e un mese dopo non lo usa nessuno. Il problema non è mai stato il modello. È stato decidere su cosa puntarlo.

Aggiungere l'IA a un prodotto nuovissimo è, curiosamente, la versione facile. Non ha utenti da deludere, nessun modello di dati da rispettare, nessun team di assistenza da istruire. Aggiungere l'IA a un SaaS che esiste già — con clienti paganti, un flusso di lavoro consolidato e la reputazione di essere affidabile — è un altro sport. Ogni nuova funzione atterra dentro un sistema di cui le persone si fidano già, e la fiducia è proprio ciò che una funzione di IA troppo entusiasta brucia più in fretta.

Abbiamo aiutato parecchi team di sviluppo a farlo bene, e ne abbiamo visti alcuni farlo male. I team che riescono non partono quasi mai dalla tecnologia. Partono dall'unica domanda dolorosa che i loro utenti continuano a porre, e solo allora si chiedono se l'IA sia la risposta onesta più economica. Questa guida è proprio quell'approccio, messo nero su bianco: come scegliere la funzione, costruirla senza rompere ciò che funziona, e rilasciarla in modo che le persone la usino davvero.

Perché la maggior parte delle funzioni di IA innestate fallisce

Attraversi abbastanza cruscotti di gestionali e prima o poi riconoscerà il cimitero. Un pulsante «✨ Assistente IA» che nessuno clicca. Un pannello di riepilogo che produce tre frasi insipide che chiunque avrebbe potuto scrivere. Un chatbot che risponde a domande a cui il prodotto rispondeva già meglio con una normale casella di ricerca. Queste funzioni non sono fallite perché l'IA era debole. Sono fallite perché erano soluzioni in cerca di un problema.

Lo schema è quasi sempre lo stesso. Qualcuno ha sentito la pressione di rilasciare qualcosa dalla forma di IA, così ha afferrato l'opzione più generica e più visibile — una casella di chat — perché è ciò che più ovviamente si legge come «IA». Ma una casella di chat è una pagina bianca, e una pagina bianca è un'interfaccia pessima per chi è entrato nel suo prodotto per portare a termine un compito preciso. Non vogliono conversare. Vogliono il report finito, l'e-mail redatta, i dati ripuliti.

Il secondo modo di fallire è più sottile e più costoso: rilasciare una funzione che ha ragione quasi sempre dentro un flusso di lavoro in cui sbagliare è inaccettabile. Un suggerimento accurato al 90 % suona magnifico in una demo. In uno strumento con cui le persone inviano fatture o pianificano i turni del personale, un errore sicuro di sé una volta su dieci non si legge come «IA impressionante»: si legge come «di questo prodotto non ci si può fidare». L'asticella dentro un prodotto esistente è più alta che su una landing page, perché sta spendendo una fiducia che si è già guadagnato.

Parta dalla domanda, non dal modello

La buona notizia è che un SaaS esistente le consegna qualcosa che un prodotto nuovo non ha mai: prove. Sa già dove i suoi utenti faticano, perché glielo dicono ogni giorno. La materia prima della sua prima grande funzione di IA è nella sua casella dell'assistenza, nei suoi sondaggi sulle disdette e nelle parti del suo stesso prodotto che le persone evitano in silenzio.

Quindi, prima che qualcuno scriva un prompt, vada a raccogliere quelle prove. Legga gli ultimi duecento ticket di assistenza ed etichetti quelli ripetitivi. Chieda al suo team di assistenza a quale domanda è stanco di rispondere. Cerchi nelle sue analitiche la schermata dove le persone rallentano, abbandonano o cliccano con rabbia. Da qualche parte lì dentro c'è un compito noioso, dalla forma linguistica, svolto più e più volte, ed è esattamente la forma di un compito in cui l'IA è brava.

Noti cosa hanno in comune queste richieste: nessuna è «aggiungi un chatbot». Sono precise, integrate, e finiscono con un risultato concreto. È questa la differenza tra una funzione di IA e un giocattolo di IA. Una funzione scompare nel flusso di lavoro e risparmia un passaggio. Un giocattolo sta in disparte e chiede all'utente lavoro in più per ricavarne un qualche valore.

Un modo rapido per classificare le sue candidate di IA

Una volta che ha una rosa di tre o sei idee, le serve un modo di scegliere che non si riduca a chi discute più forte nella riunione di pianificazione. Valutiamo ogni candidata su tre assi schietti, da uno a cinque, e il totale più alto di solito vince, o quantomeno avvia la discussione giusta.

1. 1
   Valore: quanto la desiderano gli utenti?

   Assegni 5 se risponde a una richiesta che sente di continuo e farebbe risparmiare tempo in modo visibile. Assegni 1 se è un «sarebbe carino» che qualcuno nel team ha tirato fuori.
2. 2
   Tolleranza: cosa succede quando sbaglia?

   Assegni 5 se un errore è poco costoso e facile da cogliere — una bozza che l'utente rivede comunque. Assegni 1 se un errore corrompe in silenzio dati, denaro o un rapporto con un cliente.
3. 3
   Fattibilità: può davvero alimentarla?

   Assegni 5 se possiede già i dati di cui la funzione ha bisogno, in una forma utilizzabile. Assegni 1 se dipende da dati che non ha, a cui non può accedere o che sono un disastro.
4. 4
   Moltiplichi, poi verifichi il buon senso

   Moltiplichi i tre. Poi si ponga la domanda umana: possiamo rilasciare una prima versione della vincitrice in circa un mese? In caso contrario, ne riduca la portata finché non ci riesce.

Quell'asse centrale — la tolleranza all'errore — è quello che i team saltano, ed è quello che affonda i progetti. Una funzione può essere di alto valore e del tutto fattibile e restare una pessima prima scelta, semplicemente perché il costo di una risposta sbagliata ma sicura è troppo alto. La sua prima funzione di IA dovrebbe vivere in un posto indulgente, dove la persona resta nel ciclo e un errore costa qualche secondo, non un cliente.

La costruisca dentro al prodotto, non accanto

Ecco l'errore che separa una funzione di IA amata da una tollerata: dove la colloca. L'istinto è aggiungere una superficie di IA nuova e separata — un pannello, una pagina, un cassetto di chat — perché sembra un modo pulito di rilasciare. Ma una superficie separata chiede all'utente di lasciare ciò che stava facendo, andare altrove e tornare. Ognuno di quei passaggi perde persone.

Le funzioni che attecchiscono sono quelle che compaiono esattamente dove il lavoro avviene già. Il pulsante della bozza sta dentro la casella di risposta, non in una barra laterale. I dati estratti confluiscono dritti nei campi del modulo, precompilati e modificabili. La priorità suggerita appare come un'etichetta discreta nell'elenco che l'utente già scorre con lo sguardo. L'IA non si annuncia; rende semplicemente il clic successivo palesemente più facile. È tutto qui il mestiere.

È anche qui che avere un prodotto esistente è un dono e non un vincolo. Conosce già il momento esatto in cui il suo utente si blocca, il campo esatto che sta per compilare, l'e-mail esatta che sta per scrivere. Usi quel contesto. Lo stesso modello, alimentato con i dati circostanti che il suo prodotto già custodisce, produce qualcosa dieci volte più utile di quanto potrebbe mai una casella di chat vuota, perché non sta indovinando ciò che l'utente vuole. Lo sa già.

Tenga una persona nel ciclo, e che si veda

Per le sue prime funzioni di IA, lo schema più sicuro e affidabile è quasi sempre suggerire, non agire. L'IA propone; la persona approva. Redige l'e-mail e la persona la invia. Compila i campi e la persona li controlla. Segnala la priorità e la persona decide. Non è mancanza di ambizione: è così che costruisce lo storico che poi le permetterà di automatizzare di più.

C'è una dimensione di design in questo, non solo tecnica. Renda visivamente chiaro quando qualcosa è venuto dall'IA ed è in attesa della benedizione di una persona. Un'etichetta discreta, uno sfondo diverso, un esplicito «rivedi e invia» invece di un'azione automatica silenziosa. Gli utenti perdonano un suggerimento dell'IA leggermente fuori bersaglio molto più volentieri di un'azione dell'IA avvenuta senza chiedere. Il primo sembra una collega utile; la seconda dà l'impressione che il software sia impazzito.

• Mostri l'output dell'IA come una bozza o un suggerimento che l'utente può modificare prima che faccia testo.
• Lo renda visivamente distinto, così nessuno scambia una congettura della macchina per un fatto confermato.
• Offra sempre un «no, grazie» pulito: lasci che le persone scartino il suggerimento e proseguano alla vecchia maniera.
• Quando l'IA non è sicura, lo dica, e degradi con eleganza invece di inventare una risposta sicura di sé.
• Registri cosa è stato suggerito e cosa ne ha fatto la persona: sono i suoi dati di accuratezza per il futuro.

Quest'ultimo punto è, in sordina, il più prezioso. Ogni volta che un utente accetta, modifica o rifiuta un suggerimento, le sta dicendo quanto la sua funzione sia davvero buona, nel mondo reale, su dati reali, non in una demo. Quel ciclo di feedback è il modo in cui decide se una funzione è pronta a diventare più autonoma, e dove ha ancora bisogno di una mano umana al volante.

La realtà ingegneristica di cui nessuno la avverte

La demo è il 20 % facile. Portare una funzione di IA pronta per la produzione dentro un SaaS reale è l'altro 80 %, ed è per lo più lavoro poco appariscente che ha poco a che fare con il modello in sé. Vale la pena saperlo fin dall'inizio, così un prototipo funzionante non la inganna spingendola a promettere una data di rilascio che mancherà.

Idraulica dei dati e contesto

Un modello vale solo quanto ciò di cui lo alimenta. La parte difficile è raccogliere in modo affidabile il contesto giusto dal suo database esistente, formattarlo, tenerlo aggiornato e rispettare quale utente è autorizzato a vedere cosa. In un SaaS multi-tenant questo conta enormemente: una funzione di IA che mescola per sbaglio i dati di un cliente nella risposta di un altro non è un bug, è un incidente. L'isolamento tra tenant deve arrivare fino in fondo al suo livello di IA.

Costo e latenza

Ogni chiamata all'IA costa denaro e tempo, ed entrambi crescono con l'uso in modi che un abbonamento SaaS a tariffa fissa non ha. Una funzione deliziosa per dieci utenti in beta può diventare in sordina un problema di margine a diecimila. Deve pensare per tempo a quale modello si adatta a quale compito — non le serve il modello più potente e costoso per categorizzare un ticket di assistenza —, alla messa in cache del lavoro ripetuto, e a cosa fa la funzione quando una risposta impiega quattro secondi invece di uno.

Il guasto e il percorso infelice

Gli utenti reali incollano spazzatura, caricano il file sbagliato, scrivono in tre lingue e sollecitano la sua funzione nel momento peggiore possibile. Il fornitore di IA ha un disservizio. Una risposta torna malformata. La sua funzione deve gestire tutto questo senza rompere il resto del prodotto. La regola è semplice e rigida: il guasto di una funzione di IA non deve mai trascinare con sé un flusso di lavoro essenziale. Deve fallire in silenzio, ripiegare sul percorso manuale e lasciare che l'utente continui a lavorare.

Darle un prezzo: una funzione, un componente aggiuntivo o tutta la storia?

Una volta che la funzione opera, affronta una domanda commerciale su cui inciampano molti team: come la fattura? Non c'è un'unica risposta giusta, ma qualche schema onesto sì. Può inglobarla nei suoi piani esistenti come un valore aggiunto che migliora la fidelizzazione e giustifica il suo prezzo. Può renderla un componente aggiuntivo a pagamento o un livello superiore, il che funziona quando la funzione offre un valore evidente e misurabile. Oppure può misurarla a consumo quando il costo sottostante cresce davvero con l'utilizzo.

La trappola da evitare è dare un prezzo alla funzione come se l'IA fosse il prodotto. Per la maggior parte delle aziende SaaS, l'IA non è una nuova linea di prodotto: è una nuova capacità che rende il suo prodotto esistente più prezioso. I clienti non si svegliano con la voglia di comprare «l'IA». Vogliono che il loro problema reale sia risolto un po' più facilmente, e pagheranno per quel risultato, che ci sia o no una macchina dietro. Dia un prezzo al risultato, non alla tecnologia.

Rilasci una cosa piccola, poi salga

Tutta la strategia si riduce a una sequenza, non a un singolo lancio. Scelga l'unica funzione di alto valore e tollerante all'errore che i suoi utenti già chiedono. La incorpori dove il lavoro avviene. Tenga una persona nel ciclo. La rilasci a una fetta di clienti dietro un flag. Osservi come la usano davvero, sistemi ciò che è grezzo, poi la allarghi. Solo quando quella funzione si è guadagnata il posto passa alla successiva, un po' più ambiziosa.

Faccia questo qualche volta e accade qualcosa di silenziosamente potente. Il suo prodotto smette di essere «software con un pulsante di IA innestato» e diventa uno strumento davvero più intelligente nei compiti precisi a cui i suoi clienti tengono. È una posizione molto più forte di quella del team che ha rilasciato un'impressionante demo di chatbot nella prima settimana e ha passato i sei mesi successivi a spiegare perché non la usa nessuno.

Domande frequenti