Martina gestisce il commerciale di un’azienda di 18 persone. Ogni volta che entra una nuova risorsa nel team, passa tre settimane a spiegare come funzionano le cose: come si carica un cliente in CRM, come si prepara un’offerta, cosa si dice nella prima call.
Non perché le piaccia. Perché non c’è scritto da nessuna parte.
Ha provato a mettere le istruzioni in un Google Doc, ma il documento è diventato lungo due pagine e nessuno lo apre. Ha provato a fare una call registrata, ma poi non si trovava più il link.
Il problema non è la pigrizia del team. Il problema è che Martina non ha mai usato una struttura pensata per questo — e stava cercando di risolvere un problema organizzativo con strumenti improvvisati.
Una S.O.P. — Standard Operating Procedure, procedura operativa standard — è lo strumento giusto per questo problema. Non è un documento burocratico. È un accordo scritto su come un’attività viene eseguita, da chi, in quale ordine, e con quale risultato atteso.
In questo articolo trovi la struttura base, un modello compilabile e le istruzioni per adattarlo alla realtà di un’azienda tra 15 e 50 persone — dove il tempo per costruire procedure è poco, e dove le procedure devono funzionare davvero, non solo esistere.
Cosa contiene una procedura operativa standard (S.O.P.)
Una S.O.P. efficace non è né un manuale operativo né una lista di buone intenzioni. È un documento operativo con una struttura precisa, pensata per ridurre le decisioni da prendere ogni volta che quell’attività viene eseguita.
I campi che non possono mancare:
- Titolo — il nome dell’attività, specifico abbastanza da non lasciare dubbi su cosa copre
- Chi lo esegue — il ruolo responsabile, non il nome della persona
- Trigger — l’evento che fa partire il processo
- Passaggi — le azioni in ordine numerato, una per riga
- Output atteso — come sai che l’attività è stata completata correttamente
- Responsabile di revisione — chi aggiorna il documento e con quale frequenza
Ogni campo ha una funzione specifica. Il trigger elimina l’ambiguità su quando agire. L’output atteso elimina l’ambiguità su quando smettere. Il responsabile di revisione impedisce che la procedura diventi obsoleta senza che nessuno se ne accorga.
Questa struttura fa parte del metodo completo descritto in → Come creare processi aziendali che il team usa davvero. Se non l’hai letto, è il punto di partenza logico prima di scrivere la prima SOP.
Modello di procedura operativa standard (S.O.P.)
Ecco la struttura che uso con le aziende con cui lavoro. Non è l’unica possibile — ma è quella che, nella pratica, genera le procedure più usate:
| Campo | Cosa inserire | Esempio concreto |
| Titolo | Nome dell’attività, chiaro e specifico | Onboarding nuovo cliente — fase contratto |
| Chi lo esegue | Il ruolo, non la persona | Responsabile commerciale |
| Trigger | Cosa fa scattare il processo | Contratto firmato e pervenuto via email |
| Passaggi | Azioni in ordine numerato, una per riga | 1. Creare cartella cliente su Drive… |
| Output atteso | Come sai che è fatto bene | Cliente ha ricevuto email + accesso + data kickoff |
| Responsabile revisione | Chi aggiorna il processo e quando | Operations manager — ogni 6 mesi |
Ogni campo deve essere compilabile in meno di cinque minuti. Se ci vuole di più, il processo è troppo grande e va spezzato in sotto-processi.
Un esempio concreto: S.O.P. per l’onboarding di un nuovo cliente
Tradurre la struttura in un esempio reale aiuta più di qualsiasi spiegazione teorica. Ecco come appare una S.O.P. compilata per un’attività comune in molte PMI di servizi:
| Titolo Onboarding nuovo cliente — dalla firma del contratto al kickoff |
| Chi lo esegue Responsabile operations (o project manager assegnato all’account) |
| Trigger Il contratto firmato è pervenuto via email o caricato in [nome piattaforma] |
| Passaggi 1. Creare cartella cliente su Drive seguendo la struttura standard (vedi template cartella) 2. Aprire scheda cliente in CRM e compilare tutti i campi obbligatori 3. Inviare email di benvenuto entro 24 ore (usa template email #3) 4. Creare progetto in [tool di PM] da template ‘Nuovo cliente’ 5. Inviare invito al kickoff — data entro 5 giorni lavorativi dalla firma 6. Condividere con il cliente il documento di briefing da compilare prima del kickoff |
| Output atteso Entro 48 ore dalla firma: cliente ha ricevuto email di benvenuto, ha accesso alla piattaforma e ha la data del kickoff confermata in calendario. |
| Responsabile revisione Operations manager — revisione ogni 6 mesi o dopo ogni onboarding problematico |
Nota il livello di specificità: ogni passaggio indica cosa fare, con quale strumento, e in quale tempo. Non c’è spazio per l’interpretazione — che è esattamente il punto.
Tre errori che rendono una S.O.P. inutile
1. Scrivere i passaggi senza il trigger
Una S.O.P. senza trigger è una lista di istruzioni che nessuno sa quando applicare. Il trigger è la condizione che fa partire tutto: senza di esso, il processo dipende sempre da una decisione umana — che è esattamente quello che stai cercando di eliminare.
2. Usare nomi di persone invece di ruoli
“Manda a Giulia” diventa un problema il giorno in cui Giulia non c’è, o cambia ruolo, o lascia l’azienda. Una SOP robusta non dipende dalle persone — dipende dai ruoli. Questo è il modo in cui un processo diventa resiliente al turnover.
3. Non indicare chi aggiorna il documento
Una S.O.P. senza revisione diventa obsoleta in pochi mesi. E una procedura obsoleta è peggio di nessuna procedura, perché crea confusione su cosa seguire. Ogni SOP deve avere un responsabile di revisione con una cadenza definita.
Stai creando processi… o li stai solo tenendo in testa?
Scarica la guida gratuita: Come creare procedure che funzionano davvero
Una guida discorsiva e pratica che ti accompagna passo passo nella creazione delle tue prime S.O.P., con esempi reali e i casi più comuni che emergono nel lavoro con le aziende.
Dove mettere le S.O.P. perché vengano usate
Il formato del documento conta meno di dove vive. Una S.O.P. in un file Word dentro una cartella Drive con quattro livelli di sottocartelle non verrà aperta. Una S.O.P. trasformata in template nel tool di project management del team viene eseguita ogni volta, automaticamente.
Qualche indicazione pratica per le PMI:
- Se il team usa ClickUp, Asana o Monday: crea un template di progetto o di task con i passaggi già configurati come subtask. Il processo parte in automatico, non richiede di aprire nessun documento.
- Se preferite un wiki centralizzato (Notion, Confluence, Google Sites): organizza le SOP per area funzionale, non per nome del processo. Chi cerca trova più in fretta.
- Se parti da zero e vuoi la soluzione più semplice: un Google Doc per SOP va benissimo, a patto che il link sia accessibile direttamente dalla bacheca principale del team.
Lo strumento non fa la differenza — la posizione sì. Il processo deve essere raggiungibile in massimo due clic dal luogo in cui si lavora ogni giorno.
Se vuoi approfondire l’integrazione tra procedure e strumenti digitali, l’articolo dedicato a ClickUp e alla gestione operativa entra nel dettaglio tecnico di come configurare i template.
Da dove partire
Scegli un’attività che esegui o che fai eseguire almeno due volte a settimana. Prendi la struttura che hai visto sopra — titolo, chi, trigger, passaggi, output — e compilala per quella sola attività.
Non partire da zero con la scrittura: osserva o registra come viene fatta oggi. Poi trascrivila in passaggi numerati. Poi testala con chi la esegue.
Quando quel processo funziona senza spiegazioni, ne scegli un altro.
Le aziende che funzionano senza che l’imprenditore sia nel mezzo di tutto non hanno più procedure delle altre — le hanno scritte meglio, e le hanno messe nel posto giusto.
Non sai da quale processo partire nella tua azienda?
La mappa delle decisioni — quiz gratuito di autodiagnosi in 10 domande.
Ti restituisce uno dei tre profili più comuni negli imprenditori in questa fase, con indicazioni su dove intervenire per primo.
