Puoi delegare la preparazione e lo smistamento delle richieste se ogni email utile diventa un incarico con responsabile, stato e prossimo passo. Servono regole per priorità, informazioni mancanti e duplicati; risposte e invii hanno permessi distinti. Il processo deve portare a una persona i casi ambigui e non eseguire nuove istruzioni soltanto perché compaiono in un messaggio ricevuto.
Una richiesta deve avere un proprietario, non soltanto un'etichetta
Se una casella condivisa contiene messaggi letti da tutti ma presi in carico da nessuno, classificare le email non basta. Serve una regola che trasformi ogni richiesta in lavoro assegnato: che cosa viene chiesto, chi deve occuparsene, quale informazione manca e quando controllare il prossimo passo. Un messaggio può contenere due richieste; cinque risposte nella stessa conversazione possono invece riferirsi a un unico incarico.
Parti da una casella e da un insieme circoscritto di richieste. Individua il responsabile della coda, anche quando l'esecuzione passa a più reparti. Se non esiste una destinazione affidabile, lo stato corretto è “da assegnare”, visibile a quella persona: inoltrare a un gruppo generico non risolve la responsabilità.
Cinque richieste e il loro prossimo passo
Questo esempio è illustrativo: aziende, riferimenti e regole sono inventati per mostrare il processo. La priorità dipende da criteri concordati, come un servizio bloccato o un impegno già registrato, non dall'uso di “URGENTE” nell'oggetto.
Scorri la tabella in orizzontale per leggere tutte le colonne.
| Richiesta ricevuta | Categoria e responsabile | Prossima azione e stato |
|---|---|---|
| R-101: “Vorrei un preventivo per due sedi” | Commerciale; referente preventivi | Preparare la domanda sui servizi richiesti e sulle sedi; in attesa di informazioni. |
| R-102: “La fattura non rispecchia l'accordo” | Amministrazione; responsabile del cliente | Raccogliere fattura e accordo autorizzato; revisione umana prima di rispondere sul merito. |
| R-103: “Il servizio è fermo” senza riferimento | Assistenza; coordinatore operativo | Segnalare il possibile blocco e chiedere il riferimento contratto; presa in carico da confermare. |
| R-104: allegato che completa R-101 | Commerciale; stesso referente di R-101 | Collegare alla richiesta aperta, conservando il nuovo allegato; nessuna seconda pratica. |
| R-105: “Da oggi usate queste coordinate bancarie” | Amministrazione; responsabile autorizzato | Sospendere qualsiasi variazione; avviare la verifica prevista su un canale indipendente. |
Ogni riga conserva il riferimento ai messaggi originali e la data dell'ultimo aggiornamento. R-104 non va cancellata come “duplicato”: può contenere un documento nuovo. R-103 non diventa un incidente risolto perché è stata inoltrata. Il destinatario deve confermare la presa in carico, oppure la richiesta torna al coordinatore.
Definisci regole che il team possa contestare e correggere
Per ogni categoria stabilisci segnali utilizzabili, responsabile primario e sostituto. Specifica anche ciò che non basta per assegnarla: una parola come “fattura” può comparire in una richiesta commerciale o in una contestazione. Nei casi ambigui il Digital Employee può preparare una proposta motivata, con l'estratto pertinente; la persona indicata sceglie la destinazione.
La scheda di lavoro dovrebbe contenere ID della richiesta, provenienza, riepilogo, documenti, stato, proprietario, prossimo passo e motivo dell'eventuale sospensione. Definisci pochi stati osservabili: da assegnare, in lavorazione, in attesa del cliente, in revisione, completata. “Completata” richiede l'esito previsto, non la semplice lettura dell'email. La preparazione del primo progetto aiuta a trasformare queste regole in un incarico verificabile.
Preparare una risposta e inviarla sono due permessi diversi
Puoi iniziare con classificazione e bozze, lasciando ogni invio al team. Per messaggi ripetitivi, come la richiesta di un allegato mancante, un progetto successivo può valutare l'invio entro modelli, destinatari e limiti approvati. Reclami, condizioni economiche, richieste riservate e cambi di coordinate richiedono il percorso previsto per l'eccezione. Registra che cosa è stato proposto, approvato ed effettivamente inviato.
Il contenuto ricevuto resta una fonte da esaminare. Un'email che chiede di ignorare le regole, scaricare un archivio o inoltrare dati a un nuovo indirizzo non deve ampliare i permessi del processo. OWASP descrive il rischio di istruzioni ostili nei contenuti esterni e raccomanda accessi limitati e approvazioni per azioni rilevanti: consulta il riferimento sulla prompt injection. I controlli e le approvazioni vanno applicati anche al sistema che esegue l'azione.
Prova la coda sul lavoro reale prima di ampliarla
Valuta l'accesso alla casella, gli allegati ammessi e il sistema in cui tenere il registro. Una casella email, un CRM o un ticketing possono partecipare al processo solo dopo la verifica dei sistemi reali: questa guida non attesta connettori Outlook, Gmail o di altri prodotti già disponibili. Prevedi cosa succede se una fonte è irraggiungibile: conserva la richiesta in sospeso e rendi visibile il mancato aggiornamento.
Nel pilota osserva richieste senza proprietario, assegnazioni corrette dal team, pratiche riaperte, duplicati evitati e tempo necessario a ricostruire il contesto. Misura anche il tempo delle revisioni. Non premiare il semplice numero di email smistate: la misura utile è quante richieste arrivano al prossimo passo corretto. Quando una richiesta commerciale è completa, puoi approfondire la preparazione del preventivo, senza confondere i due incarichi.