Un’agenzia gestisce 35 siti dei clienti con un piccolo team di sviluppo. I siti sono online, l’infrastruttura regge e, vista dall’esterno, non sembra esserci nulla di particolarmente urgente.

All’interno dell’agenzia, però, le crepe sono più evidenti. Ad esempio:

  • Un ex sviluppatore senior ha ancora l’accesso come Amministratore aziendale a tutti i siti dell’account, anche dopo sei mesi che non lavora più lì.
  • Esiste un ambiente di staging di WooCommerce, ma nessuno sa con certezza se rispecchi il sito di produzione attuale.
  • Gli aggiornamenti dei plugin si stanno accumulando nelle installazioni dei clienti e il team se ne occupa solo quando qualcuno ha tempo da perdere.

Tecnicamente non c’è ancora nulla che non funzioni, ma ogni nuovo cliente aggiunge ulteriori attriti interni. Ci sono più credenziali, ambienti di staging, decisioni sugli aggiornamenti, passaggi di consegne e domande su utilizzo, prestazioni e costi.

Per le agenzie WordPress, la crescita spesso mette in luce i problemi di flusso di lavoro prima ancora di quelli di hosting. Questo articolo tratta cinque dei punti critici più comuni, le loro cause e come una configurazione migliore si presenterebbe su Kinsta.

Il problema nascosto: il “debito di flusso di lavoro”

I flussi di lavoro delle piccole agenzie spesso partono da scorciatoie pratiche:

  • Accesso condiviso
  • Approvazioni su Slack
  • Aggiornamenti manuali
  • Abitudini di staging ormai consolidate
  • Conoscenze specifiche sul cliente che solo una o due persone hanno

Questo funziona quando l’elenco dei clienti è ridotto, perché il team riesce a tenere traccia dei dettagli. Ma man mano che l’agenzia cresce, queste scorciatoie diventano più pesanti.

Più siti, collaboratori esterni, ambienti, approvazioni e attività di manutenzione rendono il vecchio modo di lavorare sempre più difficile da gestire. L’agenzia potrebbe avere ancora abbastanza capacità di hosting, ma il team ha meno chiarezza su come muoversi.

Questo è il debito di workflow. Si accumula quando le persone devono ricordarsi il processo prima di poterlo seguire.

1. Il problema degli accessi: tutti hanno troppi diritti

Le piccole agenzie spesso concedono accessi poco regolamentati perché sembra l’opzione più veloce, ma questa comodità crea rischi man mano che l’agenzia cresce. Ad esempio, ex membri del team che mantengono l’accesso troppo a lungo, o clienti che hanno visibilità su ambienti a cui non dovrebbero accedere.

Il danno raramente si traduce in una violazione. Più spesso, si tratta di un rischio invisibile che rimane latente nell’account finché qualcuno non apporta una modifica irreversibile.

Un flusso di lavoro migliore parte da un accesso che corrisponda al ruolo effettivo di ogni persona. La gestione utenti di MyKinsta permette alle agenzie di assegnare l’accesso a livello aziendale o a livello di sito, con ruoli distinti per ciascuno:

Gestione utenti in MyKinsta
Regolare l’accesso degli utenti e dell’azienda ai siti e alle funzioni dei siti in MyKinsta

Per il lavoro quotidiano su WordPress, MyKinsta offre anche il login automatico a WP Admin, che può ridurre la necessità di condividere le credenziali. Quando qualcuno ha già i giusti permessi su MyKinsta, può accedere a WordPress senza dover passare credenziali amministrative separate.

2. Il problema del caos nello staging: nessuno sa quale ambiente sia quello attuale

L’uso dello staging diventa complicato quando il team cresce più velocemente del processo. Uno sviluppatore potrebbe creare un ambiente di staging per una riprogettazione, mentre un altro potrebbe apportare una correzione veloce sul sito live. In poco tempo, nessuno è più del tutto sicuro di quale ambiente rifletta il sito attuale.

Con cinque clienti, il team riesce a tenere tutto a mente. Con 20 clienti, non ce la fa più.

Una configurazione più solida assegna a ogni ambiente un ruolo ben definito. Ad esempio: lo sviluppo locale serve per la creazione e il testing, lo staging per la revisione interna, l’approvazione del cliente e i controlli pre-lancio, mentre il live è riservato esclusivamente al lavoro approvato.

Kinsta supporta questo flusso di lavoro con DevKinsta per lo sviluppo locale.

DevKinsta
DevKinsta offre un ottimo modo per fornire ambienti di staging.

E ambienti di staging per ogni installazione di WordPress. Gli URL di staging coerenti facilitano anche i cicli di revisione, perché i clienti e i team interni sanno dove cercare.

ambienti di staging
Configurare gli ambienti di staging con Kinsta

Anche il processo di push è importante. Grazie alle opzioni di push selettivo, le agenzie possono spostare file, il database o entrambi tra gli ambienti. Questo controllo è particolarmente utile per i negozi WooCommerce, i siti con abbonamento e altri siti in cui i dati in produzione cambiano costantemente.

trasferimento a live
Opzioni di push selettivo

Per progetti più grandi o più delicati, gli ambienti di staging Premium offrono alle agenzie una configurazione di test che rispecchia più da vicino l’ambiente di produzione. Questo può essere d’aiuto per siti ad alto traffico, negozi e-commerce, siti con iscrizione e lavori in cui le prestazioni sono fondamentali.

Tuttavia, gli strumenti sono utili solo se il team li usa con costanza. Le agenzie hanno bisogno di convenzioni di denominazione, regole di revisione e autorizzazioni di push chiare, così che tutti sappiano quale ambiente è quello attuale e chi può pubblicare le modifiche.

3. Il problema degli aggiornamenti arretrati: la manutenzione diventa un lavoro a tempo pieno

Nella maggior parte dei percorsi di crescita delle agenzie arriva un momento in cui qualcuno si rende conto che gli aggiornamenti dei plugin sono diventati un’attività a sé stante. Qualcuno del team si collega a una dashboard dopo l’altra, esegue gli aggiornamenti, controlla che non si sia rotto nulla e passa al sito successivo. Con 40 siti di clienti, questa operazione può facilmente richiedere dalle tre alle quattro ore a settimana.

Poi c’è la questione delle vulnerabilità. Su larga scala, un’agenzia potrebbe avere siti che in questo momento utilizzano plugin obsoleti con problemi di sicurezza noti, senza avere modo di individuare rapidamente quali siano.

Se uno sviluppatore impiega quattro ore alla settimana per gli aggiornamenti manuali, con un costo orario complessivo di 60 dollari, si tratta di 240 dollari a settimana e 12.480 dollari all’anno di manodopera che un processo di aggiornamento strutturato elimina in gran parte.

In MyKinsta ci sono due funzioni che lavorano insieme per risolvere questo problema.

La prima è il filtro delle vulnerabilità nell’elenco dei siti. In MyKinsta, le agenzie possono filtrare l’intero elenco dei siti per visualizzare solo quelli con plugin o temi vulnerabili.

vulnerabilità del sito
Visualizzare i siti con vulnerabilità per aggiornarli più velocemente.

La seconda è la funzione Aggiornamenti automatici di Kinsta (3 $ al mese per ambiente). Include test di regressione visiva che confrontano gli screenshot prima e dopo ogni aggiornamento e ripristinano automaticamente la versione precedente se qualcosa non funziona visivamente.

aggiornamenti automatici di Kinsta
Configura gli aggiornamenti automatici di Kinsta

Gli aggiornamenti possono anche essere programmati per evitare le ore di picco di traffico e le operazioni in modalità manutenzione, così i visitatori non vedranno il sito malfunzionante.

Modifica gli aggiornamenti automatici
Modificare la pianificazione degli aggiornamenti automatici

Per le agenzie che vogliono creare i propri flussi di lavoro di manutenzione, l’API di Kinsta offre anche l’accesso programmatico ai dati dei plugin e dei temi su tutti i siti dell’account, così i team possono controllare lo stato degli aggiornamenti su tutto il portafoglio senza dover aprire le singole dashboard.

4. Il problema del passaggio di consegne: l’onboarding e l’offboarding mettono a nudo i sistemi disorganizzati

L’onboarding e l’offboarding rivelano quanto sia efficiente il funzionamento effettivo di un’agenzia.

Quando un nuovo cliente si accontenta, il team migra il sito, imposta l’ambiente di staging, configura gli accessi, lo assegna allo sviluppatore giusto e lo etichetta correttamente nella dashboard. Se fatto bene, segue ogni volta un percorso coerente; altrimenti, viene leggermente improvvisato di volta in volta, con piccole variazioni che si accumulano creando un debito operativo.

Con cinque clienti, improvvisare va bene. Uno sviluppatore ricorda lo stack dei plugin. Un project manager sa dove si trovano le credenziali. Tuttavia, con 40 clienti, quel modello basato sulla memoria crolla.

Il problema dell’offboarding è spesso ancora peggiore. Un cliente se ne va, il sito deve essere trasferito sul suo hosting e l’agenzia deve separare le credenziali dall’installazione di WordPress, disattivare l’ambiente di staging, verificare chi ha ancora accesso e passare il testimone senza perdere nulla di importante.

Kinsta aiuta le agenzie a creare una versione più ordinata di entrambi.

Le migrazioni gestite gratuite eliminano il picco di lavoro più impegnativo durante l’onboarding. Da lì, le agenzie possono seguire una configurazione coerente: ambiente di staging, ruoli di accesso assegnati ed etichette dei siti che organizzano il portfolio per cliente, livello di servizio o stato dell’account.

Richiedere una migrazione
Richiedi una migrazione del sito con Kinsta

Al momento dell’offboarding, il trasferimento del sito offre alle agenzie un percorso di passaggio di consegne pulito. Un sito può essere trasferito su un altro account Kinsta o a un utente non Kinsta, che riceverà una richiesta di creare un account. I record DNS gestiti in MyKinsta vengono trasferiti insieme al sito. I componenti aggiuntivi come Redis e Staging Premium vengono trasferiti automaticamente.

trasferire la proprietà
Trasferisci la proprietà del sito

Per le agenzie che gestiscono un numero elevato di nuovi clienti, l’API di Kinsta permette ai team di creare nuovi siti WordPress, impostare ambienti di staging e configurare gli accessi in modo automatico, eliminando i passaggi manuali nella dashboard da un processo che si ripete con ogni cliente.

5. Il problema della visibilità: l’utilizzo, i bot e i costi per i clienti diventano più difficili da spiegare

Quando l’utilizzo di un cliente inizia a salire, ma le conversioni rimangono ferme e il fatturato non cambia, l’agenzia deve spiegare un aumento dei costi senza un chiaro risultato di business che lo giustifichi.

La conversazione si complica quando il team non riesce a capire subito cosa abbia causato il picco. Una campagna potrebbe aver generato traffico reale. I crawler basati sull’intelligenza artificiale potrebbero aver scansionato gran parte del sito. Bot indesiderati potrebbero aver visitato ripetutamente le stesse pagine. Crawler di ricerca, strumenti di monitoraggio e visitatori legittimi potrebbero aver contribuito tutti contemporaneamente.

Le sfumature contano. Non tutto il traffico automatizzato è negativo. I motori di ricerca devono eseguire il crawling dei siti dei clienti. Gli strumenti di monitoraggio dell’uptime devono verificare la disponibilità. Anche alcuni strumenti di e-commerce, sicurezza e integrazione si basano su attività automatizzate. Bloccare tutte le richieste crea problemi a sé stanti. Consentire l’accesso a ogni bot per impostazione predefinita rende più difficile gestire l’utilizzo e fornire spiegazioni.

Le agenzie hanno bisogno di visibilità prima di poter dare ai clienti una risposta utile.

Protezione bot di Kinsta offre alle agenzie controlli specifici per ogni sito sul traffico automatizzato. Questo è importante perché ogni sito cliente potrebbe richiedere un approccio diverso. Un cliente potrebbe voler bloccare i crawler AI. Un altro potrebbe aver bisogno di eccezioni per strumenti di monitoraggio, integrazioni o le tipiche automazioni di WordPress.

Protezione bot include reportistica che permette ai team di vedere come il traffico automatizzato influisce sui singoli siti, invece di fare supposizioni dopo i picchi di traffico.

Grafico delle suddivisioni delle richieste
Grafico delle suddivisioni delle richieste che mostra il traffico classificato per tipo nelle ultime 24 ore.

La suddivisione della cache aggiunge un ulteriore livello di visibilità. Se il traffico aumenta ma l’efficacia della cache cala, il team può verificare se il problema deriva da richieste non memorizzate nella cache, dall’attività dei bot o da un problema di configurazione a livello di sito, invece di attribuire tutto alla crescita organica.

Suddivisione della cache
Suddivisione della cache che mostra la risoluzione delle richieste.

Quando l’utilizzo cambia, qualcuno deve spiegarlo in modo chiaro. Una maggiore visibilità aiuta il team a mettere in relazione traffico, bot, cache e costi in un modo comprensibile per i clienti. Senza quel contesto, ogni picco diventa un gioco di ipotesi.

Flussi di lavoro più solidi rendono la crescita meno fragile

La crescita di un’agenzia non sempre mette subito a dura prova l’infrastruttura di WordPress. Il più delle volte, invece, mette a dura prova i flussi di lavoro informali che un tempo tenevano tutto insieme.

Le agenzie in crescita non hanno bisogno di complessità fine a se stessa. Hanno bisogno di sistemi più chiari per il lavoro che già svolgono ogni giorno, come assegnare gli accessi, testare le modifiche, gestire gli aggiornamenti, fare l’onboarding dei clienti, trasferire la proprietà e spiegare l’utilizzo.

Se la tua agenzia sta acquisendo clienti WordPress più velocemente di quanto i tuoi flussi di lavoro riescano a stare al passo, l’hosting per agenzie di Kinsta e il Programma per Agenzie Partner sono pensati proprio per il modello operativo di cui le agenzie in crescita hanno bisogno.

Joel Olawanle Kinsta

Joel è uno Frontend developer che lavora in Kinsta come redattore tecnico. È un insegnante appassionato che ama l'open source e ha scritto oltre 200 articoli tecnici principalmente su JavaScript e i suoi framework.