Blog
Smetti di scegliere gli host. Inizia a scegliere i pattern.
Un flusso di lavoro ripetibile che evita alla tua agenzia di dover ricercare l'hosting per ogni cliente.
Riepilogo
La frase più costosa nel lavoro di un'agenzia web è: "troviamo il miglior host per questo cliente." Smetti di dirla. Il tuo compito non è trovare il miglior host; è costruire un piccolo set di pattern di hosting che coprano la maggior parte dei clienti e riservare ricerche approfondite alle rare eccezioni. Questo articolo guida un cliente retail ipotetico attraverso un processo standardizzato: un modulo di intake con quattro campi, tre profili di hosting, una checklist di migrazione, un piano di affidabilità e un runbook di una pagina. Riceverai anche una routine di revisione trimestrale che mantiene onesta la tua lista di host. Il risultato è meno emergenze alle 3 di notte, margini migliori e clienti che si fidano di te perché nulla si è rotto. Usa questi passaggi per trasformare l'hosting da un incendio da gestire progetto per progetto in una parte ripetibile del tuo flusso di lavoro.
La frase più costosa nel lavoro di un'agenzia web è anche la più comune: "Troviamo il miglior host per questo cliente." Smetti di dirla. Il tuo compito non è trovare il miglior host. Il tuo compito è scegliere un piccolo set di pattern di hosting che funzionino per la maggior parte dei tuoi clienti, poi spendere le tue limitate energie mentali sui pochi che realmente escono dagli schemi. È così che trasformi l'hosting da un incendio per progetto in un passaggio ripetibile del tuo flusso di lavoro. Ecco il percorso, dalla prima chiamata di un nuovo cliente a un handoff di cui ti dimenticherai sei mesi dopo — perché nulla si è rotto.
Immagina un nuovo cliente: una catena retail con un sito catalogo, un blog e un negozio online. Sono stati su un host condiviso economico che va in crash il Black Friday. Ti chiedono di "sistemare l'hosting." Questo è il momento per fare ciò che la maggior parte delle agenzie non fa mai: guidarli attraverso un processo, non un panico.
Passaggio 1: Fai le domande giuste una volta
Costruisci un modulo di intake per l'hosting e fai sì che ogni cliente lo compili prima di parlare con loro. Il modulo dovrebbe contenere quattro campi: traffico mensile stimato, tipo di contenuto (statico, basato su database, e-commerce o con molti media), requisiti di conformità (PCI, HIPAA, GDPR) e aspettative di supporto — chi toccherà il sito quando qualcosa si rompe. Tutto qui. Tutto il resto è rumore.
Quando un cliente dice "abbiamo bisogno del miglior hosting," in realtà intende "abbiamo bisogno che non vada in crash durante la nostra vendita più importante." Il tuo modulo cattura questo in una riga: traffico. Si scopre che l'unica vera differenza tra la maggior parte dei clienti è la scala. Un sito brochure a basso traffico e un negozio e-commerce ad alto traffico necessitano di risorse diverse, ma non hanno bisogno di host diversi se hai già scelto il pattern giusto.
Il modulo elimina anche le conversazioni speculative. Senza di esso, riceverai infiniti "e se crescessimo?" e "dovremmo usare questo host visto su un cartellone?" Filtrali prima che inizino. Se un cliente non sa rispondere a quattro domande sul proprio sito, non è pronto per un consiglio sull'hosting; è pronto per sentirsi dire cosa fare.
Per il nostro cliente retail, il modulo rivela un sito con traffico sano ma non massiccio, un database di prodotti e zero requisiti di conformità oltre alla gestione di base delle carte di pagamento. Si aspettano che tu gestisca tutto, perché il loro ultimo host ha "perso" il ticket di supporto. Quel dettaglio conta più di qualsiasi scheda tecnica.
Passaggio 2: Standardizza su tre profili
Una volta ricevuto il modulo, abbina il cliente a un profilo. Non dovresti averne più di tre. Budget, supporto-first e performance. Questo è l'intero menu. Definiscili una volta, documentali e non rimetterli in discussione per ogni cliente.
| Profilo | Ideale per | Attenzione a |
|---|---|---|
| Budget condiviso | Siti brochure a basso traffico, budget limitato | Il supporto è scarso, lo fornisci tu |
| Gestito supporto-first | Clienti che non toccano la tecnologia, vogliono un unico numero di telefono | Costa di più, ti vincola al loro stack |
| VPS/dedicato performance | E-commerce, siti ad alto traffico e con molti database | Richiede più competenze di setup e manutenzione |
Quali host appartengono a quale profilo sono compiti tuoi, non del cliente. Un metodo che funziona: testa un host candidato per profilo con un progetto a basso rischio, poi documenta tutto — tempi di provisioning, performance, risposta del supporto, sorprese di fatturazione. La ricerca già disponibile ti dà un punto di partenza: host come Bluehost e Hostinger sono comunemente posizionati per utenti attenti al budget; SiteGround ha una reputazione di forte supporto; A2 e HostGator sono associati a opzioni orientate alla velocità. Ma non fidarti di queste descrizioni finché non hai aperto un ticket di supporto e misurato il tempo di risposta con un cronometro.
Il nostro cliente retail rientra nel profilo performance. Ha bisogno di query veloci sul database e la capacità di gestire un picco di traffico in un fine settimana intenso. La decisione viene presa in minuti, non in giorni, perché non stai "ricercando host" — stai consultando la tua matrice.
Se non l'hai ancora fatto, fermati qui e costruisci la tua matrice. Ti ringrazierai al prossimo kickoff di progetto. E se sei ancora tentato di personalizzare per cliente, leggi perché il tuo sito è andato giù e scopri come un singolo crash può far deragliare un trimestre. Poi blocca i tuoi profili. Resisti alla tentazione di aggiungere un quarto profilo "premium" per un cliente di alto profilo. Ogni profilo che aggiungi riporta la deliberazione progetto per progetto che stai cercando di eliminare. Tre è il massimo; per molte agenzie, due bastano.
Passaggio 3: Migra con una checklist, non con una preghiera
Ora stai trasferendo il cliente. Fallo sempre allo stesso modo. Ecco l'ordine: fai il backup di tutto dal vecchio host, incluso il database; provisiona il nuovo server e installa lo stesso stack software; importa file e database; installa SSL e testa ogni pagina; cambia i nameserver; verifica la consegna delle email e le integrazioni di terze parti; tieni vivo il vecchio host per un ciclo di fatturazione.
Scrivi questa lista una volta e trasformala in una checklist condivisa nel tuo strumento di project management. D'ora in poi, la persona che gestisce la migrazione non è un ingegnere senior che improvvisa; è chiunque sappia seguire una checklist. Nel caso del nostro cliente retail, il trasferimento richiede una frazione del tempo che servirebbe se decidessi ogni passaggio al momento. Quella frazione conta quando gestisci più clienti.
Due avvertenze dalle migrazioni reali. Primo, se il vecchio host gestiva le email, non dimenticare i record MX. È così che le migrazioni diventano obsolete e il cliente pensa che tu abbia rotto la sua email. Secondo, non fare mai il cambio DNS alle 17:00 di un venerdì. Fallo martedì mattina, quando hai i prossimi due giorni lavorativi per sistemare qualsiasi cosa si rompa. La meccanica di un trasferimento senza tempi di inattività è coperta in questa guida alla migrazione. Leggila prima della tua prima migrazione, poi cancellala dalla memoria — la checklist è tutto ciò di cui hai bisogno.
E fai una prova prima del passaggio definitivo. Provisiona un sottodominio di staging, copia lì il sito e testa ogni pagina. Costa un'ora e intercetta l'errore che avrebbe portato il tuo cliente offline per il pomeriggio. Quell'ora è l'assicurazione più economica che comprerai in tutto il trimestre.
Passaggio 4: Vendi affidabilità, non numeri di uptime
Ogni host nella tua lista alla fine fallirà. Quelli che pubblicizzano "uptime 100%" vendono marketing, non ingegneria. Quindi quando valuti un host, non chiedere garanzie. Chiedi della comunicazione sugli incidenti. Se un server muore, ricevi un'email di stato entro cinque minuti? C'è una pagina di stato? Pubblicano i post-mortem? Se l'host non sa rispondere in una frase, non è pronto per un cliente il cui fatturato dipende da un sito web.
Il tuo cliente non ha bisogno di una garanzia di uptime al 100%. Ha bisogno di un piano per quando il sito è giù. Costruiscilo con loro: una pagina di manutenzione, un albero telefonico, un elenco di chi chiama chi. Poi testa il piano con una esercitazione. È l'ora meno glamour che spenderai, e ti salverà dall'ora più stressante dell'anno. Il cliente retail non saprà mai dell'esercitazione questo trimestre, ma saprà di quella volta in cui il sito è rimasto su durante una vendita perché il tuo piano ha funzionato.
Questo è anche il posto per essere onesti con il cliente su cosa può rompersi. "Avremo backup giornalieri. Un servizio di riavvio di solito riporta il sito online in pochi minuti. Ma se il server fallisce completamente, un ripristino potrebbe richiedere alcune ore. Ecco il numero da chiamare." Questa onestà vale più di una falsa garanzia. Ti impedisce anche di essere quello che viene chiamato alle 3 di notte perché hai promesso l'impossibile. Porta il modello di runbook a questa conversazione e dì: "Ecco cosa faremo se il sito va giù. Riceverai subito un aggiornamento sullo stato." Poi fallo davvero.
Passaggio 5: Scrivi il runbook di una pagina
Il deliverable che rende l'hosting ripetibile tra i clienti non è l'host stesso; è la documentazione. Alla consegna, dai al tuo cliente un runbook di una pagina con: login dell'host, registrar del dominio, provider DNS, pianificazione dei backup, numero di telefono del supporto e una sezione "cosa fare se il sito va giù". Non seppellirlo in una presentazione di 30 slide. Una pagina. Ogni cliente riceve lo stesso modello. Gli unici campi che cambiano sono le credenziali e il profilo.
Per il cliente retail, il runbook è la differenza tra un ticket di supporto e una telefonata tranquilla. Quando ti chiamano a novembre chiedendo di una strana email dal loro vecchio host, puoi dire: "Ignorala, abbiamo spostato tutto. I login sono nel tuo runbook." È allora che passi da "agenzia web" a "partner di hosting che pensa in anticipo."
Il fatto di far stare tutto in una pagina ti obbliga a decidere cosa è davvero critico. Se non ci riesci, non capisci la tua stessa configurazione. Tieni il modello in un drive condiviso e aggiornalo ogni volta che la tua infrastruttura cambia. Applica il principio del minimo privilegio, ruota le credenziali e non inviare mai password via email. La tua versione interna del runbook dovrebbe essere una copia della pagina del cliente più una sezione per il tuo team: IP dei server, posizione di archiviazione dei backup e credenziali dello strumento di monitoraggio. Quella versione interna è quella che userai nella revisione trimestrale.
Passaggio 6: Revisione trimestrale, non per progetto
Imposta un evento ricorrente nel calendario per il primo lunedì di ogni trimestre. In quel giorno, estrai tre report: i ticket di supporto dell'ultimo trimestre, i dati di uptime dal tuo strumento di monitoraggio e le fatture degli host. Cerca pattern. Se un host è responsabile della maggior parte dei tuoi ticket di supporto, è fuori. Se il supporto di un altro host non risponde mai al telefono, è fuori. Se è apparso un nuovo provider con un prezzo drasticamente migliore per la stessa classe di servizio, testalo — con un cliente non critico — e aggiungilo alla matrice se se lo merita.
Questa revisione è la differenza tra reagire ai fallimenti e prevenirli. Avrai ancora fallimenti, ma saranno colpa dell'host, non del tuo processo. Quando un nuovo candidato host appare sul tuo radar, sottoponilo a un vero stress test prima di impegnarti. Un host economico può sembrare ottimo sulla carta e crollare sotto carico; il test ti dirà la verità.
La revisione trimestrale è anche il momento di potare. Se un profilo non è stato usato per due trimestri, rimuovilo o scopri perché. L'obiettivo è una matrice viva che rifletta ciò che hai realmente imparato, non un documento statico scritto una volta e ignorato. Non saltare la revisione perché sei occupato. Il tempo che ci passi ti fa risparmiare una settimana fatturabile in seguito.
Conclusione
L'hosting non è il posto per la creatività. È il posto per i pattern. Costruisci il modulo di intake, blocca i tuoi tre profili, esegui la checklist di migrazione, vendi affidabilità, scrivi il runbook di una pagina e fai revisioni trimestrali. Il cliente retail avrà un sito stabile, tu avrai un trimestre più tranquillo e finalmente smetterai di cercare su Google "miglior hosting per" ogni volta che arriva un nuovo progetto. Questa è la vittoria. Vai a standardizzare.