Quando un’agenzia affida lo sviluppo di un sito web a un partner esterno, la domanda su chi possiede il codice prodotto non è teorica: è una questione che può determinare se l’agenzia può consegnare il sito al cliente, se può portare il progetto da un altro sviluppatore, e se può rivendicare il lavoro come proprio portfolio. In Italia, la risposta non è ovvia e dipende quasi interamente da cosa c’è scritto nel contratto, o da cosa non c’è scritto.

Noi di Blurr strutturiamo ogni collaborazione con NDA e clausole di proprietà intellettuale esplicite fin dal primo progetto. L’abbiamo imparato osservando cosa succede quando questi accordi mancano, e quello che succede non è mai neutro.

Cosa dice la legge italiana sulla proprietà intellettuale del software

In Italia il software è protetto dalla Legge sul Diritto d’Autore (L. 633/1941, modificata dal D.Lgs. 518/1992 per recepire la Direttiva CE 91/250). Il principio generale è che i diritti patrimoniali sul software appartengono all’autore che lo ha creato, salvo eccezioni specifiche.

L’eccezione più rilevante per le agenzie: se lo sviluppatore è un dipendente, il software creato nell’esercizio delle sue mansioni appartiene al datore di lavoro. Se invece lo sviluppatore è un libero professionista, una società esterna o un partner white label, i diritti restano in capo a chi ha scritto il codice, a meno che il contratto non dica esplicitamente il contrario.

Questo significa che in assenza di una clausola contrattuale specifica sulla cessione dei diritti, il codice sviluppato da un partner esterno appartiene formalmente al partner, non all’agenzia che ha commissionato il lavoro e pagato la fattura.

È una situazione che crea problemi reali. Un’agenzia di Verona che seguivamo ci ha raccontato di aver perso l’accesso completo al codice di un sito ecommerce sviluppato da un freelance con cui avevano collaborato per due anni. Il rapporto si era concluso male, il freelance non rispondeva più, e il codice era su un repository privato di sua proprietà. Il cliente chiedeva modifiche urgenti, l’agenzia non aveva modo di intervenire senza ricominciare da zero. Il contratto originale non menzionava la proprietà del codice. Ci sono voluti tre mesi e un accordo economico aggiuntivo per riottenere l’accesso ai file.

I tre scenari che le agenzie devono gestire

Scenario 1: l’agenzia sviluppa internamente per il cliente finale. Il codice è prodotto da dipendenti o collaboratori dell’agenzia stessa. In questo caso la proprietà dipende dal tipo di rapporto lavorativo. Con dipendenti a tempo indeterminato o determinato, il codice appartiene all’agenzia per legge. Con collaboratori autonomi (partita IVA, collaborazione occasionale), serve una clausola contrattuale esplicita di cessione dei diritti.

Scenario 2: l’agenzia usa un partner white label come Blurr. Il codice è sviluppato da un soggetto terzo. Senza clausole specifiche, i diritti restano al partner. La soluzione corretta è una clausola nel contratto di collaborazione che preveda la cessione automatica dei diritti patrimoniali sull’opera all’agenzia committente al momento del pagamento della fattura. Questo è lo standard che applichiamo in tutti i nostri accordi con le agenzie partner.

Scenario 3: l’agenzia cede il sito al cliente finale. Indipendentemente da chi ha sviluppato il codice, l’agenzia deve avere i diritti per poterli cedere al cliente. Se il contratto con il cliente include la consegna del codice sorgente come proprietà del cliente, l’agenzia deve assicurarsi di avere quei diritti prima di firmare. Molte agenzie promettono “il sito è tuo” senza aver regolato la questione a monte con lo sviluppatore.

Cosa deve contenere il contratto con il partner esterno

Una clausola di proprietà intellettuale efficace in un contratto di sviluppo web deve coprire tre aspetti distinti.

Cessione dei diritti patrimoniali. Il partner cede all’agenzia tutti i diritti patrimoniali sul codice prodotto nell’ambito della collaborazione, inclusi i diritti di riproduzione, distribuzione, modifica e sublicenza. La cessione diventa efficace al momento del pagamento integrale del corrispettivo.

Esclusione del portfolio. Il partner rinuncia al diritto di citare il progetto come proprio lavoro nel proprio portfolio, mostrare screenshot o descrizioni del sito su propri canali, o rivelare l’esistenza della collaborazione a terzi. Questo è il nucleo del white label: non solo il codice è dell’agenzia, ma anche la paternità dell’opera.

Restituzione degli accessi. Alla conclusione del progetto o della collaborazione, il partner è tenuto a consegnare tutti gli accessi (repository, credenziali hosting, pannelli di amministrazione) e a rimuovere eventuali copie del codice dai propri sistemi.

Senza questi tre elementi, anche un NDA ben scritto lascia zone grigie che possono diventare costose da gestire.

Come documentiamo nell’articolo sul NDA con un partner white label, la riservatezza e la proprietà intellettuale sono due aspetti distinti che richiedono clausole separate nello stesso contratto.

La questione dei temi e plugin di terze parti

Un aspetto che spesso crea confusione: il codice sviluppato custom appartiene all’agenzia (con le clausole corrette), ma i temi commerciali, i plugin premium e i framework di terze parti hanno licenze proprie che non possono essere cedute.

Bricks Builder, che usiamo come page builder standard su tutti i nostri progetti, ha una licenza per sito che appartiene a chi l’ha acquistata. WooCommerce è GPL e può essere liberamente distribuito. I plugin premium hanno licenze diverse: alcuni sono per sito, altri per sviluppatore, altri ancora per agenzia.

Quando si consegna un sito al cliente finale, è importante chiarire nel contratto quali componenti sono licenze dell’agenzia (che potrebbero non essere trasferibili) e quali sono licenze che il cliente deve acquistare autonomamente. Questo vale sia per i plugin che per eventuali font commerciali, librerie di icone o stock photo incluse nel design. Come spieghiamo nell’articolo sul contratto di sviluppo web, le clausole sulle licenze di terze parti sono tra quelle più spesso dimenticate nei contratti standard delle agenzie.

Cosa fare se non c’è un contratto scritto

La situazione più comune nelle collaborazioni informali è l’assenza di un contratto scritto. Si lavora sulla fiducia, si comunica via WhatsApp, si fattura e si consegna. Finché il rapporto funziona nessuno fa domande. Quando si rompe, le questioni di proprietà emergono nel momento peggiore.

In assenza di contratto, la legge italiana tende a proteggere l’autore materiale dell’opera, cioè chi ha scritto il codice. L’agenzia che ha commissionato e pagato il lavoro ha ragioni economiche per rivendicare la proprietà, ma non ha uno strumento legale diretto. La via giudiziale è lenta e costosa, e nel frattempo il sito del cliente è bloccato.

La soluzione pratica per le collaborazioni già avviate senza contratto è regolarizzare retroattivamente con un accordo scritto che entrambe le parti firmano. Non è la soluzione ideale, ma è molto meglio di niente. Per le collaborazioni nuove, il contratto va firmato prima di iniziare qualsiasi lavoro, non dopo.

Se stai strutturando il tuo processo di collaborazione con partner tecnici esterni e vuoi assicurarti che la proprietà intellettuale sia gestita correttamente fin dall’inizio, blurr.it/contatti/ è il punto di partenza. Blurr, studio WordPress white label con sede a Calliano (Trento), include clausole di cessione dei diritti e NDA strutturato in ogni accordo di collaborazione.

Lo SLA (Service Level Agreement) è uno degli strumenti contrattuali più sottovalutati nelle agenzie web italiane. La maggior parte delle agenzie non ce l’ha, alcune lo hanno ma non lo comunicano, pochissime lo usano come leva commerciale. Eppure definire per iscritto i tempi di risposta, i livelli di uptime garantiti e le procedure di escalation non è solo una protezione legale: è esattamente quello che i clienti più strutturati cercano quando scelgono un fornitore web, e quello che separa un’agenzia professionale da una che “fa i siti”.

Noi di Blurr includiamo uno SLA strutturato in ogni accordo di manutenzione con le agenzie partner. Lo abbiamo costruito nel tempo, affinandolo progetto dopo progetto, e lo usiamo anche come riferimento quando aiutiamo le agenzie a strutturare i loro contratti verso i clienti finali. Quello che descriviamo in questo articolo viene dalla pratica, non dalla teoria.

Cosa è uno SLA nel contesto dello sviluppo web

Nel contesto web, uno SLA definisce le condizioni operative del rapporto tra agenzia e cliente dopo la consegna del sito. Non riguarda il progetto di sviluppo in sé, quello è regolato dal contratto di sviluppo, ma la fase successiva: come vengono gestite le richieste di assistenza, in quanto tempo, con quali priorità e con quali conseguenze in caso di mancato rispetto.

I componenti principali di uno SLA per un’agenzia web sono quattro. I tempi di risposta per le richieste di assistenza, differenziati per urgenza. I livelli di disponibilità garantiti per il sito, tipicamente espressi come percentuale di uptime mensile. Le procedure di escalation per i problemi critici. Le esclusioni, ovvero cosa non è coperto dallo SLA.

Senza questi elementi scritti, il cliente interpreta “assistenza inclusa” come “fate quello che voglio quando voglio”. L’agenzia interpreta la stessa frase come “rispondiamo quando possiamo”. Questa ambiguità è la radice della maggior parte delle controversie post-consegna che vediamo nelle agenzie con cui collaboriamo.

I tempi di risposta: come differenziarli per urgenza

Il campo dei tempi di risposta è quello dove lo SLA ha l’impatto pratico più immediato. Non tutti i problemi hanno la stessa urgenza, e trattarli tutti allo stesso modo porta a due risultati ugualmente negativi: o si risponde troppo lentamente alle emergenze reali, o si brucia capacità produttiva su richieste non urgenti.

La struttura che funziona meglio nella pratica per le agenzie web divide le richieste in tre livelli:

Critico: il sito è completamente down, il checkout ecommerce non funziona, c’è una violazione di sicurezza attiva. Tempo di risposta garantito: entro 2-4 ore, in orario lavorativo esteso. Alcune agenzie garantiscono risposta anche fuori orario per i clienti con contratti premium.

Urgente: una funzionalità importante non funziona correttamente (form che non invia, area riservata inaccessibile, errori visibili agli utenti), ma il sito è accessibile. Tempo di risposta: entro 8 ore lavorative.

Standard: richieste di modifica, aggiornamenti pianificati, domande tecniche, piccoli fix estetici. Tempo di risposta: entro 2-3 giorni lavorativi.

Qualche anno fa un’agenzia di Firenze che seguivamo ci ha raccontato di aver perso un cliente ecommerce importante non per la qualità del lavoro, ma per una crisi gestita male: il sito è andato down un venerdì pomeriggio, il cliente non riusciva a contattare nessuno, e il lunedì mattina aveva già firmato con un’altra agenzia. Non c’era nessun numero di emergenza nel contratto, nessuna procedura definita, nessun impegno scritto sui tempi di risposta. Il cliente non era insoddisfatto del sito, era insoddisfatto dell’assenza di un processo. Uno SLA scritto avrebbe reso esplicito cosa ci si poteva aspettare, e probabilmente avrebbe salvato il rapporto.

L’uptime: come garantirlo senza esporsi a rischi

La percentuale di uptime è il parametro più comune negli SLA, e anche quello dove le agenzie si espongono di più se non lo gestiscono con attenzione.

Un uptime del 99,9% significa circa 8,7 ore di downtime tollerato all’anno. Un uptime del 99,5% significa circa 43 ore. Questi numeri sembrano astratti finché non si deve applicare una penale per averli mancati.

Il punto critico per le agenzie è che l’uptime del sito dipende dall’hosting, non dall’agenzia. Un’agenzia che garantisce il 99,9% di uptime senza avere controllo diretto sull’infrastruttura si sta esponendo a rischi che non può gestire. La soluzione corretta è garantire l’uptime indirettamente: scegliendo un hosting con SLA certificato, monitorando il sito con strumenti automatici e includendo nello SLA dell’agenzia le procedure di intervento in caso di downtime, non la garanzia assoluta di disponibilità.

Noi di Blurr per le agenzie partner usiamo un sistema di monitoraggio che segnala immediatamente qualsiasi anomalia di uptime. Questa è la base per poter fare promesse realistiche ai clienti finali senza esporsi a penali impossibili da gestire. Il tema del monitoraggio è approfondito nell’articolo su sicurezza e monitoraggio del sito web.

Come comunicare lo SLA al cliente senza spaventarlo

Il problema comunicativo degli SLA nelle agenzie web è che suonano burocratici. Il cliente legge “Service Level Agreement” e pensa a contratti enterprise con clausole incomprensibili. Il risultato è che molte agenzie evitano di formalizzarli per non complicare la conversazione commerciale.

La soluzione è riformulare lo SLA come garanzia di servizio, non come documento legale. Invece di presentare una tabella con percentuali di uptime e tempi di risposta in gergo tecnico, si presenta come: “Se il tuo sito va giù, ti chiamiamo noi prima che te ne accorga. Se hai un problema urgente, hai un numero diretto e una risposta entro quattro ore. Se hai bisogno di modifiche, le gestiamo entro tre giorni lavorativi.”

Questa è esattamente la stessa cosa di uno SLA formale, comunicata nel linguaggio del cliente. Il documento legale esiste e va firmato, ma la conversazione commerciale usa il linguaggio del beneficio, non della procedura.

Le agenzie che adottano questo approccio trovano che lo SLA diventa un argomento di vendita, non un ostacolo. Come spieghiamo nell’articolo su come trattenere i clienti con piani di manutenzione, i clienti che firmano un piano di manutenzione strutturato con SLA hanno un tasso di rinnovo molto più alto di quelli con accordi informali.

SLA verso il cliente e SLA con il partner tecnico: due livelli

Per le agenzie che usano un partner tecnico white label per lo sviluppo, come Blurr, lo SLA ha due livelli distinti ma collegati.

Il primo livello è lo SLA che l’agenzia firma con il cliente finale. Il secondo è l’accordo operativo che l’agenzia ha con il partner tecnico, che deve essere allineato o più stringente del primo. Se l’agenzia garantisce al cliente una risposta entro quattro ore per le emergenze, il partner tecnico deve essere in grado di rispondere almeno entro due ore.

Questo allineamento è spesso il punto debole nelle collaborazioni white label non strutturate. Un’agenzia firma uno SLA ambizioso con il cliente, poi scopre che il freelance esterno risponde “quando può”. La soluzione è definire esplicitamente i tempi di risposta e gli SLA operativi anche nell’accordo con il partner, prima di firmare qualsiasi cosa con il cliente finale. Come documentiamo nell’articolo su come scegliere un partner di sviluppo WordPress white label, i tempi di risposta garantiti sono uno dei sette criteri fondamentali per valutare un partner.

Se vuoi strutturare i tuoi contratti di manutenzione con uno SLA professionale e stai cercando un partner tecnico che rispetti gli stessi standard, blurr.it/contatti/ è il punto di partenza. Blurr, studio WordPress white label con sede a Calliano (Trento), include SLA operativo in ogni accordo con le agenzie partner.

Acquisire un nuovo cliente costa in media cinque volte di più che mantenerne uno esistente. Per una web agency, questo dato si traduce in una conseguenza operativa precisa: il rinnovo del contratto con un cliente già acquisito è il momento commerciale con il miglior rapporto tra sforzo e risultato di tutto il ciclo di vendita. Eppure è quello che le agenzie gestiscono con meno attenzione, spesso lasciandolo accadere per inerzia invece di strutturarlo come un’opportunità consapevole.

Lavorando con oltre 130 agenzie italiane, vediamo due pattern opposti. Le agenzie che crescono in modo stabile hanno quasi sempre una base di clienti che rinnovano e aumentano il proprio valore nel tempo. Le agenzie che faticano a crescere dipendono quasi esclusivamente dall’acquisizione continua di nuovi clienti, che ha costi e rischi molto più alti.

Perché il rinnovo è il momento commerciale più importante

Un cliente che rinnova un contratto di manutenzione o che amplia il proprio progetto web ha già superato le due barriere più difficili del ciclo di vendita: ti conosce e si fida di te. Non deve essere convinto della tua credibilità, non deve superare lo scetticismo iniziale, non deve fare il confronto con altri preventivi. È già nel rapporto e sta valutando se continuare e in che modo.

Questo è il momento in cui la proposta di un servizio aggiuntivo ha le probabilità più alte di essere accettata. Secondo i dati HubSpot sul settore, i clienti esistenti hanno una probabilità di acquisto compresa tra il 60% e il 70% rispetto al 5%-20% dei nuovi prospect. Il rinnovo non è una formalità burocratica: è la conversazione commerciale con il tasso di conversione più alto che un’agenzia possa avere.

Come strutturare il rinnovo come conversazione, non come rinnovo automatico

Il problema del rinnovo gestito per inerzia è che non produce crescita: il cliente rinnova allo stesso prezzo, per gli stessi servizi, senza valutare se il suo progetto web sia ancora adeguato alle sue esigenze attuali. Dopo due anni, le esigenze sono cambiate, il sito ha bisogno di evoluzioni, i competitor hanno fatto investimenti che hanno cambiato il contesto competitivo. Ma nessuno lo ha detto al cliente, e il cliente non sa di avere un problema.

La struttura che funziona è trasformare ogni rinnovo in una revisione. Quattro o sei settimane prima della scadenza del contratto, l’agenzia contatta il cliente con un’analisi dello stato attuale del sito: performance sui Core Web Vitals, posizionamento su keyword strategiche, confronto con i principali competitor, eventuali problemi tecnici rilevati. Non è una presentazione commerciale: è una lettura clinica della situazione che porta il cliente a vedere da solo dove il sito sta perdendo terreno.

Da quella conversazione emergono naturalmente le opportunità di evoluzione: un aggiornamento del design che non tiene più su mobile, una sezione del sito non ottimizzata per le ricerche locali, una pagina prodotto che ha un tasso di abbandono alto. L’agenzia non sta vendendo qualcosa di nuovo: sta rispondendo a un problema che il cliente ha appena riconosciuto come tale.

I servizi da proporre al momento giusto

Il timing della proposta è il fattore che più determina se viene accettata o percepita come una forzatura commerciale. Proporre l’upselling nel momento sbagliato, prima che il cliente abbia visto i risultati del servizio base, è il modo più efficace per ottenere un no.

La SEO tecnica avanzata ha senso proporla quando il sito ha almeno sei mesi di vita, ha già traffico organico misurabile e il cliente ha visto che il sito funziona tecnicamente. Prima di quel momento, il cliente non ha i dati per valutare l’investimento. Dopo, ha sia i dati che la motivazione.

L’ecommerce su un sito aziendale si propone quando il cliente comincia a ricevere richieste di acquisto diretto dai visitatori del sito, o quando entra in un mercato in cui i competitor vendono già online. È un’evoluzione naturale che il cliente spesso non sa di poter fare con chi ha già sviluppato il sito.

Il redesign parziale si propone quando i dati di Analytics mostrano che specifiche sezioni del sito hanno performance scadenti: pagine con alto tasso di abbandono, sezioni non ottimizzate per mobile, landing page con CTR basso dai risultati di ricerca. Non si propone il redesign completo: si propone l’intervento chirurgico su quello che non funziona.

Il piano di manutenzione avanzato si propone quando il cliente ha già un piano base e ha visto il valore concreto nel tempo: aggiornamenti gestiti, problemi risolti rapidamente, sito sempre aggiornato. Il passaggio a un piano più completo con monitoraggio delle performance e report periodico è una proposta che il cliente che ha già sperimentato la manutenzione base valuta con occhi molto diversi da chi non l’ha mai usata.

Il report quadrimestrale come strumento di rinnovo

Uno degli strumenti più efficaci per creare le condizioni giuste per il rinnovo è il report periodico. Non un documento tecnico pieno di dati incomprensibili: un documento che il cliente legge in cinque minuti e capisce chiaramente cosa è stato fatto, qual è lo stato attuale del sito e cosa si potrebbe migliorare.

Blurr fornisce alle agenzie partner un report quadrimestrale brandizzato con i dati dell’agenzia, pronto per essere inoltrato al cliente finale. Non è un documento di Blurr: è un documento dell’agenzia che racconta ai propri clienti l’attività svolta. Questo report crea sistematicamente le condizioni per la conversazione sul rinnovo: il cliente vede il valore ricevuto, vede le opportunità di miglioramento segnalate, e arriva al momento del rinnovo già informato invece di dover essere convinto da zero.

Le agenzie che usano questo report sistematicamente ci segnalano un tasso di rinnovo dei contratti di manutenzione significativamente più alto rispetto a prima. Non perché il report sia uno strumento di vendita: perché elimina il vuoto comunicativo tra consegna e rinnovo che è la causa principale della perdita di clienti. Su blurr.it/servizi/ trovi come strutturiamo il supporto continuativo alle agenzie partner.

Come aumentare il prezzo al rinnovo senza perdere il cliente

Aumentare il prezzo al rinnovo è la conversazione che le agenzie evitano più di tutte. Il rischio percepito è che il cliente se ne vada. La realtà, per le agenzie che la gestiscono con il metodo giusto, è quasi sempre opposta.

Il prezzo si aumenta quando è giustificato da valore aggiunto dimostrabile. Se negli ultimi dodici mesi il sito ha migliorato le performance, il traffico organico è cresciuto, i problemi tecnici sono stati gestiti prima che diventassero visibili al cliente: questi sono argomenti concreti che giustificano un aumento. Non “i nostri costi sono aumentati”: “negli ultimi dodici mesi abbiamo fatto questo e questo, e il valore che hai ricevuto è cresciuto, quindi il prezzo riflette questo.”

L’aumento va comunicato con anticipo, almeno quattro o sei settimane prima della scadenza, con una spiegazione chiara del valore che lo giustifica. Non come un fatto compiuto nella mail di rinnovo automatica: come parte della conversazione di revisione. Un cliente che capisce perché il prezzo aumenta e vede il valore ricevuto lo accetta molto più facilmente di un cliente che lo scopre nella fattura.

Per approfondire come costruire entrate ricorrenti con i piani di manutenzione, leggi come trattenere i clienti con piani di manutenzione. Per capire come strutturare la conversazione contrattuale fin dall’inizio, leggi contratto per lo sviluppo web: le clausole che ogni agenzia dovrebbe avere.