Una richiesta arriva per email. Una persona la legge, cerca i dati del cliente, li ricopia nel gestionale e avvisa un collega. Il problema non è necessariamente la singola operazione. È il passaggio fra strumenti e persone, ripetuto ogni giorno.
Per scegliere da dove partire, serve descrivere bene una di queste sequenze. Un progetto circoscritto permette di vedere cosa funziona, quanto lavoro di verifica resta e quali informazioni mancano.
Descrivi un’attività, dall’inizio alla fine
Scegli un esempio recente e ricostruiscilo con chi lo ha svolto. Cosa ha fatto partire il lavoro? Da dove sono arrivati i dati? Quali passaggi hanno richiesto una decisione? Dove è finito il risultato?
Scrivi la sequenza in una frase: «Quando arriva una richiesta, recuperiamo i dati necessari, prepariamo una proposta e la facciamo verificare al referente». È un punto di partenza più utile di «vogliamo automatizzare il commerciale».
Confronta le attività su tre criteri
- Frequenza. Il passaggio si ripete abbastanza da giustificare il lavoro di integrazione? Conta le occorrenze, senza affidarti solo alla sensazione di chi è più impegnato.
- Disponibilità dei dati. Gli input sono accessibili, aggiornati e utilizzabili dalle persone autorizzate? Se mancano queste condizioni, il primo intervento riguarda le informazioni.
- Verificabilità. Una persona può riconoscere facilmente un risultato corretto? Il controllo deve essere parte del processo, soprattutto quando un errore avrebbe conseguenze rilevanti.
Un’attività frequente ma piena di eccezioni può richiedere più preparazione di una meno frequente e ben definita. La scelta dipende anche dal valore del risultato e dal tempo necessario a controllarlo.
Separa le regole dall’interpretazione
Copiare un campo fra due sistemi può richiedere una semplice integrazione. Interpretare una richiesta scritta in modi diversi può beneficiare dell’AI. Le due cose possono convivere nello stesso percorso.
Definisci dove il sistema esegue una regola, dove propone un’interpretazione e dove si ferma per chiedere una verifica. Anche «mancano informazioni» deve essere un esito gestibile.
Fai una prova che possa anche andare male
Prepara esempi ordinari, richieste incomplete e casi ambigui. Usa dati consentiti per la prova e annota il risultato atteso. Prima di avviare il test, concorda chi controlla, cosa si misura e quando si sospende l’esecuzione.
Per l’esempio dell’email, il sistema potrebbe preparare una bozza e recuperare i riferimenti. La persona verifica destinatario, informazioni e allegati prima dell’invio. È una configurazione illustrativa, da adattare agli strumenti e alle responsabilità reali.
Misura anche il lavoro che rimane
Confronta il tempo dell’intero percorso: preparazione, esecuzione, controllo e correzioni. Annota quante richieste richiedono un intervento e perché. Un risultato veloce da generare può essere lento da verificare.
La prova è utile quando permette di decidere il passo successivo: estendere, correggere o fermarsi. Conserva gli esempi usati nel test: serviranno per verificare che un aggiornamento non peggiori il comportamento.
Il primo processo giusto ha un inizio riconoscibile, un risultato controllabile e qualcuno che ne risponde.
Un esempio: dalle email a una richiesta pronta da valutare
Immagina un’impresa che riceve richieste di assistenza via email. Ogni messaggio va letto, associato a un cliente e assegnato alla persona giusta. Alcuni contengono un allegato, altri soltanto una frase. L’obiettivo della prova può essere preparare una scheda ordinata da far verificare al referente. L’esempio è illustrativo, non un risultato di un cliente FODI.
Il primo confine è chiaro: il sistema prepara la scheda; una persona decide se assegnarla. Il cliente non riceve ancora risposte automatiche. Puoi così osservare la qualità della preparazione prima di aggiungere conseguenze esterne.
| Passaggio | Cosa provare | Cosa controllare |
|---|---|---|
| Riconoscere il cliente | Cercare una corrispondenza nell’anagrafica | Non confondere nomi simili |
| Estrarre la richiesta | Riportare problema e riferimenti presenti | Lasciare esplicito ciò che manca |
| Proporre un referente | Applicare le regole di assegnazione | Segnalare le richieste fuori perimetro |
| Preparare la scheda | Collegare il messaggio originale | Consentire la verifica prima del salvataggio |
Come confrontare due possibili automazioni
Supponi che l’alternativa sia preparare il riepilogo di una riunione mensile. L’email è più frequente, ma questo non basta per sceglierla: se il referente non può verificare l’associazione al cliente, quel rischio deve entrare nella decisione. Il riepilogo potrebbe invece avere fonti più chiare e un controllo più semplice.
Scrivi per entrambi i casi la frequenza osservata, i dati accessibili, l’esito atteso e il lavoro di controllo. Segna anche chi userà il risultato. Una proposta che termina in un documento che nessuno apre non ha ancora un percorso completo.
Una scheda da compilare prima di partire
- Quando comincia: l’evento che avvia l’attività.
- Cosa entra: dati e documenti necessari, con la loro fonte.
- Cosa deve uscire: il risultato che una persona può accettare.
- Chi controlla: referente e criteri di approvazione.
- Quando si ferma: dati mancanti, ambiguità o eccezioni da affidare a una persona.
La prima prova dovrebbe permettere di compilare questa scheda con esempi osservati. Se emergono troppe risposte vaghe, restringi il compito prima di allargare l’automazione.