In una prima versione di questo pezzo avevo scritto che la qualità del modello è un non-problema e che, se l'agente fallisce, il difetto è sempre nel design. Era troppo. Passo le giornate a decidere quale modello fa cosa, quindi non posso sostenerlo. La versione che sostengo adesso è più stretta: accedere a un modello frontier è facile per chiunque, e la parte rara è sapere quale lavoro togliere a una persona, quale giudizio lasciarle e come provare che il risultato regge nel tempo.
L'ho imparato nelle discovery con gli amministratori di condominio per Lia, il prodotto di Yempik per gli studi di amministrazione, e costruendo l'agente WhatsApp di CVing.
Chi chiede completezza spesso vuole togliersi un altro lavoro
Lia è nata senza contabilità, per scelta. L'obiezione tornava spesso, e una volta l'abbiamo annotata parola per parola: «se io uso un gestionale senza la parte contabile, lo uso a metà». Letta così, sembrava un'istruzione chiara per la roadmap.
Allora abbiamo fatto la domanda in un altro modo a due amministratori che non si conoscono, in città diverse: cosa ti fa imprecare la mattina? Tutti e due hanno messo la contabilità in fondo, e tutti e due hanno spiegato il perché senza che glielo chiedessimo. Il primo: «Non è la parte contabile. Il problema è la parte pratica, quindi tutti gli interventi.» Il secondo: una volta registrate bene le fatture, la contabilità la fa qualsiasi software.
L'obiezione parlava di feature. Prevede bene cosa dice un cliente quando confronta due prodotti su carta, e male cosa pagherebbe per farsi risolvere. Abbiamo deciso operatività prima della contabilità: pratiche e fornitori, posta, WhatsApp, e il rilevamento dei condòmini morosi con solleciti approvati. Il valore più richiesto stava accanto a un sottosistema enorme, e per darlo non serviva ricostruirlo. Due conversazioni non fanno una legge di mercato. Bastano per non costruire per prima la parte sbagliata.
La domanda più utile è quella sull'impossibile
Gli esperti chiedono le feature che pensano di poter avere. Il valore grosso di solito sta in quello che non dicono, perché sono così abituati al sistema vecchio che certe cose non le mettono più in discussione. Per questo a ogni primo incontro faccio la stessa domanda, scritta così nei miei appunti:
what's the one thing that would be so cool to have/that would change your life but that we did not even mention because it is impossible?
La faccio prima di mostrare cosa sa fare il mio stack, perché dopo una demo le risposte si restringono a quello che hai appena mostrato. La risposta poi la investigo con calma, e al tavolo non prometto niente.
Prima di cercare un modello migliore, cerca un input che porti con sé il contesto
In una discovery su Lia si parlava dei fornitori che mandano le foto degli interventi su WhatsApp. L'idea sul tavolo era la più AI-native possibile: l'AI guarda la foto e capisce di che condominio e di che lavoro si tratta. Ho proposto la strada opposta, molto meno sexy: mandare al fornitore un link legato a quell'intervento, dove carica le foto, che finiscono direttamente nella pratica giusta. «Senza che il fornitore debba imparare a utilizzare il gestionale».
Il link elimina il problema invece di chiedere al modello di risolverlo. È ancora una proposta, con dettagli aperti su come scade e come si protegge. Vale ovunque: prima di migliorare estrazione o ragionamento, chiediti se la richiesta può nascere già legata al record giusto.
Alcuni gate umani restano anche quando il modello ha ragione
Quando abbiamo descritto i solleciti automatici, un amministratore ci ha fermati. Con alcuni condòmini ha accordi non scritti su tempi e modi di pagamento. Un sollecito automatico, corretto sui dati e puntuale, mandato a una di quelle persone può chiudere un rapporto che vale molto più del sollecito. Nei miei appunti di quella call ho scritto: «fare solleciti alla gente giusta, non sbagliata».
L'altro amministratore voleva la stessa schermata di conferma per il motivo opposto: il suo sistema di incasso a volte perde dei pagamenti, quindi il dato può essere sbagliato. Il suo gate dipende dalla qualità dei dati, e potrà allentarsi quando i dati migliorano. Il primo dipende da un rapporto, e resta, perché quell'accordo non starà mai in un campo del database. Quelli che proteggono un rapporto vanno resi veloci: una lista pronta e una conferma per riga.
Tieni lo standard dell'esperto e cambia i passaggi
Le pratiche consolidate di un esperto sono due cose insieme: abitudini, e il modo in cui oggi garantisce la qualità. Se le automatizzi così come sono, copi l'organigramma. Se le butti, perdi la qualità. Io riprogetto da zero in quello che chiamo «modo ignorante»: ignoro il processo esistente e parto da un vincolo, “this must be done by a single person with these AI tools”. Lo standard dell'esperto resta il criterio con cui accetto il risultato.
L'esperto così conta più di prima, con un ruolo diverso. Firma gli standard, porta esempi accettati e fallimenti inaccettabili, aggiorna tutto quando il dominio cambia. È questa firma che separa un deliverable riproducibile da una vincita alla lotteria dei token. Se il tuo human in the loop è una persona che corregge ogni output, hai una coda di review travestita da sistema. Raccogli esempi e criteri, costruisci eval, e misura quanto il risultato si ripete. Con il codice funziona allo stesso modo: una persona che legge ogni diff è anche lei una review queue (qui).
Il prodotto minimo è un ciclo chiuso, anche fuori dal tuo prodotto
Abbiamo definito la prima unità di valore di Lia passo per passo: importare un condominio reale, ricevere una email, capire chi scrive e per quale condominio, aprire o aggiornare la pratica, preparare la risposta, chiedere l'approvazione, annotare l'esito. Il test di adozione è uno solo: lo studio vuole spostare su Lia anche gli altri condomini che gestisce?
Uno studio che lavorava con Lia sui suoi dati veri ci ha fatto notare un problema che nessuna demo avrebbe mostrato. Una email gestita dentro Lia restava da leggere su Gmail. La sua frase: «o lavoriamo su CRM o lavoriamo su Gmail. Non puoi lavorare su entrambi». Le risposte andavano bene, ma il prodotto aveva creato una seconda casella da presidiare: più lavoro, l'opposto della promessa. Il «fatto» va definito nel sistema su cui l'operatore conta ancora, e testato lungo tutto il flusso.
Lo stesso ciclo deve reggere la migrazione. Chi cambia gestionale sposta i condomini uno alla volta, rimette in formazione i colleghi e lavora con export parziali. Mappa come si sposta un cliente prima di dare per scontato che cambi tutto in un giorno.
L'obiezione: allora il modello non conta
L'obiezione più forte va alla mia vecchia versione: se il modello è una commodity, prendi il più economico e chiudi la questione. La capacità del modello resta un vincolo da testare. L'agente WhatsApp di CVing è partito con un modello piccolo ed economico, e il mese dopo girava su uno più capace. Si cambia senza toccare il codice, e quel punto di sostituzione è la parte giusta del ragionamento sulla commodity.
Non ho misurato il prima e il dopo in modo isolato, quindi a quel cambio non attribuisco nessun miglioramento. Il mio ordine: prima controllo dati, strumenti, stato e istruzioni; poi verifico se il modello regge il task; tengo il fornitore sostituibile e chiedo prove prima di accettare una sostituzione.
Da lunedì
- Chiedi ai clienti di mettere in ordine le frustrazioni concrete, e separa «mi aspetto che ci sia» da «ho bisogno che sia risolto».
- Fai la domanda sull'impossibile prima della demo.
- Prima di migliorare l'estrazione, prova a legare l'input al record.
- Per ogni gate umano scrivi perché esiste: dati incerti o rapporto. Riduci i primi, rendi veloci i secondi.
- Definisci il «fatto» nel sistema che l'operatore usa ancora, e testalo lungo tutto il flusso.
- Tieni il modello sostituibile e testa ogni cambio sul task vero.