SLA Template WordPress: Cosa Garantire ai Clienti

Perché serve un SLA per siti WordPress

Un Service Level Agreement (SLA) ben strutturato protegge sia l’agenzia che il cliente, definendo aspettative realistiche sui servizi di manutenzione WordPress. Senza un SLA chiaro, ogni rallentamento diventa un’emergenza e ogni ticket ha priorità massima.

Secondo dati del 2025, le agenzie con SLA documentati registrano il 43% in meno di dispute contrattuali e tempi di escalation ridotti del 58%. Un SLA non è solo un documento legale: è uno strumento operativo che guida il triage dei ticket e l’allocazione delle risorse.

Gli elementi critici di un SLA WordPress includono metriche misurabili, definizioni precise dei livelli di servizio, procedure di escalation e limiti chiari su cosa è coperto dal contratto base.

Metriche di uptime e disponibilità

L’uptime è la metrica più visibile per i clienti, ma va definita con precisione per evitare ambiguità.

Standard di uptime realistici

Per siti WordPress su hosting condiviso o VPS gestito, garantire:

• 99.5% uptime mensile: equivale a 3.6 ore di downtime potenziale al mese, realistico per la maggior parte dei progetti
• 99.9% uptime mensile: 43 minuti di downtime, appropriato per e-commerce e siti business-critical con hosting dedicato
• 99.95% uptime mensile: 21 minuti, richiede infrastruttura ridondante e monitoraggio H24

Evitate il 100% di uptime: è irrealistico e vi espone a contestazioni per manutenzioni programmate. Specificate sempre che la manutenzione pianificata con preavviso di 48 ore è esclusa dal calcolo dell’uptime.

Cosa escludere dal calcolo uptime

• Downtime causato da provider hosting terzi (includi SLA del provider come riferimento)
• Attacchi DDoS superiori a soglie specifiche (es. 10 Gbps)
• Problemi di rete non dipendenti dall’infrastruttura gestita
• Modifiche richieste dal cliente che causano instabilità
• Manutenzioni programmate in finestre concordate (tipicamente notturne)

Monitoraggio e reporting

Implementate monitoraggio con strumenti come UptimeRobot, Pingdom o Better Uptime con check ogni 1-5 minuti. Fornite dashboard cliente con:

• Status page pubblico o privato
• Report mensili automatici con metriche di disponibilità
• Log di incident con durata e causa radicale

Tempi di risposta e risoluzione

I tempi di risposta sono più controllabili dell’uptime e creano aspettative gestibili sul supporto.

Schema a tre livelli di priorità

Definite priorità chiare con esempi concreti:

P1 – Critico (sito completamente inaccessibile)

• Tempo di risposta: 1 ora (h24 solo per piani premium)
• Tempo di risoluzione target: 4 ore
• Esempi: homepage in errore 500, database irraggiungibile, sito hackerato
• Canale: telefono + ticket prioritario

P2 – Alto (funzionalità importante compromessa)

• Tempo di risposta: 4 ore lavorative
• Tempo di risoluzione target: 24 ore
• Esempi: form contatti non funzionante, checkout e-commerce bloccato, errori su pagine specifiche
• Canale: ticket + email

P3 – Normale (problemi minori e richieste)

• Tempo di risposta: 24 ore lavorative
• Tempo di risoluzione target: 72 ore
• Esempi: piccoli bug layout, aggiornamenti contenuti, ottimizzazioni performance
• Canale: ticket standard

Ore lavorative vs H24

Specificate chiaramente gli orari di copertura:

• Piano Base: Lun-Ven 9-18, esclusi festivi nazionali
• Piano Business: Lun-Ven 8-20, Sab 9-13
• Piano Premium: H24/7 per P1, orari estesi per P2-P3

Per emergenze fuori orario su piani base, prevedete tariffe on-demand (es. 150-300€/ora con minimo 2 ore).

Manutenzione e aggiornamenti

Gli aggiornamenti WordPress sono fonte frequente di incomprensioni. Lo SLA deve chiarire cosa, quando e come viene aggiornato.

Politica di aggiornamento standard

• Core WordPress: aggiornamenti minori automatici entro 48h, major version entro 14 giorni dopo test su staging
• Plugin e temi: aggiornamenti mensili programmati (prima settimana del mese), con testing preventivo
• Patch di sicurezza: entro 24-48 ore dalla pubblicazione, con priorità su vulnerabilità critiche
• PHP e stack: allineamento a versioni supportate con preavviso 30 giorni per major changes

Processo di testing

Documentate il workflow di aggiornamento:

1. Backup completo pre-aggiornamento (database + files)
2. Test su ambiente staging per siti business/premium
3. Aggiornamento in produzione durante finestra manutenzione
4. Smoke test post-aggiornamento (homepage, funzioni critiche)
5. Rollback automatico se errori critici rilevati

Limitazioni e esclusioni

Specificate cosa non è coperto dalla manutenzione ordinaria:

• Aggiornamenti di plugin/temi premium senza licenza attiva
• Refactoring di codice custom incompatibile con nuove versioni
• Migrazione tra hosting provider
• Redesign o modifiche strutturali

Backup e disaster recovery

I backup sono assicurazione, non optional. Lo SLA deve definire retention, frequenza e procedure di restore.

Policy di backup raccomandata

• Backup completi: giornalieri per 7 giorni, settimanali per 4 settimane, mensili per 3 mesi
• Backup database: ogni 6-12 ore per e-commerce, giornalieri per siti standard
• Storage: minimo 2 location (server + cloud esterno tipo S3, Backblaze)
• Test restore: trimestrale su ambiente staging, report al cliente

Recovery Time Objective (RTO)

Definite tempi di ripristino realistici:

• RTO Standard: ripristino completo entro 6 ore lavorative da richiesta approvata
• RTO Premium: ripristino entro 2 ore H24
• Point-in-time recovery: possibile per ultimi 30 giorni con preavviso

Importante: specificate che il cliente deve approvare il restore point, assumendosi responsabilità per dati creati dopo quel momento.

Performance e ottimizzazione

Le aspettative di performance vanno quantificate, altrimenti “il sito è lento” diventa soggettivo.

Metriche Core Web Vitals target

Basate su Google Core Web Vitals (dati mobile, 75° percentile):

• LCP (Largest Contentful Paint): < 2.5 secondi
• FID (First Input Delay): < 100 millisecondi
• CLS (Cumulative Layout Shift): < 0.1

Specificate che questi target sono garantiti con:

• Hosting conforme alle specifiche minime concordate
• Contenuti ottimizzati (immagini < 500KB, video esterni)
• Numero ragionevole di plugin attivi (tipicamente < 25)

Limitazioni tecniche

Escludete esplicitamente:

• Performance su connessioni < 3G o reti congestionate
• Ritardi causati da servizi terzi (payment gateway, API esterne)
• Problemi legati a CDN o DNS provider scelti dal cliente

Sicurezza e hardening

La sicurezza WordPress richiede approccio stratificato. Lo SLA deve chiarire misure preventive e reattive.

Misure di sicurezza incluse

• Firewall applicativo (WAF) configurato con regole WordPress-specific
• Scansioni malware settimanali con strumenti come Wordfence o Sucuri
• Hardening base: disabilitazione file editor, protezione wp-config, security headers
• Gestione credenziali: policy password forti, 2FA obbligatorio per admin
• Rate limiting su login e API endpoints

Gestione compromissioni

Definite processo e tempistiche per siti compromessi:

1. Rilevamento: notifica cliente entro 2 ore da detection
2. Contenimento: isolamento sito entro 4 ore (modalità manutenzione o offline)
3. Analisi: identificazione vettore attacco entro 24 ore
4. Pulizia: rimozione malware e restore da backup pulito entro 48 ore
5. Hardening: implementazione misure preventive aggiuntive

Importante: specificate costi aggiuntivi per cleanup complessi (es. 500-2000€ se richiede analisi forense approfondita).

Supporto e comunicazione

Canali e modalità di comunicazione vanno standardizzati per evitare dispersione di richieste.

Canali supportati per priorità

• P1 Critico: telefono dedicato (solo orari H24 se incluso) + ticket sistema
• P2-P3: sistema ticketing centralizzato (es. AgencyPilot, Help Scout, Zendesk)
• Domande generali: email con SLA 48 ore

Canali esplicitamente esclusi

Per mantenere tracciabilità e SLA, escludete:

• WhatsApp, Telegram, SMS personali (eccetto emergenze P1 pre-accordate)
• Social media DM
• Email personali dei tecnici
• Chiamate non documentate da ticket follow-up

Reporting mensile

Fornite report standardizzato con:

• Uptime effettivo vs SLA
• Numero ticket per priorità e tempo medio risoluzione
• Aggiornamenti effettuati (core, plugin, temi)
• Incidenti di sicurezza e azioni correttive
• Raccomandazioni per miglioramenti (opzionale per piani premium)

Penali e compensazioni

Le penali rendono credibile lo SLA ma vanno calibrate per non esporre l’agenzia a rischi insostenibili.

Schema compensazione uptime

Esempio di service credit basato su mancato raggiungimento uptime mensile:

• 99.5-99.0%: 10% credito canone mese successivo
• 99.0-98.0%: 25% credito
• < 98.0%: 50% credito

Massimale: compensazione non superiore al 100% del canone mensile. Nessun rimborso cash, solo service credit.

Condizioni per compensazione

Il cliente deve:

• Segnalare il problema entro 24 ore dalla rilevazione
• Fornire evidenze (screenshot, log, report monitoraggio terzi)
• Richiedere compensazione entro 15 giorni da fine mese

Clausole aggiuntive essenziali

Responsabilità del cliente

Lo SLA funziona se anche il cliente rispetta obblighi:

• Fornire accessi completi e aggiornati (hosting, dominio, servizi terzi)
• Non effettuare modifiche senza coordinamento su siti in manutenzione
• Mantenere licenze attive per software premium
• Approvare aggiornamenti major entro 7 giorni dalla notifica
• Pagare canoni nei termini concordati (ritardi > 15gg sospendono SLA)

Limiti di responsabilità

Clausole di limitazione liability essenziali:

• Massimale responsabilità: valore 12 mesi di canoni per danni diretti
• Esclusione danni indiretti, perdite di profitto, danni reputazionali
• Force majeure: eventi straordinari fuori controllo (calamità, interruzioni internet nazionali)

Modifica e revisione SLA

Prevedete clausola di revisione:

• SLA rivisto annualmente o su richiesta con 30 giorni preavviso
• Modifiche sostanziali richiedono accettazione esplicita
• Adeguamenti tecnici (es. nuove metriche Google) comunicati con 60 giorni preavviso

Template operativo pronto all’uso

Un template SLA pratico per WordPress dovrebbe includere questi documenti collegati:

• SLA principale: documento contrattuale con metriche e obblighi (3-5 pagine)
• Matrice di priorità: tabella rapida con esempi per ogni livello (1 pagina, da condividere con cliente)
• Processo escalation: flowchart con contatti per livello di gravità
• Checklist onboarding: verifica prerequisiti tecnici prima attivazione SLA

Integrate lo SLA nel vostro sistema di ticketing per:

• Auto-classificazione priorità basata su keyword
• Alert automatici su SLA a rischio (es. ticket P2 aperto da 20 ore)
• Dashboard real-time per rispetto SLA per cliente

Strumenti come AgencyPilot permettono di monitorare SLA multi-cliente con dashboard unificate e alert automatici quando i tempi di risposta si avvicinano alle soglie critiche.

FAQ

Cosa succede se non rispetto i tempi di risposta dello SLA?

Dipende dalle penali concordate. Tipicamente si applicano service credit proporzionali alla gravità e frequenza delle violazioni. L’importante è documentare tutto: se il ritardo è causato da mancata risposta del cliente o problemi di hosting terzo, lo SLA può prevedere esenzioni. Implementate sistema di alert interno per intercettare ticket a rischio prima della scadenza SLA.

Devo offrire supporto H24 per tutti i clienti?

No, anzi è sconsigliato per piani base. Riservate H24 solo per clienti premium con canoni che giustificano reperibilità notturna (tipicamente >500€/mese). Per altri clienti offrite supporto in orario lavorativo esteso (es. 8-20) e prevedete interventi fuori orario solo per emergenze P1 con tariffazione extra o callback mattina seguente per P2-P3.

Come calcolare l’uptime se uso hosting condiviso per i clienti?

Basatevi sullo SLA del provider hosting e sottraete 0.3-0.5% come margine. Se l’hosting garantisce 99.9%, voi garantite massimo 99.5% per coprire eventuali problemi WordPress-specific non dipendenti da infrastruttura. Implementate monitoraggio indipendente (UptimeRobot, Pingdom) come fonte di verità per dispute e non affidate solo ai report del provider.

Gli aggiornamenti plugin possono rompere il sito: come gestirlo nello SLA?

Prevedete ambiente staging obbligatorio per clienti business/premium dove testare aggiornamenti prima della produzione. Per clienti base su hosting condiviso senza staging, lo SLA deve specificare che gli aggiornamenti comportano rischio residuo e prevedere rollback rapido (entro 1 ora) se rilevati problemi critici. Escludete responsabilità per plugin abbandonati o non più compatibili, richiedendo approvazione cliente per sostituzione.

Quanto devo far pagare per garantire uno SLA solido?

Dipende dai livelli di servizio. Come riferimento 2026 per il mercato italiano: piano base con uptime 99.5% e supporto orario lavorativo 80-150€/mese per sito; piano business con 99.9%, staging e orari estesi 200-400€/mese; piano premium con H24, monitoring avanzato e SLA stringenti da 500€/mese in su. Calcolate almeno 3-5 ore/mese di effort per cliente per manutenzione ordinaria più buffer per emergenze.