Governance di agenzie e fornitori digitali: ruoli, accessi, SLA e qualità
15 Settembre 2026 · Strategia
In sintesi
Governare agenzie e fornitori significa coordinare chi può modificare sito, campagne, CRM e dati, con quali autorizzazioni e secondo quali standard. Contratti e piattaforme non bastano se account, richieste, approvazioni e passaggi tra specialisti restano frammentati o dipendono dalla memoria delle persone.
Che cosa comprende davvero
Comprende perimetro, obiettivi, ruoli, accessi, fonti di verità, standard di qualità, tempi, dipendenze, gestione delle modifiche e procedura di uscita. Il suo scopo è rendere il sistema comprensibile e trasferibile anche quando cambiano persone o partner.
Quando diventa necessaria
Serve quando più agenzie o specialisti lavorano sullo stesso sito, campagne e dati; quando l’azienda dipende da account intestati al fornitore; quando i deliverable non hanno criteri di accettazione; quando marketing, IT e vendite ricevono versioni differenti dello stesso risultato.
Che cosa deve restare all’azienda
Domini, hosting, account pubblicitari, analytics, CRM, repository, creatività, dati, documentazione e credenziali principali dovrebbero avere proprietà e accesso aziendale. Il fornitore riceve i privilegi necessari, non il controllo esclusivo dell’infrastruttura.
Come definire responsabilità e qualità
Una matrice RACI chiarisce chi è responsabile, chi approva, chi viene consultato e chi informato. Ogni deliverable deve indicare input, formato, scadenza, revisore, criteri di completamento e manutenzione successiva.
Come gestire modifiche e conflitti
Nuove richieste, ritardi di dipendenze, priorità cambiate e problemi di qualità devono entrare in un change log. Le decisioni non vanno disperse tra email e call: servono una fonte comune e un owner lato cliente.
Come preparare la continuità
Onboarding, documentazione, naming, backup, esportazioni, revoca degli accessi e handover riducono il rischio di lock-in. La possibilità di sostituire un fornitore senza perdere mesi di conoscenza è un indicatore di buona governance.
Quando serve
- Lavorano sul progetto più fornitori o reparti.
- Account, dati o codice sono controllati da soggetti esterni.
- I risultati sono difficili da verificare o confrontare.
- Le priorità cambiano spesso e generano extra non tracciati.
- Esiste un rischio concreto di dipendenza da una singola persona.
Che cosa non risolve da solo
- Non sostituisce competenza e fiducia.
- Non richiede burocrazia identica per ogni microattività.
- Non deve trasformare ogni decisione in un comitato.
- Non corregge obiettivi commerciali ancora indefiniti.
Matrice di orientamento
| Dimensione | Oggetto | Decisione | Cautela |
|---|---|---|---|
| Proprietà | Account, dominio, dati | Intestazione aziendale | Ridurre lock-in |
| Accessi | Ruoli e privilegi | Least privilege | Revoca e audit |
| Deliverable | Formato e accettazione | Definition of done | No output ambiguo |
| Tempi | SLA e dipendenze | Escalation | Non promettere l’impossibile |
| Decisioni | Priorità e change log | Owner cliente | Una fonte di verità |
| Uscita | Export e handover | Runbook | Testare la trasferibilità |
Output minimi
- Mappa di account e proprietà
- RACI cliente-fornitori
- Catalogo dei deliverable
- SLA e change process
- Piano di handover e revoca
La mappa degli account deve corrispondere agli accessi reali, la RACI alle approvazioni praticate e il catalogo dei deliverable ai file effettivamente consegnati. SLA, change process e piano di handover diventano operativi solo quando il referente aziendale sa attivarli, i fornitori ne conoscono i passaggi e una prova conferma che esportazioni e revoche funzionano.
Indicatori da osservare
- Account senza owner aziendale
- Deliverable respinti o riaperti
- Tempi bloccati da dipendenze
- Modifiche non preventivate
- Accessi privilegiati non necessari
- Tempo necessario a un handover
Ogni misura deve rispondere a una domanda concreta sulla relazione con i fornitori. Molti ticket chiusi possono nascondere riaperture; tempi rapidi possono dipendere da revisioni superficiali; pochi change request possono indicare stabilità oppure richieste gestite fuori registro. Il confronto deve quindi distinguere consegna, accettazione, blocchi, rilavorazioni e rischi di accesso.
Scenario applicativo
Tre fornitori gestiscono sito, campagne e CRM. Ognuno usa una propria nomenclatura e il cliente non possiede l’account principale di un servizio.
La governance riallinea proprietà, ruoli, naming e Definition of Done. I fornitori restano specialisti autonomi, ma lavorano su un sistema comune e trasferibile.
Errori da evitare
- Confondere governance e controllo ossessivo.
- Lasciare account intestati al fornitore.
- Definire attività ma non criteri di accettazione.
- Non assegnare un owner interno.
- Conservare decisioni solo nelle call.
- Preparare l’uscita quando il rapporto è già in crisi.
Scrivere SLA che gestiscano anche dipendenze e revisioni
Uno SLA utile non assegna lo stesso tempo a qualsiasi richiesta. Deve distinguere incidenti, attività pianificate, revisioni e domande informative, perché ciascuna categoria richiede priorità e modalità di risposta differenti. È importante chiarire anche quando inizia il conteggio: una richiesta priva di credenziali, materiali o approvazione non può essere trattata come un’attività pronta per l’esecuzione.
Elementi da precisare
- Canale di ingresso: il luogo nel quale la richiesta viene registrata e può essere ritrovata.
- Classificazione: gravità, urgenza e impatto, con esempi che riducano interpretazioni divergenti.
- Tempo di presa in carico: distinto dal tempo necessario per completare il lavoro.
- Pause ammesse: attese dovute a input, accessi o approvazioni mancanti, con motivazione visibile.
- Escalation: persone da coinvolgere quando un blocco supera la soglia concordata o coinvolge più fornitori.
La qualità non va affidata soltanto alla scadenza. Per una landing, per esempio, la consegna può richiedere verifica dei contenuti, comportamento responsive, tracciamento, form e routing. Se questi controlli non sono esplicitati, il fornitore può considerare concluso il lavoro al caricamento della pagina, mentre il cliente si aspetta un percorso già collaudato.
Provare l’handover prima che sia necessario
Il piano di uscita dovrebbe essere verificato durante una fase ordinaria del rapporto. Si può scegliere un account o un’attività circoscritta e controllare se un’altra persona riesce a trovare credenziali, configurazioni, file sorgente, cronologia delle modifiche e istruzioni di ripristino senza dipendere da spiegazioni informali.
- Esportare un campione di dati in un formato riutilizzabile.
- Verificare che gli accessi amministrativi appartengano all’azienda.
- Simulare revoca e riassegnazione dei privilegi senza interrompere il servizio.
Le lacune emerse dalla prova vanno corrette mentre il rapporto è stabile. Questo riduce il lock-in, ma migliora anche il lavoro quotidiano: documentazione e accessi ordinati rendono più semplici sostituzioni temporanee, audit e collaborazione tra specialisti.
Domande frequenti
Serve anche con un solo fornitore?
Sì, in forma proporzionata: proprietà, accessi, deliverable e continuità restano importanti.
Chi deve essere l’owner interno?
Una persona con autorità sulle priorità e accesso a marketing, vendite e IT, non un semplice tramite amministrativo.
Lo SLA garantisce il risultato?
No. Definisce tempi e responsabilità operative; i risultati di mercato dipendono anche da domanda, offerta e dati.
Approfondisci il servizio: Consulenza marketing B2B.