Marco ha scritto le procedure. Tutte. Onboarding clienti, gestione fornitori, chiusura mese. Le ha messe in una cartella condivisa con accesso per tutti.
Sei mesi dopo, continua a spiegare le stesse cose alle stesse persone. La cartella è lì, intatta, con la data di creazione che non è mai cambiata.
Il problema non è che il team non legge. Il problema è che Marco ha scritto procedure pensando che il lavoro fosse finito nel momento in cui le ha salvate. Ma il vero lavoro inizia dopo — nel modo in cui quella procedura viene costruita, testata e posizionata nel flusso quotidiano.
C’è una differenza misurabile tra una SOP che viene seguita e una che viene ignorata. Non dipende dalla lunghezza, dalla formattazione, o dallo strumento usato. Dipende da alcune scelte specifiche fatte nel momento in cui la si scrive.
Perché la maggior parte delle SOP non sopravvive alla prima settimana
Una procedura operativa standard nasce con un’intenzione buona: ridurre la dipendenza dall’imprenditore, standardizzare il lavoro, rendere il team autonomo. Poi, nella pratica, non succede nulla di tutto questo.
Le ragioni sono quasi sempre le stesse:
- La procedura descrive come dovrebbe funzionare il processo, non come funziona davvero oggi
- I passaggi sono scritti in modo che chi li ha scritti li capisce, ma chi li deve seguire no
- Non c’è un trigger chiaro — nessuno sa quando applicarla
- Vive in un posto diverso da dove si lavora — aprirla richiede uno sforzo aggiuntivo
- Non ha un responsabile: nessuno la aggiorna, diventa obsoleta, e a quel punto seguirla diventa controproducente
Il risultato è che il team torna a fare come ha sempre fatto — non per abitudine o resistenza, ma perché è più efficiente. E l’imprenditore torna a essere il punto di riferimento per tutto.
| SOP che viene ignorata | SOP che viene seguita |
| Scritta da chi supervisiona | Scritta con chi esegue |
| Parte dal risultato ideale | Parte da come funziona oggi |
| Passaggi generici, interpretabili | Passaggi specifici, con trigger |
| Vive in un documento separato | Vive nel tool di lavoro |
| Nessun responsabile di aggiornamento | Revisione programmata |
Le scelte che separano una SOP usata da una ignorata
Scrivi con chi esegue, non per chi esegue
La distinzione sembra sottile, ma cambia tutto. Quando scrivi da solo — o peggio, quando deleghi la scrittura a qualcuno che non esegue quel processo — produci un documento che descrive come le cose dovrebbero andare nel mondo ideale.
Chi esegue conosce i casi edge, le eccezioni, i punti in cui il processo si inceppa davvero. Coinvolgerlo nella scrittura non rallenta il lavoro — lo rende utilizzabile.
Il metodo più rapido: fai eseguire il processo a quella persona mentre la osservi, o chiedi di registrare lo schermo. Poi trascrivete insieme i passaggi. In un’ora hai una bozza che rispecchia la realtà.
Definisci il trigger prima dei passaggi
Ogni SOP deve rispondere a una domanda prima di qualsiasi altra: quando si usa questa procedura?
Senza un trigger esplicito, la decisione di applicare la procedura ricade ogni volta sulla persona che esegue — che spesso preferisce chiedere piuttosto che sbagliare. Il trigger elimina quella decisione a monte.
Un trigger efficace è un evento osservabile: “quando il contratto è firmato”, “quando un cliente apre un ticket di priorità alta”, “ogni lunedì entro le 9”. Non uno stato vago come “quando è necessario” o “in caso di problemi”.
Scrivi i passaggi come se il lettore fosse alla sua prima settimana
Non perché il tuo team sia inesperto. Ma perché una procedura che funziona anche per qualcuno di nuovo è una procedura che non lascia nulla alla memoria o all’interpretazione.
Ogni passaggio deve contenere: cosa fare, con quale strumento o risorsa, e — se c’è una decisione da prendere — quale criterio usare per prenderla. Se un passaggio richiede una spiegazione orale per essere capito, va riscritto.
Indica l’output atteso, non solo i passaggi
La fine di un processo non è “completare l’ultimo passaggio”. È raggiungere un risultato verificabile. Definire quell’output — e renderlo misurabile — dà a chi esegue un modo per sapere se ha fatto bene, senza doverlo chiedere.
“Invia l’email di conferma” è un passaggio. “Il cliente ha ricevuto conferma scritta entro 24 ore dalla richiesta” è un output. Il secondo è più utile — dice anche quando e a quale standard.
Il passaggio che quasi nessuno fa: testare prima di distribuire
Una SOP non è finita quando hai scritto l’ultimo passaggio. È finita quando qualcuno che non l’ha scritta riesce a seguirla senza farti domande.
Prima di renderla operativa, falla seguire a una persona del team che non ha partecipato alla scrittura. Non spiegarle nulla. Osserva dove si ferma, cosa chiede, dove interpreta.
Ogni punto di blocco è un passaggio da riscrivere — non un problema del lettore. Questo step richiede al massimo trenta minuti e dimezza il numero di domande che riceverai nelle settimane successive.
Se stai cercando la struttura completa — i campi, il formato, un esempio compilato — trovi tutto nell’articolo → Procedura operativa standard: il modello che funziona (e come adattarlo alla tua azienda)
Dove posizionare la SOP perché venga trovata nel momento giusto
Il contenuto può essere perfetto — se la SOP vive nel posto sbagliato, nessuno la cercherà quando ne ha bisogno.
La regola pratica è una sola: la procedura deve essere raggiungibile in massimo due clic dal luogo in cui quella persona lavora ogni giorno.
Se il tuo team lavora su un tool di project management, la SOP dovrebbe diventare un template di progetto o di task — già configurato, pronto da avviare. Se usate un wiki, il link alla procedura deve stare nella home page dell’area a cui appartiene, non in tre livelli di sottocartelle.
L’articolo dedicato all’integrazione tra procedure e strumenti di lavoro entra nel dettaglio di come configurare questo sistema in modo che funzioni senza dipendere dalla memoria di nessuno.
L’azione da fare questa settimana
Prendi l’ultima procedura che hai spiegato a voce a qualcuno del team. Quella cosa che hai raccontato per la terza o quarta volta.
Siediti con quella persona. Falle eseguire l’attività mentre la osservi. Trascrivi i passaggi nell’ordine in cui li fa — non nell’ordine in cui pensi che dovrebbe farli.
Aggiungi il trigger. Aggiungi l’output atteso. Poi mandagliela e chiedi: “Riesci a seguirla senza che ti spieghi nulla?”
Quello che emerge da quella domanda è la SOP reale — non quella che pensavi di aver scritto.




