Il design dei percorsi di eccezione aiuta i team a gestire richieste rifiutate, documenti mancanti e approvazioni parziali prima che il rifacimento rallenti l'intero processo.
La maggior parte dei team inizia con la versione pulita di un workflow. Arriva una richiesta, qualcuno la valuta e viene approvata. Sembra efficiente, ma nasconde dove avviene il lavoro reale.
Il percorso ideale è di solito il più breve. Il modulo è completo, gli allegati ci sono e il revisore sa esattamente cosa fare. Nelle operazioni reali, quello raramente è ciò che causa ritardi.
I ritardi iniziano quando qualcosa manca, è poco chiaro, è in ritardo o è solo parzialmente accettabile. Un responsabile può approvare il budget ma rifiutare una voce. La contabilità può aver bisogno di un documento fiscale mai caricato. Un responsabile supporto può rimandare indietro una richiesta perché il campo motivo è troppo vago. Ognuno di questi momenti crea passaggi extra, messaggi in più e attese.
Se queste situazioni non vengono pianificate in anticipo, le persone prendono decisioni al volo. Un revisore invia un'email. Un altro lascia un commento nello strumento. Un terzo rifiuta la richiesta senza spiegazioni. Il richiedente resta a indovinare: deve correggere l'errore, ricominciare o chiedere aiuto a qualcuno?
Questa confusione ha un costo. Rallenta chi ha inviato la richiesta, chi la rivede e chi viene coinvolto per spiegare cosa è successo. Un workflow che sembrava semplice su una lavagna si trasforma in chat di follow-up, invii duplicati e passaggi manuali.
Un flusso di approvazione di base è facile da disegnare:
La versione reale è più complessa. E se manca un documento? E se solo parte della richiesta viene approvata? E se il revisore la rifiuta ma l'utente può correggerla? Questi non sono casi insoliti. Per molti team, sono i casi normali.
Per questo il design dei percorsi di eccezione merita attenzione prima che si disegnino le schermate e si nominino gli stati. Il percorso di eccezione definisce cosa succede quando la realtà interrompe il piano, e la realtà lo fa spesso.
Se stai costruendo un'app interna di approvazione, anche in una piattaforma no-code come AppMaster, i casi rifiutati e incompleti richiedono la stessa cura del caso approvato. Influenzano i messaggi che le persone vedono, le azioni successive e se il workflow aiuta a riprendersi o lascia bloccati.
Un percorso ideale mostra l'intento. I percorsi di eccezione mostrano se il processo può resistere all'uso reale.
Un percorso di eccezione è ciò che succede quando una richiesta non può procedere normalmente. Non è un caso remoto. È la parte del processo che gestisce il disordine del mondo reale: una richiesta viene negata, un modulo è incompleto, una parte è approvata ma un'altra no, o il lavoro semplicemente si blocca.
Un percorso di eccezione chiaro usa un linguaggio semplice. Invece di uno status vago come "Fallito", dì cosa è successo: "Rifiutato perché il budget supera il limite" o "In attesa di documento d'identità." Le persone devono sapere cosa non va, chi deve agire e cosa succede dopo.
La maggior parte dei workflow si rompe in modi prevedibili:
Le informazioni mancanti sono uno dei problemi più comuni. Immagina un modulo di onboarding fornitore che richiede un documento fiscale e un numero di conto bancario. Se uno dei due manca, il sistema non dovrebbe fermarsi. Dovrebbe segnare la richiesta come incompleta, mostrare esattamente cosa manca e rimandarla alla persona giusta.
Le approvazioni parziali sono altrettanto importanti. Pensa a una richiesta di viaggio per volo, hotel e budget pasti. Il responsabile approva volo e hotel ma taglia il budget pasti. Il processo ora ha bisogno di regole. Il dipendente accetta la modifica, aggiorna la richiesta o annulla il viaggio?
Anche i blocchi contano. Una richiesta può restare ferma perché il revisore assegnato ha lasciato l'azienda, il team non ha previsto un sostituto o il processo raggiunge uno step senza un proprietario successivo. Tecnicamente nulla è rotto, ma la richiesta non può comunque muoversi.
Se non progetti questi percorsi presto, le persone li gestiscono con email, chat o note su fogli di calcolo. Presto nessuno sa quale versione sia quella finale.
Prendi una richiesta di viaggio per un responsabile commerciale che vuole partecipare a una conferenza di due giorni. Su carta, il flusso sembra facile: il dipendente inserisce le date del viaggio, il costo stimato e il motivo. Il manager la approva, la contabilità conferma il budget e il viaggio passa alla prenotazione.
Quel flusso è pulito, ma anche incompleto.
Ora rompi la stessa richiesta. Il dipendente carica la stima del volo e il biglietto della conferenza ma si dimentica del preventivo dell'hotel. Se il sistema conosce solo "inviato" e "approvato", le persone si bloccano in fretta. La contabilità può vedere una richiesta incompleta, il manager può pensare che sia pronta e il dipendente non sapere cosa manca.
Un flusso migliore dà alla richiesta uno stato proprio, come "In attesa di documento" o "Necessita aggiornamento." Il dipendente dovrebbe vedere un messaggio chiaro: "Aggiungi il preventivo dell'hotel prima che questa richiesta possa passare alla contabilità." Il manager non dovrebbe dover rifiutare tutto solo per chiedere un file.
Aggiungi ora un secondo problema. Il manager è d'accordo che il viaggio debba avvenire, ma non per l'importo totale. Approva il volo e una notte d'hotel, ma respinge la tariffa del workshop e la seconda notte d'hotel.
Qui molti team scoprono di non avere un vero processo di approvazione parziale.
Se il workflow non può approvare solo una parte della richiesta, le persone usano soluzioni alternative. Possono rifiutare l'intera richiesta e chiedere al dipendente di inviarla di nuovo. Oppure la contabilità potrebbe approvare l'intero importo per errore perché il sistema registra una sola decisione sì/no.
Un modello più chiaro traccia ogni voce di costo, o almeno il totale approvato. Una richiesta potrebbe mostrare:
Questo singolo esempio mostra perché gli errori nei workflow di approvazione spesso derivano da regole mancanti, non da persone distratte. Se definisci quelle regole prima di progettare le schermate, il resto del workflow diventa molto più affidabile.
Un buon modo per migliorare un workflow è presumere che la richiesta non passerà liscia. Questo cambiamento migliora subito la qualità del design.
Inizia dai casi disordinati: il modulo è incompleto, la policy è ambigua, l'approvatore è assente o solo una parte della richiesta deve procedere. La maggior parte dei team può raggruppare questi casi in tre schemi principali:
Questo mantiene il lavoro gestibile. Invece di inventare una nuova risposta per ogni caso, definisci un piccolo set di schemi e applicali a ogni tipo di richiesta.
Lavora in questo ordine.
Per prima cosa, elenca ogni punto in cui la richiesta può fermarsi. Pensa a documenti mancanti, valori non validi, violazioni di policy, scadenze scadute, invii duplicati e revisione manuale. Se la richiesta può aspettare, fallire o tornare al mittente, segnalo.
Poi, decidi cosa succede in ogni caso. Per ogni eccezione, rispondi a quattro domande semplici:
Per esempio, immagina che un dipendente presenti una nota spese di $600. Mancano la ricevuta dell'hotel e un pasto è oltre la policy. Se progetti solo il percorso ideale, la richiesta o resta bloccata o viene rifiutata come un blocco unico. Se progetti prima le eccezioni, il sistema può mettere in pausa il rimborso per la ricevuta mancante, notificare il dipendente con un messaggio chiaro e comunque segnare gli elementi consentiti come approvati condizionatamente.
Qui entrano in gioco le regole per le approvazioni parziali. Devi decidere se l'importo approvato può procedere ora, se il resto resta in attesa e se il richiedente può modificare solo la parte contestata o deve inviare di nuovo l'intera richiesta.
Se stai costruendo il processo in AppMaster, questo è il momento di mappare quei rami nella logica di business prima di lucidare l'interfaccia. È molto più facile fidarsi di un workflow quando rifiuto, ritorno per modifiche e approva con condizioni sono trattati come percorsi separati invece che nascosti dietro uno stato vago.
Infine, testa uno scenario reale dall'inizio alla fine. Usa numeri reali, un vero documento mancante e una eccezione di policy. Se una persona che legge il flusso non riesce a capire cosa succede dopo in meno di un minuto, il design è ancora troppo vago.
Le schermate sembrano concrete, quindi i team spesso iniziano da lì. Schizzano pulsanti, moduli e dashboard prima di accordarsi sulle regole. Questo crea di solito problemi più avanti, perché l'interfaccia finisce per nascondere decisioni che nessuno ha preso.
Un ordine migliore è semplice: definisci stati, passaggi, scadenze e le prove richieste per procedere. Poi costruisci le schermate attorno a quello.
Il design dei percorsi di eccezione diventa più semplice quando l'insieme di regole è piccolo e chiaro. Se una richiesta può essere approvata, rifiutata, rimandata per correzioni o parzialmente approvata, quegli stati devono avere nomi semplici che significano una sola cosa. Evita quasi-duplicati come "restituita", "riaperta" e "necessita modifiche" a meno che non si comportino davvero in modo diverso.
Prendi una richiesta di acquisto. Un manager la apre e nota che manca il preventivo. Se il team non ha deciso cosa succede dopo, le persone improvvisano. Un manager la rifiuta. Un altro la lascia in sospeso. Un terzo invia un messaggio e non cambia nulla nel sistema. Presto nessuno si fida dello stato.
Scrivi la regola prima. Quando manca un preventivo, la richiesta passa a "Necessita documenti." Il richiedente è responsabile del passo successivo. La richiesta resta lì per cinque giorni lavorativi. Se non arriva nulla, cambia in "Scaduto" e serve una nuova sottomissione.
Quella sola regola plasma il prodotto meglio di un mockup. Ora sai cosa l'utente dovrebbe vedere, quale promemoria inviare e quale cronologia mantenere.
Un set di regole pratico dovrebbe rispondere a quattro domande:
Le approvazioni parziali richiedono lo stesso livello di cura. Se il viaggio è approvato ma il costo dell'hotel no, il richiedente modifica lo stesso record o ne crea uno nuovo? La contabilità rivede solo la parte cambiata o tutto di nuovo? Se non si decide presto, la schermata può sembrare ordinata mentre il processo dietro resta disordinato.
Quando i team concordano prima le regole, l'interfaccia diventa più semplice. Più importante, gli utenti sanno esattamente cosa fare dopo, anche quando la risposta è "non ancora approvato."
Un messaggio di eccezione scarso rallenta tutto. Le persone non hanno solo bisogno di sapere che qualcosa ha fallito. Hanno bisogno di sapere cosa è successo, cosa riguarda e cosa fare dopo.
Qui il design diventa reale per gli utenti. Le tue regole interne possono essere chiare, ma se lo schermo mostra solo "Errore" o "In attesa di revisione", le persone indovineranno, invieranno i file sbagliati di nuovo o chiederanno supporto.
Prendi un esempio di approvazione fornitore. Un utente invia un modulo con documento fiscale, dati bancari e assicurazione. I dati bancari vanno bene, il documento fiscale è scaduto e la prova di assicurazione manca. Se il sistema mostra solo "Richiesta non approvata", l'utente non ha una chiara azione successiva.
Un messaggio migliore suona così: "I tuoi dati bancari sono stati approvati. Ci serve ancora un documento fiscale aggiornato e la prova di assicurazione prima dell'approvazione finale." Questa frase separa ciò che è fatto da ciò che resta da fare e risparmia tempo.
I buoni messaggi rispondono di solito a quattro piccole domande:
Quest'ultimo punto conta. Le persone sono più propense a completare l'azione quando il passo successivo è ovvio. "Carica il file mancante e invia di nuovo per la revisione" è molto meglio di "Azione richiesta."
Etichette vaghe creano anche ansia. "In attesa di revisione" può significare aspettare una persona, dati mancanti o un controllo interno. Se conosci la ragione, dilla chiaramente. "In attesa di approvazione del manager" e "In attesa di prova di residenza" non sono la stessa cosa e non dovrebbero apparire uguali.
Se un processo permette approvazioni parziali, mostralo chiaramente nello stato stesso. Una breve ripartizione spesso funziona meglio di un'etichetta unica:
Ora l'utente può correggere solo ciò che conta. Non deve ricominciare da capo.
Qui la riesubmission dovrebbe essere facile da trovare. Metti l'azione successiva vicino al messaggio, non in un'altra schermata. Se costruisci il flusso in AppMaster, aiuta far corrispondere il testo visibile all'utente agli stati effettivi del processo così l'app dice esattamente cosa sta facendo il workflow.
Buoni messaggi riducono i ticket di supporto, accelerano le approvazioni e rendono il processo più equo. Le persone possono accettare un rifiuto quando lo capiscono.
La maggior parte del rifacimento inizia da un'errata supposizione: il percorso normale è la cosa principale da progettare. I team mappano richiesta inviata, approvata, completata e si fermano lì. Poi arriva la vita reale: manca un file, un manager vuole modifiche o solo una parte può procedere.
Questa lacuna genera lavoro extra in fretta. Le persone inventano soluzioni manuali, inviano messaggi laterali e rinominano stati al volo. Alcune settimane dopo, nessuno si fida del workflow perché ogni eccezione sembra un caso speciale.
Un errore comune è trattare il percorso ideale come il prodotto e tutto il resto come pulizia. Immagina una nota spese che richiede una ricevuta, l'approvazione del dipartimento e la revisione della contabilità. Se manca la ricevuta, la richiesta si mette in pausa, torna al dipendente o viene rifiutata? Se quella regola non è chiara dall'inizio, il team di solito la sistema dopo con email e commenti.
Nomi di stato confusi causano un altro giro di rifacimenti. Etichette come "In revisione 2" o "Azione in sospeso" sembrano innocue, ma costringono le persone a indovinare cosa succede dopo. Nomi chiari riducono gli errori perché mostrano il problema, il proprietario, l'esito o il passo successivo.
La responsabilità è un altro punto dove i workflow si rompono. Una richiesta non dovrebbe mai rimanere in uno stato che non appartiene a nessuno. Se un caso è in attesa, qualcuno deve essere responsabile di farlo procedere, chiedere più informazioni o chiuderlo. Altrimenti accumulano ritardi silenziosi e gli utenti pensano che il sistema abbia perso la loro richiesta.
L'approvazione parziale è spesso gestita male. I team la trattano come un rifiuto totale perché sembra più semplice. Ma quei risultati significano cose diverse. Se una richiesta di viaggio chiede volo, hotel e pasti, la contabilità potrebbe approvare volo e hotel ma negare i pasti. Quel caso richiede un percorso proprio, un messaggio dedicato e spesso un'azione di follow-up.
Quando l'approvazione parziale viene confusa con il rifiuto, le persone reinviano l'intera richiesta, duplicano documenti e rifanno revisioni già completate. Questo è puro rifacimento.
Un test semplice aiuta: leggi ogni stato non ideale e chiediti: "Chi è il responsabile, cosa vede l'utente e cosa succede dopo?" Se la risposta è vaga, il processo probabilmente si romperà nello stesso punto in futuro.
Prima di costruire schermate o automatizzare qualcosa, fai un'ultima verifica sui casi disordinati. Un buon design dei percorsi di eccezione spesso è solo poche decisioni chiare prese presto, prima che la confusione diventi lavoro extra.
Se una richiesta è rifiutata, in pausa o solo parzialmente approvata, qualcuno dovrebbe sempre sapere cosa succede dopo, chi lo fa e quali informazioni mancano.
Usa questo controllo rapido su ogni eccezione nel tuo processo:
Poi esegui un test semplice. Affida il processo a qualcuno che non ha partecipato al progetto. Dagli una richiesta rifiutata e una con un documento mancante. Se non riesce a capire cosa fare in meno di un minuto, il flusso è ancora troppo vago.
Un piccolo esempio chiarisce il punto. Immagina che un manager approvi una richiesta software ma rifiuti la parte hardware. Se lo stato dice solo "Parzialmente approvato", il dipendente può pensare che tutto possa procedere. Uno stato migliore dice esattamente cosa è approvato, cosa è negato e se il dipendente può inviare di nuovo la parte mancante.
Se vuoi trasformare quelle regole in un'app interna funzionante, mappa prima gli stati di eccezione e costruisci il percorso ideale dopo. In AppMaster, questo può significare definire stati, regole di business e campi obbligatori prima di pensare alle schermate lucidate. È un modo pratico per creare applicazioni no-code che gestiscano il lavoro reale, non solo la versione ideale.
Il passo successivo è semplice: elenca le tue prime cinque eccezioni, assegna un proprietario a ciascuna e scrivi il messaggio che l'utente dovrebbe vedere. Se queste tre parti sono chiare, la fase di costruzione di solito diventa molto più semplice.
Perché il percorso ideale non è sufficiente per un workflow di approvazione?Perché i ritardi reali di solito avvengono quando qualcosa è mancante, poco chiaro, in ritardo o solo in parte approvato. Se progetti solo il flusso pulito, le persone finiscono per risolvere i problemi con chat, email e soluzioni manuali.
Quali percorsi di eccezione dovrei progettare per primi?Inizia con i casi che si verificano più spesso: rifiuto, informazioni mancanti e approvazione parziale. Aggiungi poi i blocchi, come una richiesta senza responsabile o senza passo successivo definito.
Quali stati dovrebbe avere un'app di approvazione?Usa un set ridotto di stati chiari che ciascuno significhi una sola cosa. Un default pratico è: approvato, rifiutato, necessita documenti, necessita modifiche, parzialmente approvato e scaduto, se usi scadenze.
Come dovrebbe gestire il processo i documenti mancanti?L'utente dovrebbe vedere esattamente cosa manca e cosa fare dopo. Un buon comportamento predefinito è spostare la richiesta in uno stato come "Necessita documenti", elencare chiaramente gli elementi mancanti e rimandarla alla persona giusta invece di rifiutare l'intera richiesta.
Come gestisco le approvazioni parziali senza generare rifacimenti?Trattalo come un percorso a sé, non come un rifiuto totale. Mostra cosa è stato approvato, cosa è stato negato, il nuovo totale approvato se rilevante, e se il richiedente può accettare la modifica, aggiornare la richiesta o inviare di nuovo solo la parte contestata.
Cosa dovrebbe succedere quando una richiesta resta bloccata senza azione?Assegna a ogni stato di attesa un proprietario e una regola temporale. Se un revisore è assente o una richiesta resta troppo a lungo, il workflow dovrebbe scalare, riassegnare o scadere invece di restare bloccato.
Cosa rende utile un messaggio di eccezione?Sii chiaro e specifico. Indica quale parte è stata rifiutata o manca, quale parte è già stata accettata, cosa deve fare l'utente e cosa accade dopo la nuova sottomissione.
Dovrei progettare prima le schermate o prima le regole del workflow?Definisci prima le regole. Concorda stati, responsabili, scadenze, file richiesti e azioni successive prima di abbozzare pulsanti o dashboard, perché l'interfaccia deve riflettere decisioni già prese.
Come costruirei questo tipo di workflow in AppMaster?Mappa gli stati di eccezione nella logica di business prima di rifinire l'interfaccia. In AppMaster ciò significa definire stati, campi obbligatori, responsabilità e rami come rifiuto, ritorno per modifiche e approvazione condizionata prima di lucidare l'UI.
10 mar 2026
11 min
08 mar 202611 min
07 mar 20266 minSperimenta con AppMaster con un piano gratuito.
Quando sarai pronto potrai scegliere l'abbonamento appropriato.
