Chiedi alla maggior parte dei team se hanno un processo di approvazione e diranno sì. Poi chiedi loro di mostrarti l’ultima approvazione che hanno dato, chi l’ha approvata, cosa hanno visto al momento dell’approvazione, quale versione hanno firmato, quando è avvenuto esattamente, e guarda la fiducia svanire dalla stanza.

La verità è che la maggior parte dei “processi di approvazione” sono solo abitudini. Qualcuno mostra qualcosa a qualcun altro, l’altra persona dice qualcosa come “a me sembra ok”, e questo viene considerato approvato. Il che funziona bene finché il cliente non chiede perché il testo è cambiato, o il team legale non segnala qualcosa che non è mai stato esaminato, o due persone non ricordano la stessa conversazione in modo completamente diverso.

Abbiamo visto questo scenario in agenzie, team operativi, dipartimenti HR, servizi clienti, ovunque il lavoro abbia bisogno di un’approvazione umana prima di andare avanti. La versione informale dell’approvazione è così diffusa che la maggior parte delle persone non la considera nemmeno un problema finché non si trova nel mezzo di un malinteso molto costoso.

L’approvazione che viveva in un thread di chat

Ecco uno scenario più comune di quanto chiunque vorrebbe ammettere. Un’agenzia invia una bozza a un cliente. Il cliente risponde in un thread di email: “Sembra bene, vai avanti.” L’account manager interpreta questo come approvazione finale. Tre settimane dopo, quando la campagna è attiva, il cliente dice di non aver mai approvato la versione finale, solo la bozza. Ora c’è una disputa, alcune chiamate molto tese, e una relazione che è un po’ peggiore di prima.

Nessuno ha mentito. Nessuno agiva in malafede. Il processo di approvazione era semplicemente troppo vago per proteggere entrambe le parti. Non c’era alcuna registrazione di esattamente cosa era stato visto, quando e da chi. Un’emoji pollice su in un thread di email non è un contratto, ma per molti team è come se lo fosse.

Come appaiono davvero le approvazioni strutturate

Abbiamo integrato i workflow di approvazione in Gript in modo che quando qualcosa richiede una firma, l’intero processo avvenga all’interno del lavoro, non in un canale laterale che nessuno può tracciare in seguito.

Assegni un revisore. Riceve una notifica. Vede l’elemento reale, in pieno contesto, con tutto ciò di cui ha bisogno per prendere una decisione. Approva o rifiuta, con un commento facoltativo. Quella decisione viene registrata, con marca temporale, e visibile a tutti con accesso alla lavagna. Fatto.

Niente inseguimenti. Nessuna ambiguità. Nessuna conversazione “aspetta, abbiamo avuto l’approvazione per questo?” la mattina di un lancio.

La parte che le persone non considerano fino a quando non ne hanno bisogno: la traccia

Oltre al fatto che le approvazioni avvengano in modo pulito, i workflow strutturati ti danno qualcosa che le approvazioni informali non possono mai dare: un registro. Non perché sei paranoico, ma perché tra tre mesi qualcuno chiederà. Qualcuno chiede sempre.

“Chi ha approvato questo?” “Il team legale ha esaminato la versione finale?” “Quando ha approvato il cliente il cambio di portata?” Se hai un workflow di approvazione strutturato, puoi rispondere a quelle domande in circa dieci secondi. Se non ce l’hai, stai scorrendo vecchi messaggi di Slack sperando che la risposta sia da qualche parte.

Abbiamo costruito questa funzionalità in parte perché ne avevamo abbastanza di vedere buoni team finire nei guai evitabili, non perché fossero disorganizzati, ma perché il loro processo di approvazione viveva da qualche parte dove nessuno aveva pensato di cercare. Portarlo nel lavoro stesso aveva semplicemente senso.