Blog
Pare de escolher hosts. Comece a escolher padrões.
Um fluxo de trabalho repetível que poupa sua agência de pesquisar hospedagem novamente para cada cliente.
Resumo
A frase mais cara no trabalho de uma agência web é 'vamos encontrar o melhor host para este cliente.' Pare de dizê-la. Seu trabalho não é encontrar o melhor host; é construir um pequeno conjunto de padrões de hospedagem que cubra a maioria dos clientes e reserve a pesquisa fresca para as exceções raras. Este artigo conduz um cliente hipotético de varejo por um processo padronizado: um formulário de captação com quatro campos, três perfis de hospedagem, um checklist de migração, um plano de confiabilidade e um runbook de uma página. Você também receberá uma rotina de revisão trimestral que mantém sua lista de hosts honesta. O resultado são menos emergências às 3 da manhã, melhores margens e clientes que confiam em você porque nada quebrou. Use essas etapas para transformar a hospedagem de um incêndio por projeto em uma parte repetível do seu fluxo de trabalho.
A frase mais cara no trabalho de uma agência web também é a mais comum: "Vamos encontrar o melhor host para este cliente." Pare de dizê-la. Seu trabalho não é encontrar o melhor host. Seu trabalho é escolher um pequeno conjunto de padrões de hospedagem que funcione para a maioria dos seus clientes e gastar sua limitada capacidade cerebral nos poucos que realmente fogem desses padrões. É assim que você transforma a hospedagem de um incêndio por projeto em uma etapa repetível do seu fluxo de trabalho. Aqui está o passo a passo, desde a primeira ligação de um novo cliente até uma entrega que você esquecerá seis meses depois — porque nada quebrou.
Imagine um novo cliente: uma rede de varejo com um site de catálogo, um blog e uma loja online. Eles estavam em um host compartilhado barato que trava na Black Friday. Eles pedem que você "conserte a hospedagem." Este é o seu momento para fazer o que a maioria das agências nunca faz: conduzi-los por um processo, não por um pânico.
Passo 1: Faça as perguntas certas uma vez
Crie um formulário de captação de hospedagem e faça todos os clientes responderem antes de falar com eles. O formulário deve conter quatro campos: tráfego mensal estimado, tipo de conteúdo (estático, baseado em banco de dados, e-commerce ou com muitos arquivos de mídia), requisitos de conformidade (PCI, HIPAA, GDPR) e expectativas de suporte — quem vai mexer no site quando algo quebrar. Só isso. Todo o resto é ruído.
Quando um cliente diz "precisamos da melhor hospedagem", o que ele realmente quer dizer é "precisamos que não trave durante nossa maior promoção." Seu formulário captura isso em uma linha: tráfego. Acontece que a única diferença real entre a maioria dos clientes é escala. Um site institucional de baixo tráfego e uma loja de e-commerce de alto tráfego precisam de recursos diferentes, mas não precisam de hosts diferentes se você já escolheu o padrão certo.
O formulário também elimina conversas especulativas. Sem ele, você terá infinitos "e se crescermos?" e "devemos usar aquele host que vimos num outdoor?" Filtre-os antes que comecem. Se um cliente não consegue responder quatro perguntas sobre o próprio site, ele não está pronto para conselhos de hospedagem; ele está pronto para que lhe digam o que fazer.
Para nosso cliente de varejo, o formulário revela um site com tráfego saudável, mas não massivo, um banco de dados de produtos e zero requisitos de conformidade além do manuseio básico de cartões de pagamento. Eles esperam que você gerencie tudo, porque o último host "perdeu" o ticket de suporte deles. Esse último detalhe importa mais do que qualquer especificação.
Passo 2: Padronize três perfis
Assim que o formulário for preenchido, associe o cliente a um perfil. Você não deve ter mais que três. Orçamento, suporte primeiro e performance. Esse é o menu completo. Defina-os uma vez, documente-os e não os reabra para cada cliente.
| Perfil | Melhor para | Cuidado |
|---|---|---|
| Compartilhado econômico | Sites institucionais de baixo tráfego, orçamento apertado | O suporte é fraco, você fornece |
| Gerenciado com suporte primeiro | Clientes que não querem mexer em tecnologia, querem um único telefone | Custa mais, prende você à stack deles |
| VPS/dedicado de performance | E-commerce, alto tráfego, sites pesados em banco de dados | Exige mais habilidade de configuração e manutenção |
Quais hosts pertencem a cada perfil é sua tarefa, não do cliente. Um método que funciona: teste um host candidato por perfil com um projeto de baixo risco e documente tudo — tempo de provisionamento, performance, resposta do suporte, surpresas na cobrança. A pesquisa já disponível para você dá um ponto de partida: hosts como Bluehost e Hostinger são comumente posicionados para usuários preocupados com orçamento; SiteGround tem reputação de suporte forte; A2 e HostGator são associados a opções focadas em velocidade. Mas não confie nessas descrições até você abrir um ticket de suporte e medir o tempo de resposta com um cronômetro.
Nosso cliente de varejo cai no perfil de performance. Ele precisa de consultas rápidas ao banco de dados e capacidade de lidar com um pico de tráfego em um fim de semana movimentado. A decisão é tomada em minutos, não em dias, porque você não está "pesquisando hosts" — você está consultando sua própria matriz.
Se você ainda não fez isso, pare aqui e construa sua matriz. Você vai se agradecer no próximo kickoff de projeto. E se ainda estiver tentado a personalizar por cliente, leia por que seu site caiu e veja como uma queda pode atrapalhar um trimestre. Depois, fixe seus perfis. Resista à vontade de adicionar um quarto perfil "premium" para um cliente de alto nível. Cada perfil que você adiciona traz de volta a deliberação por projeto que você está tentando eliminar. Três é o teto; para muitas agências, dois é suficiente.
Passo 3: Migre com um checklist, não com uma oração
Agora você está movendo o cliente. Faça isso do mesmo jeito toda vez. Aqui está a ordem: faça backup de tudo do host antigo, incluindo o banco de dados; provisione o novo servidor e instale a mesma pilha de software; importe arquivos e banco de dados; instale SSL e teste todas as páginas; troque os nameservers; verifique a entrega de e-mails e integrações de terceiros; mantenha o host antigo ativo por um ciclo de cobrança.
Escreva essa lista uma vez e transforme-a em um checklist compartilhado na sua ferramenta de gerenciamento de projetos. A partir de agora, a pessoa que conduz a migração não é um engenheiro sênior improvisando; é qualquer pessoa que consiga seguir um checklist. No caso do nosso cliente de varejo, a mudança leva uma fração do tempo que levaria se você decidisse cada etapa pelo caminho. Essa fração importa quando você está conciliando vários clientes.
Dois avisos de migrações reais. Primeiro, se o host antigo lidava com e-mail, não esqueça os registros MX. É assim que as migrações ficam obsoletas e é por isso que o cliente acha que você quebrou o e-mail dele. Segundo, nunca faça a mudança de DNS às 17h de uma sexta-feira. Faça na terça-feira de manhã, quando você tem os próximos dois dias úteis para corrigir o que quebrar. Os detalhes de uma mudança sem tempo de inatividade estão cobertos em este guia de migração. Leia-o antes da sua primeira migração, depois apague-o da memória — o checklist é tudo o que você precisa agora.
E faça um ensaio antes da mudança real. Provisione um subdomínio de staging, copie o site para lá e teste todas as páginas. Custa uma hora e detecta o erro que tiraria o site do cliente do ar por uma tarde. Essa hora é o seguro mais barato que você vai comprar no trimestre.
Passo 4: Venda confiabilidade, não números de uptime
Todo host da sua lista vai falhar eventualmente. Os que anunciam "100% de uptime" estão vendendo marketing, não engenharia. Então, ao avaliar um host, não pergunte sobre garantias. Pergunte sobre comunicação de incidentes. Se um servidor morrer, você recebe um e-mail de status em cinco minutos? Existe uma página de status? Eles publicam post-mortems? Se o host não consegue responder a isso em uma frase, ele não está pronto para um cliente cuja receita depende de um site.
Seu cliente não precisa de uma garantia de 100% de uptime. Ele precisa de um plano para quando o site estiver fora do ar. Construa com ele: uma página de manutenção, um esquema de ligações, uma lista de quem liga para quem. Depois teste o plano com um treinamento. É a hora menos glamorosa que você vai gastar, e vai te poupar da hora mais estressante do ano. O cliente de varejo nunca saberá sobre o treinamento neste trimestre, mas saberá da vez que o site ficou no ar durante uma promoção porque seu plano funcionou.
Este também é o lugar para ser honesto com o cliente sobre o que pode quebrar. "Teremos backups diários. Um serviço de reinicialização geralmente traz o site de volta em minutos. Mas se o servidor falhar completamente, uma restauração pode levar algumas horas. Aqui está o número para ligar." Essa honestidade vale mais do que uma garantia falsa. Também impede que você seja o único a receber a ligação às 3 da manhã porque prometeu o impossível. Leve o modelo do runbook para essa conversa e diga: "Aqui está o que faremos se o site cair. Você receberá uma atualização de status imediatamente." Então faça isso de verdade.
Passo 5: Escreva o runbook de uma página
O entregável que torna a hospedagem repetível entre clientes não é o host em si; é a documentação. Na entrega, dê ao seu cliente um runbook de uma página com: login do host, registrador de domínio, provedor de DNS, agendamento de backups, telefone de suporte e uma seção "o que fazer se o site ficar fora do ar". Não enterre isso em uma apresentação de 30 slides. Uma página. Todo cliente recebe o mesmo modelo. Os únicos campos que mudam são as credenciais e o perfil.
Para o cliente de varejo, o runbook é a diferença entre um ticket de suporte e uma ligação calma. Quando ele ligar em novembro perguntando sobre um e-mail estranho do host antigo, você pode dizer: "Ignore, mudamos tudo. Os logins estão no seu runbook." É quando você se forma de "agência web" para "parceiro de hospedagem que pensa à frente".
O ato de encaixar tudo em uma página força você a decidir o que é realmente crítico. Se você não consegue encaixar, você não entende sua própria configuração. Mantenha o modelo em um drive compartilhado e atualize-o sempre que sua infraestrutura mudar. Aplique o princípio do menor privilégio, rotacione credenciais e nunca envie senhas por e-mail. Sua versão interna do runbook deve ser uma cópia da página do cliente mais uma seção para seu time: IPs de servidor, local de armazenamento de backup e credenciais da ferramenta de monitoramento. Essa versão interna é a que você usará na revisão trimestral.
Passo 6: Revise trimestralmente, não por projeto
Defina um evento de calendário recorrente para a primeira segunda-feira de cada trimestre. Nesse dia, puxe três relatórios: os tickets de suporte do último trimestre, os dados de uptime da sua ferramenta de monitoramento e suas contas de host. Procure padrões. Se um host é responsável pela maioria dos seus tickets de suporte, ele está fora. Se o suporte de outro host nunca atende o telefone, ele está fora. Se um novo provedor apareceu com um preço dramaticamente melhor para a mesma classe de serviço, teste-o — com um cliente não crítico — e adicione-o à matriz se ele merecer seu lugar.
Essa revisão é a diferença entre reagir a falhas e preveni-las. Você ainda terá falhas, mas elas serão culpa do host, não do seu processo. Quando um novo candidato a host aparecer no seu radar, submeta-o a um teste de estresse real antes de se comprometer. Um host barato pode parecer ótimo no papel e desmoronar sob carga; o teste vai lhe dizer a verdade.
A revisão trimestral também é o momento de podar. Se um perfil não foi usado em dois trimestres, remova-o ou descubra o porquê. O objetivo é uma matriz viva que reflita o que você realmente aprendeu, não um documento estático que você escreveu uma vez e ignorou. Não pule a revisão porque está ocupado. O tempo que você gasta lá economiza uma semana faturável depois.
Conclusão
Hospedagem não é lugar para criatividade. É lugar para padrões. Construa o formulário de captação, fixe seus três perfis, execute o checklist de migração, venda confiabilidade, escreva o runbook de uma página e revise trimestralmente. O cliente de varejo terá um site estável, você terá um trimestre mais calmo e finalmente vai parar de pesquisar "melhor hospedagem para" toda vez que um novo projeto chegar. Essa é a vitória. Vá padronizar.