# Cos'è uno statement of work: guida pratica prima di firmare URL: https://legalysis.co/it/journal/cos-e-uno-statement-of-work Type: blog Locale: it Published: 2026-10-19 Updated: 2026-10-22 --- > Lo statement of work definisce cosa si consegna, entro quando e a quale prezzo. Ecco le clausole che decidono le controversie e cosa verificare prima di firmare. Uno statement of work, abbreviato SOW, è la parte di un contratto di servizi che stabilisce con precisione cosa verrà consegnato, entro quando, da chi e a quale prezzo. Se si chiede cos'è uno statement of work, la risposta più utile è questa: è il documento di progetto che sta sotto le clausole legali. Nella pratica è lì che si vincono o si perdono la maggior parte delle controversie del tipo «non era quello che avevamo concordato». ## Cosa contiene davvero uno statement of work? Uno SOW descrive un singolo lavoro. Non prova a coprire l'intera relazione tra due aziende. Quelli scritti bene contengono quasi sempre gli stessi blocchi fondamentali. - **Ambito del lavoro:** cosa farà il fornitore, con verbi semplici, e cosa non farà. - **Deliverable:** i risultati concreti, come un database migrato, una brand guide o 40 ore di supporto. - **Tempistiche e milestone:** date o durate, legate ai deliverable e non a un vago «entro fine trimestre». - **Compensi e piano di pagamento:** prezzo fisso, tempo e materiali oppure una combinazione, con i momenti che fanno scattare la fattura. - **Criteri di accettazione:** come il cliente stabilisce che un deliverable è completato. - **Ruoli e dipendenze:** chi fornisce accessi, dati, approvazioni o ambienti di test, e entro quando. - **Procedura di modifica:** come si cambiano ambito, prezzo o date una volta iniziato il lavoro. In sostanza lo SOW trasforma un'idea nata da una stretta di mano in qualcosa che una terza persona può leggere e verificare. Quella terza persona è spesso un giudice, un revisore o un collega nuovo che eredita il progetto. ![Mani che indicano sezioni con linguette su un contratto stampato](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/legalysis/2026-10/856bc2-i1.webp) ## In cosa lo SOW si distingue da MSA, proposta e ordine d'acquisto? La confusione nasce da documenti che si somigliano e che, in una trattativa, compaiono quasi sempre insieme. Un master services agreement (MSA) contiene le clausole legali generali: responsabilità, proprietà intellettuale, riservatezza, protezione dei dati, risoluzione e legge applicabile. Si firma una volta sola. Ogni SOW si aggancia poi all'MSA e copre un singolo progetto. Un solo MSA può reggere una dozzina di SOW nell'arco di diversi anni. Una proposta è un documento commerciale. Descrive ciò che il fornitore spera di fare e perché sceglierlo. Di solito non è vincolante, e spesso viene riutilizzata come prima bozza dello SOW: è lì che iniziano i guai, perché il linguaggio di marketing finisce dentro un contratto. Un ordine d'acquisto è un'autorizzazione al pagamento. Indica un prezzo e una quantità, raramente un ambito. Affidarsi solo a un ordine d'acquisto per un progetto di servizi lascia il lavoro indefinito. Per un incarico unico, un solo accordo che include lo SOW come allegato può andare benissimo. La separazione tra MSA e SOW diventa utile quando si acquista più volte dallo stesso fornitore. ## Quale clausola prevale se MSA e SOW non coincidono? È la domanda che quasi tutti saltano, ed è quella che costa di più. Gli accordi scritti con cura seguono di solito uno schema semplice. L'MSA governa le clausole legali. Lo SOW governa ambito, tempistiche e compensi. Una clausola di ordine di precedenza lo dice in una o due frasi e indica quale documento prevale in caso di conflitto. Senza quella clausola ci si affida a come un giudice legge i documenti nel loro insieme. Secondo il diritto inglese, per esempio, i documenti contrattuali sono generalmente letti come un unico accordo, quindi un'incoerenza non si annulla da sola. Genera una discussione, e le discussioni si fatturano. Ecco il tipo di formulazione da cercare, scritta come esempio di redazione e non come consiglio per la Sua giurisdizione: `§ In caso di conflitto, le clausole dell'MSA prevalgono sullo SOW, salvo che lo SOW prevalga per quanto riguarda ambito, deliverable, tempistiche e compensi del progetto che descrive.` Attenzione a una trappola. Uno SOW che sovrascrive in silenzio il limite di responsabilità o la clausola sulla titolarità della proprietà intellettuale «solo per questo progetto» è legittimo quando entrambe le parti lo vogliono. Diventa un problema quando nessuno se ne è accorto. Chi firma lo SOW deve leggerlo come un contratto, non come un piano di progetto. ![Muro di post-it disposti come una timeline di milestone di progetto](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/legalysis/2026-10/50c55e-i2.webp) ## Cosa rende solido il linguaggio sull'ambito? L'ambito è il punto in cui gli SOW falliscono. Un ambito vago non è neutro: favorisce chi è più disposto a discutere in seguito, cioè di solito la parte con più potere contrattuale. Tre abitudini aiutano a tenerlo solido. Primo, scrivere le esclusioni. Un elenco di ciò che resta fuori ambito è spesso più utile dell'elenco di ciò che è dentro. «Non include l'integrazione con il vecchio sistema di fatturazione del cliente» chiude una conversazione che altrimenti richiederebbe tre riunioni. Secondo, legare i deliverable a sostantivi, non ad aggettivi. «Un sito web reattivo» è discutibile. «Otto template, testati sulle due versioni più recenti di quattro browser indicati per nome» è verificabile. Terzo, dichiarare le ipotesi. Se la tempistica dipende dal fatto che il cliente restituisca i feedback entro cinque giorni lavorativi, va scritto, insieme a ciò che succede al calendario se non accade. Le richieste di ritardo sono molto più facili da gestire quando la dipendenza era messa per iscritto. Eviti la tentazione di copiare un modello e riempire gli spazi vuoti. Un modello mostra i titoli, ma non può dirle quali ipotesi sono specifiche del suo progetto. ## Come vanno scritti accettazione e richieste di modifica? I criteri di accettazione rispondono a una domanda: quando un deliverable è abbastanza finito da essere pagato? «Alta qualità» e «soddisfacente per il cliente» non rispondono. Un criterio verificabile sì. Per una migrazione di dati, per esempio, potrebbe essere «tutti i record trasferiti e un report di riconciliazione che non mostra differenze non spiegate». Aggiunga un meccanismo di accettazione tacita. Una prassi comune prevede che un deliverable si consideri accettato se il cliente non invia per iscritto le contestazioni entro un termine definito, spesso intorno ai dieci giorni lavorativi. Senza questo meccanismo, il cliente può bloccare l'approvazione e, con essa, la fattura finale, a tempo indeterminato. Se è lei il cliente, chieda un periodo chiaro perché il fornitore corregga ciò che è stato segnalato: così i tempi sono equi per entrambe le parti. Le richieste di modifica meritano la stessa cura. Lo scope creep raramente arriva come una grande richiesta. Arriva come dieci piccole richieste che sembrano ragionevoli una per una. Una procedura di modifica di un paragrafo risolve il problema: ogni cambiamento di ambito, prezzo o date richiede un change order scritto, firmato da entrambe le parti prima che il lavoro inizi. Molti fornitori perdono margine sui progetti proprio perché lo SOW lasciava spazio a un accordo verbale. ![Stretta di mano sopra una cartella firmata in una sala riunioni](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/legalysis/2026-10/dd4a94-i3.webp) ## Prezzo fisso o tempo e materiali: quale si adatta a uno SOW? La sezione sui compensi cambia il modo in cui si ripartisce il rischio, quindi conviene scegliere con deliberazione. Il prezzo fisso scarica il rischio di consegna sul fornitore. Funziona quando l'ambito è ben chiaro e difficilmente cambierà. Funziona male quando l'ambito è sfumato, perché il fornitore inserirà un margine di sicurezza nel prezzo oppure contesterà ogni variazione. Il tempo e materiali scarica il rischio di impegno sul cliente. Si adatta al lavoro esplorativo, ma richiede un tetto massimo, altrimenti il budget è un'opinione. Un ibrido, con un prezzo fisso per ogni milestone, è spesso il compromesso più onesto. Ogni milestone ha il proprio deliverable, il proprio test di accettazione e la propria fattura, il che rende lo SOW facile da verificare e facile da interrompere se il progetto va male. ## Dove si sbaglia quando lo si firma? Dopo aver letto molti di questi documenti, gli stessi errori ricorrono. - Firmare lo SOW prima che esista l'MSA, così il progetto procede senza alcuna clausola su responsabilità o proprietà intellettuale. - Lasciare le date come «indicative» senza alcuna conseguenza se non vengono rispettate. - Descrivere i deliverable per attività («fornire supporto») anziché per risultato («rispondere ai ticket prioritari entro quattro ore lavorative»). - Dimenticare la protezione dei dati quando il fornitore tratterà dati personali. Nell'UE e nel Regno Unito questo di solito significa un accordo sul trattamento dei dati affiancato allo SOW, e i dettagli giusti dipendono dalle giurisdizioni coinvolte. - Non aggiornare lo SOW dopo una modifica verbale, per poi affidarsi alla memoria un anno dopo. Non è un rischio teorico: è ciò che i giuristi vedono regolarmente. Nessuno di questi errori richiede un talento legale straordinario per essere evitato. Serve qualcuno che legga il documento con calma prima di firmarlo. ## Quali strumenti aiutano a redigere, firmare e rivedere uno SOW? Gli strumenti non scrivono al posto suo un buon ambito, ma possono eliminare il lavoro ripetitivo che lo circonda. Per redigere a partire da blocchi riutilizzabili, con approvazioni e firma elettronica nello stesso flusso, una piattaforma documentale è pratica. Per la sola firma, con traccia di audit e ampia accettazione tra le controparti, un servizio di firma elettronica dedicato è sufficiente. Per i team che gestiscono molti SOW all'anno e hanno bisogno di collegarli a un MSA, una piattaforma di gestione del ciclo di vita dei contratti mantiene il legame tra clausole master e ogni documento di progetto. Per una prima verifica dei rischi nelle clausole dentro Word, un componente aggiuntivo di revisione basato sull'IA può segnalare esclusioni mancanti o una clausola di responsabilità in conflitto prima che una persona la legga. Nessuno di questi strumenti sostituisce un avvocato quando in gioco ci sono interessi rilevanti. Il software serve a individuare i problemi di routine; ciò che è insolito, rilevante o transfrontaliero va sottoposto al proprio consulente legale. ## Cosa fare prima di firmare il prossimo SOW Tre azioni coprono la maggior parte del rischio. - Verificare che esista un MSA e che lo SOW indichi quale documento prevale sulle clausole legali, rispetto ad ambito e compensi. - Riscrivere ogni deliverable in modo che una persona estranea al progetto possa capire, con un sì o un no, se è stato consegnato, e aggiungere esclusioni e ipotesi. - Confermare la finestra di accettazione, il periodo di rimedio e la regola della modifica scritta, poi allegare ogni variazione allo SOW stesso. Se il progetto è grande, coinvolge dati personali o attraversa confini, lo faccia leggere al consulente legale. La risposta dipenderà dalla legge applicabile, e una revisione breve costa molto meno di una controversia. ## FAQ ### Cos'è uno statement of work in parole semplici? È il documento che descrive un singolo progetto di servizi: cosa viene fatto, cosa viene consegnato, entro quando, da chi e a quale prezzo. Sta sotto le clausole legali generali del contratto. ### Qual è la differenza tra uno SOW e un MSA? L'MSA contiene le clausole legali generali e si firma una volta sola. Lo SOW descrive un progetto specifico e si collega all'MSA. Un solo MSA può regolare molti SOW nel tempo. ### Quale documento prevale se MSA e SOW sono in conflitto? Dipende da cosa dice il contratto. Di solito l'MSA prevale sulle clausole legali e lo SOW su ambito, tempistiche e compensi. Senza una clausola di ordine di precedenza, il conflitto si risolve con un'interpretazione, spesso costosa. ### Uno SOW può valere anche senza un MSA? Dipende dal contesto e dalla legge applicabile. In ogni caso, senza un MSA mancano le clausole generali su responsabilità, proprietà intellettuale e riservatezza. Per questo conviene definire prima l'MSA e verificare i dettagli con un consulente. ### Prezzo fisso o tempo e materiali: quale scegliere in uno SOW? Il prezzo fisso funziona con un ambito ben definito. Il tempo e materiali è adatto al lavoro esplorativo, ma va sempre accompagnato da un tetto massimo. Per molti progetti un prezzo fisso per milestone è il compromesso più chiaro. ### Quando serve un accordo sul trattamento dei dati insieme allo SOW? Quando il fornitore tratta dati personali. Nell'UE e nel Regno Unito di solito è necessario, ma i dettagli dipendono dalle giurisdizioni coinvolte e conviene farli verificare.