Ogni agenzia web che gestisce siti per i propri clienti accumula debito tecnico. Non in modo drammatico, non tutto insieme: piano piano, un plugin non aggiornato alla settimana, una richiesta di fix minore al mese, un tema incompatibile che emerge durante un aggiornamento. Il risultato è che il titolare, il project manager o, nei casi peggiori, il commerciale che dovrebbe stare acquisendo clienti, finisce a rispondere a “il form non funziona più” alle undici di martedì mattina.
Il problema non è la singola richiesta. Il problema è che queste richieste non hanno mai una stima del costo reale per l’agenzia, arrivano in modo imprevedibile, e interrompono attività che valgono molto di più dell’intervento richiesto. La manutenzione WordPress non strutturata è uno dei principali generatori di costi nascosti nelle agenzie web, e quasi nessuno la contabilizza in modo esplicito.
Noi di Blurr gestiamo la manutenzione tecnica di centinaia di siti WordPress per conto delle agenzie partner. Quello che vediamo sui progetti che prendiamo in carico da situazioni non strutturate è quasi sempre lo stesso schema.
Il debito tecnico WordPress si accumula in silenzio
Il termine “debito tecnico” nasce nello sviluppo software per descrivere il costo futuro delle scorciatoie prese nel presente. Nel contesto della manutenzione WordPress, si manifesta in modo molto concreto: plugin aggiornati in produzione senza staging, temi non toccati da due anni perché “funziona tutto”, conflitti tra plugin risolti disattivando quello che dava problemi invece di capire la causa, versioni PHP lasciate indietro perché nessuno ha mai trovato il momento giusto per aggiornarle.
Ognuna di queste scorciatoie ha un costo differito. Un plugin non aggiornato da diciotto mesi non è un problema oggi. Diventa un problema il giorno in cui WooCommerce rilascia un aggiornamento che richiede PHP 8.2 e il sito gira su PHP 7.4 da tre anni. A quel punto l’intervento non è più dieci minuti: è mezza giornata su un sito in produzione che il cliente usa ogni giorno.
Sui siti che prendiamo in gestione dopo anni di manutenzione informale, troviamo sistematicamente tre o quattro plugin installati e disattivati da mesi che nessuno ha rimosso, versioni PHP non aggiornate per timore di rompere qualcosa, e temi con modifiche dirette al codice senza child theme: modifiche che vanno perse ad ogni aggiornamento e che qualcuno deve riapplicare ogni volta.
Quanto tempo costa davvero la manutenzione non strutturata
Un caso che ricordiamo bene: un’agenzia di Verona, cinque persone, clienti principalmente nel settore manifatturiero e servizi B2B. Gestivano internamente la manutenzione di circa venticinque siti. Nessun processo formale: gli aggiornamenti si facevano quando qualcuno trovava il momento, i backup erano affidati al pannello di hosting senza mai essere verificati, e le richieste dei clienti arrivavano via WhatsApp al titolare direttamente.
Quando ci hanno contattato, la situazione che ci hanno descritto era questa: il titolare dedicava mediamente due ore al giorno a rispondere a richieste tecniche dei clienti, inclusa la sera. Non perché i siti avessero problemi gravi, ma perché ogni piccola cosa, un plugin che aggiornato aveva spostato un elemento grafico, un form che non inviava più perché il provider aveva cambiato le impostazioni SMTP, un cliente che non riusciva ad accedere all’area admin, finiva sul suo telefono. In un anno aveva perso due opportunità commerciali concrete perché durante le trattative era stato interrotto da emergenze tecniche che non riusciva a delegare a nessuno.
Abbiamo preso in carico la manutenzione dei venticinque siti. Il primo mese abbiamo trovato sette plugin con vulnerabilità note non patchate, tre siti con backup dell’hosting mai verificati (uno non funzionava da quattro mesi), e due installazioni su PHP 7.4 con WooCommerce che richiedeva già 8.0. Risolto tutto in staging prima di toccare la produzione. Dal secondo mese, le richieste tecniche urgenti al titolare si sono azzerate. Adesso usa quelle due ore per fare altro.
La difficoltà nel misurare il costo è che gli interventi arrivano spalmati su settimane e mesi, associati a progetti diversi, mai contabilizzati come voce separata. Si tratta di dieci minuti qui, venti minuti là, una mezz’ora per capire perché il plugin di contatto ha smesso di inviare le email.
Incrociando i dati di gestione sui progetti che abbiamo preso in carico negli ultimi anni, il quadro che emerge è questo: un’agenzia che gestisce internamente la manutenzione di venti siti WordPress, senza un processo strutturato, impiega mediamente tra le quattro e le sei ore mensili per interventi tecnici non pianificati. Aggiornamenti che rompono qualcosa, richieste di micro-fix da parte dei clienti, problemi di compatibilità tra plugin, verifiche di backup dopo segnalazioni di anomalie.
Quattro ore al mese sembrano poche. Sono però quattro ore che non appartengono a nessun progetto fatturabile, gestite da una persona con un costo orario reale, distribuite in modo imprevedibile e capaci di interrompere attività molto più strategiche. Su quaranta siti il tempo raddoppia. Su sessanta inizia a richiedere una risorsa dedicata.
Il costo più alto non è il tempo in sé. È il costo dell’interruzione: un account manager che interrompe una trattativa commerciale per gestire un conflitto tra plugin perde non solo i venti minuti dell’intervento, ma anche il contesto della trattativa che deve ricostruire. Chi ha lavorato su attività che richiedono concentrazione sa che il costo del rientro è spesso maggiore del costo dell’interruzione stessa.
Le categorie di micro-task che consumano più tempo
Monitorando i ticket aperti sui siti in manutenzione, le categorie che assorbono più ore non pianificate sono sempre le stesse.
Aggiornamenti che rompono qualcosa. Un plugin aggiornato in produzione che rompe il layout della homepage o disabilita una funzionalità critica richiede un rollback, l’identificazione del conflitto e una soluzione. Su un sito con staging questo si gestisce prima del go-live. Senza staging, si gestisce in emergenza sul sito del cliente.
Form di contatto che smettono di funzionare. È il classico ticket che arriva con urgenza perché il cliente non riceve richieste da tre giorni. Le cause sono varie: filtri anti-spam che bloccano le email, modifiche alle impostazioni del server, aggiornamenti del plugin che cambiano la configurazione. Ogni volta richiede verifica, diagnosi e fix.
Siti che rallentano senza motivo apparente. Un cliente che segnala che “il sito è lento” genera un’analisi che può durare da dieci minuti a un’ora, a seconda della causa. Cache non configurata, immagini non ottimizzate caricate dopo un aggiornamento del CMS, plugin che generano query lente.
Richieste di modifica minimali fuori contratto. “Puoi cambiare questo testo?”, “il numero di telefono è sbagliato”, “puoi aggiungere questo link nel menu?”. Singolarmente richiedono cinque minuti. Su venti clienti attivi, arrivano costantemente e consumano tempo di una risorsa che potrebbe fare altro.
La differenza tra manutenzione strutturata e assistenza reattiva
L’approccio che la maggior parte delle agenzie segue è reattivo: si interviene quando qualcosa si rompe. L’approccio strutturato previene i problemi prima che diventino emergenze.
La differenza pratica: un sito con aggiornamenti testati mensilmente su staging, backup verificati settimanalmente e monitoraggio automatico dell’uptime genera richieste di assistenza reattiva in misura molto inferiore rispetto a un sito aggiornato solo quando qualcosa smette di funzionare. Non elimina le richieste, ma le riduce e, soprattutto, fa sì che gli interventi necessari siano pianificati invece che improvvisati.
Per le agenzie che gestiscono più di dieci siti in manutenzione, la soglia oltre la quale strutturare questo processo in modo sistematico è quasi sempre già stata superata. I piani di manutenzione mensile in white label risolvono esattamente questo problema: il processo tecnico viene gestito da Blurr, i costi sono fissi e prevedibili, e l’agenzia smette di ricevere micro-ticket tecnici che interrompono il lavoro strategico.
Se vuoi capire quante ore mensili potresti recuperare strutturando la manutenzione in modo diverso, blurr.it/contatti/ è il punto di partenza: facciamo una valutazione basata sul numero di siti che gestisci e sulla tipologia di interventi che ti arrivano più spesso.
FAQ
Come si misura il debito tecnico accumulato su un sito WordPress? I segnali più diretti: versione PHP del server rispetto ai requisiti attuali di WordPress e WooCommerce, numero di plugin non aggiornati da più di sei mesi, presenza di modifiche dirette ai file del tema senza child theme, assenza di un ambiente di staging per testare gli aggiornamenti. Non esiste un numero univoco, ma un audit tecnico di un’ora su questi quattro punti dà un quadro preciso della situazione.
Quando conviene strutturare la manutenzione WordPress in white label invece di gestirla internamente? Oltre i dieci siti in gestione, il costo dell’approccio reattivo supera quasi sempre il costo di una manutenzione strutturata. Sotto quella soglia dipende dal tipo di siti: siti con aggiornamenti frequenti dei contenuti, ecommerce attivi e plugin complessi generano più richieste di assistenza dei siti vetrina statici.
La manutenzione white label copre anche le richieste di modifica dei contenuti? Dipende da come viene strutturato il piano. La manutenzione tecnica standard copre aggiornamenti WordPress e plugin, backup, monitoraggio uptime e interventi su problemi tecnici. Le modifiche ai contenuti, testi, immagini, prezzi, sono generalmente gestite come interventi separati, quotati a ore o inclusi in un pacchetto di ore mensili predefinito.
Come si comunica al cliente che la manutenzione è gestita da un partner esterno? Non si comunica. L’accordo white label prevede che il partner tecnico rimanga invisibile: tutti i report di manutenzione vengono inviati con il brand dell’agenzia, le comunicazioni al cliente passano sempre attraverso l’agenzia, e il partner non ha nessun contatto diretto con il cliente finale. Dal punto di vista del cliente, la manutenzione è gestita dalla sua agenzia di fiducia.