La progettazione della matrice di approvazione parte da soglie, approvatori di fallback, sostituti ed escalation, così gli schermi riflettono il reale percorso decisionale.
Una schermata pulita può comunque nascondere un processo confuso. Se la logica di approvazione non è definita prima, gli utenti possono vedere i pulsanti Approva e Rifiuta ma non sapere chi deve agire, quando deve farlo o cosa succede dopo.
Questa confusione emerge rapidamente nel lavoro concreto. Qualcuno invia una richiesta, arriva nell'app e la prima domanda è: "Va al manager, alla finanza o a entrambi?" Lo schermo sembra completo, ma il percorso decisionale manca.
Questo succede perché gli schermi fanno sembrare le regole più semplici di quanto siano. Un modulo può mostrare lo stato, i commenti e i pulsanti di azione, ma non può indovinare la matrice di approvazione reale dietro il processo. Se l'azienda ha limiti per importi, regole dipartimentali o deleghe temporanee, l'interfaccia inizia a rompersi non appena compaiono quei casi.
Spesso basta un'eccezione per spingere il lavoro fuori dall'app. Forse le approvazioni vanno solitamente al responsabile di reparto, tranne quando la richiesta è urgente, supera una certa soglia o l'approvatore è in ferie. Se quel caso non è mai stato mappato, le persone ricorrono a email, chat o fogli di calcolo.
Poi appare un problema più grande: ogni team inizia ad applicare la propria versione delle regole. Operations invia la richiesta in un modo, la finanza in un altro e il supporto gestisce le eccezioni diversamente dalle risorse umane. L'app diventa uno schermo condiviso per decisioni incoerenti invece che un processo condiviso.
I segnali di avvertimento sono di solito facili da individuare:
Gli aggiornamenti di policy espongono rapidamente questa debolezza. Quando la logica vive nello schermo invece che in regole di workflow chiare, ogni modifica di soglia o ruolo si trasforma in lavoro sulla UI. Questo rallenta i team, provoca nuovi errori e fa perdere fiducia agli utenti.
Lo schermo dovrebbe riflettere il percorso decisionale, non definirlo. Quando la matrice è chiara prima, l'interfaccia diventa più semplice, più stabile e più facile da usare.
Inizia dalla logica decisionale, non dallo schermo. Una solida matrice di approvazione nasce come una tabella semplice che mostra chi può approvare cosa, in quali condizioni e cosa succede quando qualcuno non è disponibile. Se quella logica è vaga, anche un'interfaccia raffinata confonderà le persone.
Per ogni tipo di richiesta, mappa i livelli di approvazione in ordine. Annota il ruolo che possiede ogni passo e cosa permette quel passo: approvare, rifiutare, revisionare o rinviare. I ruoli funzionano meglio dei nomi personali perché le persone si spostano, i team cambiano e il processo deve comunque reggere.
Poi definisci le regole che cambiano il percorso. L'importo è il trigger ovvio, ma raramente è l'unico. Le regole di instradamento spesso dipendono da regione, dipartimento, tipo di fornitore, categoria di richiesta o livello di rischio. Lo stesso importo può essere routine in un team e sensibile in un altro.
Le assenze hanno bisogno di regole anche loro. Se l'approvatore principale è assente, chi subentra immediatamente? Se il backup è temporaneo, quali date valgono? Senza questo, le richieste restano ferme perché nessuno sa chi le gestisce quella settimana.
I limiti di tempo contano altrettanto. Decidi cosa succede quando una richiesta non riceve risposta. Potresti inviare un promemoria dopo un giorno, effettuare un'escalation dopo due giorni e notificare operations dopo tre. Quelle scelte influenzano le etichette di stato, le notifiche e le viste delle code, quindi dovrebbero essere decise prima di progettare gli schermi.
Una matrice pratica risponde di solito a cinque domande basilari:
Se mappi quelle risposte presto, il resto della costruzione diventa molto più semplice.
Usa una tabella, una lavagna o un foglio di calcolo. Mantienila abbastanza semplice perché un manager, un team lead e il responsabile del processo possano capirla in una lettura.
Per prima cosa, elenca ogni tipo di richiesta che necessita approvazione. Non forzare tutto in un unico flusso generico se l'azienda già tratta le richieste in modo diverso. Una richiesta di acquisto, un rimborso, un'approvazione di sconto e una richiesta di accesso spesso richiedono approvatori, limiti e scadenze diversi.
Poi scrivi il primo approvatore e ogni punto decisionale successivo. Per ogni tipo di richiesta, annota chi la revisiona per primo e cosa succede dopo approvazione o rifiuto. Segui il percorso fino a raggiungere un esito finale come approvato, rifiutato, rimandato per modifiche o annullato.
Dopo di che, aggiungi le soglie che cambiano il percorso. Qui molte squadre si bloccano dopo. Se una richiesta sotto i $500 va al team lead ma tutto ciò che supera i $500 va al capo dipartimento, scrivilo ora. Se le richieste urgenti saltano un passaggio o seguono un percorso più veloce, catturalo anche.
Poi registra eccezioni, scadenze e stati finali. Includi casi come documenti mancanti, richieste duplicate, violazioni di policy e approvazioni scadute. La regola non è completa finché non sai come si comporta quando qualcosa va storto.
Infine, rivedi la bozza con le persone che oggi approvano le richieste. Chiedi dove il lavoro si blocca di solito, dove si saltano passaggi e cosa succede quando l'approvatore normale non è disponibile. Le abitudini reali spesso rivelano regole mai documentate.
Un piccolo esempio chiarisce il concetto. Immagina una richiesta d'acquisto: forniture d'ufficio sotto $200 vanno al team lead, software tra $200 e $2.000 va al manager di dipartimento e tutto ciò che supera quel limite richiede anche la finanza. Se il modulo non cattura importo e categoria fin da subito, l'interfaccia non può inviare la richiesta lungo il percorso giusto.
Le soglie funzionano solo quando le persone le leggono rapidamente e fanno la stessa scelta ogni volta. Se una regola dice "acquisti piccoli" o "fornitori ad alto rischio", persone diverse interpreteranno in modo diverso. Usa numeri fissi, date e condizioni nominate invece.
Una regola più chiara suona così: "Fino a $1.000 va al team lead. Da $1.001 a $5.000 va al manager di dipartimento. Oltre $5.000 va a finanza e al direttore." Nessuno deve indovinare a chi appartiene la richiesta.
L'importo è comune, ma non dovrebbe essere l'unico trigger se il tuo processo dipende da altri fattori. Un acquisto software a basso costo da un fornitore nuovo può richiedere più verifica rispetto a un ordine più grande da un fornitore approvato.
La maggior parte dei team ha bisogno solo di un piccolo insieme di regole di instradamento. Esempi comuni includono fascia di importo, stato del fornitore, categoria di acquisto, dipartimento e urgenza. L'importante non è il numero di regole, ma che tutti le applichino nello stesso modo.
Anche l'ordine delle regole è importante. Se le persone non sanno quale condizione prevale, instraderanno la stessa richiesta in modo diverso. Scegli un ordine e mantienilo coerente. Potresti controllare prima lo stato del fornitore, poi la categoria, poi l'importo. Oppure prima l'importo e gestire le eccezioni dopo. Entrambe le strade funzionano se tutti seguono la stessa sequenza.
È utile anche definire chi può oltrepassare una soglia e quando. Altrimenti, il personale aspetta troppo o aggira il processo con email e chat. "Il direttore finanziario può approvare richieste oltre il limite durante la chiusura di fine mese" è utile. "La leadership può fare eccezioni" non lo è.
Un test semplice funziona bene: dai lo stesso esempio a tre persone e chiedi dove dovrebbe andare. Se danno tre risposte diverse, le soglie sono ancora troppo vaghe.
Una matrice solida non si ferma all'approvatore principale. Il lavoro reale continua quando qualcuno è in ferie, malato o semplicemente non risponde in tempo. Se non pianifichi questo in anticipo, lo schermo può sembrare ordinato mentre il processo si blocca silenziosamente.
Inizia nominando l'approvatore di fallback per ogni passo importante. Deve essere una persona o un ruolo con il contesto giusto, non solo "il manager successivo" per default. Se un lead finanziario approva spese sopra una certa soglia, decidi chi subentra quando quella persona non è disponibile.
I sostituti temporanei devono avere limiti. Un sostituto dovrebbe avere i diritti di approvazione solo per un periodo definito, come le date di vacanza o un'assenza programmata. Questo mantiene chiara la responsabilità ed evita casi in cui qualcuno mantiene l'accesso all'approvazione molto dopo il previsto.
Una configurazione semplice dovrebbe rispondere a quattro cose: chi è l'approvatore principale, chi è il backup, per quanto tempo il sostituto può agire e quando la richiesta sale la catena.
Le escalation dovrebbero basarsi su trigger chiari, non su congetture. Trigger comuni includono tempo, importo, rischio o informazioni mancanti. Per esempio, se una richiesta di acquisto sopra $10.000 resta inattiva per 24 ore, potrebbe essere scalata al capo dipartimento.
Mantieni il percorso di escalation breve. Se le persone hanno bisogno di un diagramma complesso solo per capire chi riceve la richiesta dopo, la regola è probabilmente troppo complicata. Uno o due salti chiari sono di solito sufficienti.
Registra anche ogni decisione. Salva chi ha approvato, chi ha sostituito, quando è avvenuto il passaggio e perché la richiesta è stata scalata. Quello storico è importante quando qualcuno poi chiede perché una richiesta è stata ritardata o approvata da un sostituto.
Una regola in più che conta più di quanto sembri: evita i loop. Una richiesta non dovrebbe mai rimbalzare a qualcuno che l'ha già approvata, né a un sostituto che agisce per la stessa persona. Controlla la matrice per percorsi circolari prima di costruire la logica nell'app.
Immagina una piccola azienda che acquista beni di uso quotidiano. Un dipendente invia una richiesta con l'articolo, l'importo, la motivazione e la data necessaria. L'instradamento è guidato dalle regole, non da chi è online.
Se la richiesta è per $420, va direttamente al team lead. Così gli acquisti piccoli avanzano. Una richiesta da $3.200 salta il team lead e va al manager di dipartimento perché l'impatto sul budget è maggiore.
Ora prendi una richiesta da $7.800 per nuova attrezzatura. Il manager di dipartimento la revisiona ancora, ma non basta. Poiché l'importo supera $5.000, anche la finanza deve esaminarla. Ecco dove una matrice chiara aiuta: importi più alti aggiungono controllo senza introdurre incertezze.
Le assenze contano anche qui. Se il manager di dipartimento è in ferie, la richiesta non dovrebbe restare in sospeso. Un sostituto nominato la riceve automaticamente e può agire per il periodo definito.
I limiti di tempo richiedono lo stesso livello di chiarezza. Se nessuno agisce entro due giorni, la richiesta viene scalata a operations. Operations può seguire, riassegnare o assicurarsi che non blocchi il lavoro.
In questo esempio, la matrice risponde a poche domande semplici ma importanti: quanto si richiede, quale ruolo approva a ogni fascia, quando la finanza viene coinvolta, chi copre le assenze e cosa succede se una scadenza viene mancata.
Una volta che queste risposte sono definite, il design dello schermo diventa semplice. Il modulo deve solo raccogliere i dati corretti e la pagina della richiesta deve mostrare l'approvatore corrente, eventuali sostituti e se l'orologio di escalation è attivo.
La maggior parte dei rifacimenti inizia prima che venga disegnato un singolo schermo. I team indovinano il percorso di approvazione e poi cercano di adattare la UI a regole che non erano mai state concordate.
Un errore comune è copiare l'organigramma e chiamarlo workflow. Può sembrare ordinato, ma le richieste reali si muovono spesso per importo, rischio, sede o tipo di richiesta. Se la matrice ignora questo, gli schermi avranno poi campi extra, stati aggiuntivi ed eccezioni scomode.
Un altro problema è dimenticare i casi speciali. Richieste urgenti, acquisti regolamentati o richieste inter-team spesso seguono percorsi diversi. Se queste eccezioni non vengono mappate presto, le persone chiedono soluzioni manuali e l'interfaccia si riempie di opzioni una tantum che confondono tutti.
I team creano guai anche quando assegnano a due persone lo stesso ruolo senza una regola di spareggio. Se entrambe possono approvare, chi agisce per primo? Se non sono d'accordo, quale decisione vale? Senza quella risposta, le richieste rimbalzano e gli utenti perdono fiducia.
Le regole sui sostituti sono un altro punto debole. Un sostituto dovrebbe coprire un'assenza, non diventare silenziosamente un proprietario secondario per sempre. Quando coperture temporanee e proprietà permanente si mescolano, i report diventano confusi e la responsabilità scompare.
Progettare i moduli prima che l'instradamento sia definito crea un altro giro di rifacimenti. Un modulo può sembrare completo, ma una volta finalizzate le regole di approvazione, spesso si scoprono campi mancanti come fascia di importo, dipartimento, urgenza o flag di policy. Allora layout, validazioni e notifiche devono cambiare.
Un controllo rapido aiuta a intercettare questo presto:
Se una qualsiasi risposta è ambigua, fermati lì. Sistemate la matrice prima di rifinire gli schermi.
Prima di abbozzare un modulo o una badge di stato, testa la logica in linguaggio semplice. Una buona matrice di approvazione dovrebbe essere facile da spiegare senza aprire un diagramma. Se un manager, un lead finanziario o un collega di operations non riesce a descrivere il percorso in circa un minuto, il processo è ancora troppo vago per lavorare sulla UI.
Esegui una revisione veloce usando esempi reali. Chiedi a una persona di spiegare il percorso completo dalla richiesta alla decisione finale. Verifica che ogni esito probabile abbia un prossimo approvatore nominato, non solo il percorso ideale. Riscrivi soglie vaghe come regole esatte tipo "$1.000 e sotto" o "più del 10% di sconto". Conferma che regole di fallback ed escalation usino limiti temporali chiari come "dopo 24 ore" o "dopo 2 giorni lavorativi."
Poi testa la tracciabilità. Qualcuno chiederà in seguito perché una richiesta è stata ritardata, chi ha approvato un'eccezione o quando un sostituto è intervenuto. Il tuo processo dovrebbe già rispondere a queste domande. Timestamp, storico decisionale e cambiamenti di stato chiari non sono extra; fanno parte del set di regole.
Uno scenario semplice spesso mette in luce i punti deboli. Immagina una richiesta da $4.800 arrivata un venerdì pomeriggio mentre l'approvatore abituale è assente. Chi la prende dopo? Quanto tempo aspetta il sistema prima di muoversi? Cosa succede se anche il backup non reagisce? Se quelle risposte non sono scritte, l'interfaccia nasconderà confusione invece di risolverla.
Quando questi controlli passano, il design degli schermi diventa molto più semplice. Non stai più indovinando cosa mostrare nell'interfaccia. Stai dando una forma chiara a regole chiare.
Una volta chiare le regole, costruisci il processo prima di rifinire gli schermi. Parti dalla logica, dai campi dati e dagli stati di approvazione. Se l'instradamento funziona, l'interfaccia sarà molto più semplice da progettare. Se l'instradamento è ancora in evoluzione, schermate attraenti nasconderanno solo i problemi.
Una prima versione pratica include di solito le basi: tipo di richiesta, importo, dipartimento, approvatore corrente, stato finale e uno storico chiaro di ogni decisione. Poi aggiungi le regole che spostano una richiesta avanti, la inviano a un approvatore di fallback o scatenano un'escalation quando qualcuno non risponde in tempo.
Mantieni le prime schermate semplici. Un richiedente dovrebbe poter inviare, controllare lo stato e rispondere a domande di follow-up. Un approvatore dovrebbe poter revisionare, approvare, rifiutare o riassegnare. Questo è sufficiente per testare se il workflow ha senso nell'uso quotidiano.
Un ordine di costruzione sensato è semplice:
Questa fonte di verità condivisa conta più di quanto molti team si aspettino. Se il mobile mostra uno stato, il pannello web un altro e il backend segue soglie diverse, la fiducia svanisce rapidamente.
Se stai costruendo questo in AppMaster, una matrice chiara rende la configurazione molto più semplice. Puoi modellare prima i dati, la business logic e il flusso di approvazione, poi portare lo stesso processo su backend, web e mobile senza riscrivere le regole in strumenti separati.
Usa un caso reale per il primo test. Esegui una richiesta d'acquisto con una soglia, un approvatore sostituto e un'escalation per ritardo. Osserva dove le persone esitano, quali dati mancano e quali etichette di stato confondono.
Migliora la formulazione e il layout dopo quello. Quando il processo funziona con una richiesta reale, gli schermi sono più facili da progettare e molto meno propensi a essere rifatti una settimana dopo.
07 mar 2026
9 min
07 mar 20269 min
03 mar 20267 minSperimenta con AppMaster con un piano gratuito.
Quando sarai pronto potrai scegliere l'abbonamento appropriato.
