Um serviço de manutenção WordPress sem SLA documentado é uma fonte de conflitos à espera de acontecer. O cliente não sabe o que está a pagar, a agência não sabe onde começa e termina a sua responsabilidade, e quando algo corre mal — e eventualmente algo corre mal — não há base objetiva para avaliar se o serviço foi cumprido. Um SLA bem construído protege todas as partes e é, em simultâneo, uma ferramenta de venda poderosa.
O que é um SLA e porque é importante para agências de manutenção WordPress
SLA — Service Level Agreement — é um acordo formal que define os níveis de serviço comprometidos entre prestador e cliente. No contexto de manutenção WordPress para agências, um SLA responde a perguntas como: quanto tempo demora a resposta quando algo falha? Com que frequência são feitas as atualizações? O que acontece se o site ficar em baixo às 23h de sexta-feira?
Para as agências que prestam manutenção WordPress, um SLA serve três funções críticas:
- Protege a agência. Define o âmbito exato do serviço, evitando que o cliente peça o que não está incluído e que a agência acabe por prestar trabalho não faturado por falta de clareza contratual.
- Define expectativas realistas. Um cliente que sabe que a resolução de incidentes não críticos pode demorar até 24 horas não vai ligar às 2h da manhã a exigir resolução imediata para um problema de formatação de texto.
- É a base para preços e renovações. SLAs mais exigentes justificam preços mais elevados. Na renovação anual, o SLA é a prova tangível do valor entregue.
Métricas chave para definir num SLA de manutenção WordPress
Uptime guarantee
A disponibilidade do site, expressa em percentagem mensal. 99.9% de uptime significa no máximo ~43 minutos de downtime por mês. 99.5% permite ~3,6 horas. É importante ser honesto: a agência apenas pode garantir o que controla. Se o hosting é do cliente e a agência não tem SLA com o provider, garantir uptime é arriscado. Neste caso, a formulação correta é "monitorizamos e atuamos em X minutos após detetar downtime".
Tempo de resposta a incidentes
Quanto tempo demora até um técnico começar a trabalhar no problema após o incidente ser reportado ou detetado. Diferente do tempo de resolução — resposta é o primeiro contacto ou início de ação.
Janela de execução de updates
Quando são feitas as atualizações de plugins, temas e core. Definir uma janela previsível (por exemplo, "entre o 1.º e o 5.º dia útil de cada mês") permite ao cliente saber quando esperar atividade no site e evita surpresas.
Frequência de relatórios
Com que periodicidade o cliente recebe informação sobre o estado do site. O standard do mercado é mensal, com um relatório que detalha atividade, métricas e incidentes.
Tempo de resolução por severidade
O compromisso mais exigente de qualquer SLA. Quanto tempo demora a resolver um problema após a sua deteção, dependendo da sua gravidade.
Definir níveis de severidade
Um sistema de severidades bem definido é o coração de qualquer SLA de suporte técnico. Modelo recomendado para manutenção WordPress:
| Prioridade | Definição | Tempo de resposta | Tempo de resolução |
|---|---|---|---|
| P1 — Crítico | Site completamente em baixo, site hackeado/comprometido, perda de dados ativa | 1 hora | 4 horas |
| P2 — Alto | Funcionalidade crítica falha (checkout, formulários, login), degradação grave de performance | 4 horas | 8 horas (dia útil) |
| P3 — Médio | Degradação de performance não crítica, funcionalidade secundária falha, problema visual significativo | 24 horas | 3 dias úteis |
| P4 — Baixo | Melhoria não urgente, ajuste cosmético, questão de configuração sem impacto operacional | 48 horas | Próxima janela de manutenção |
Uma nota importante: para P1 e P2, é crítico especificar se os SLAs se aplicam 24/7 ou apenas em horário de trabalho. A cobertura fora de horário tem um custo real — quer seja em recursos humanos internos, quer seja através de um parceiro como a Vuvo que oferece suporte urgente fora de horas.
Como comunicar a classificação ao cliente
É a agência, não o cliente, que classifica a severidade. Se o cliente puder classificar qualquer problema como P1, todos os problemas serão P1. O SLA deve deixar claro que a classificação segue a definição acordada, não a perceção subjetiva do cliente naquele momento.
O que NUNCA incluir num SLA de manutenção
Um SLA mal redigido pode comprometer a agência ao incluir, implicitamente, responsabilidades que não foram consideradas no preço. Excluir explicitamente:
- Trabalho de desenvolvimento ou design. Adicionar novas funcionalidades, redesenhar páginas, criar conteúdo — nada disto é manutenção. Se o cliente pede, é um projeto separado com orçamento separado.
- Alterações de conteúdo. Atualizar textos, trocar imagens, publicar artigos de blog — a não ser que o plano inclua especificamente um pacote de horas de suporte editorial.
- Suporte ao utilizador final do cliente. A agência presta suporte técnico ao cliente (a empresa), não aos clientes do cliente (os utilizadores do site). Responder a questões de utilizadores finais sobre como usar o site não é manutenção WordPress.
- Problemas originados em serviços de terceiros. Se o gateway de pagamento estiver em baixo, se o serviço de email marketing tiver problemas, se uma API externa estiver a falhar — a agência pode diagnosticar e comunicar, mas não pode resolver. O SLA deve refletir isto.
- Alterações no hosting não gerido pela agência. Se o cliente gere o próprio servidor e faz alterações de configuração, as consequências não podem ser responsabilidade da agência.
Como comunicar o SLA ao cliente
Momento ideal: integrar no contrato inicial
O SLA deve ser apresentado e assinado antes de o serviço de manutenção começar, idealmente como anexo ao contrato de serviços. Introduzir um SLA a um cliente que já está a receber manutenção "informalmente" é mais difícil — o cliente pode interpretar como tentativa de reduzir responsabilidades.
Revisão anual
O SLA deve ser revisto anualmente. As necessidades do cliente evoluem, o stack técnico do site muda, e o mercado de manutenção WordPress evolui. Uma revisão anual é também uma oportunidade de upsell — um cliente cujo site cresceu pode precisar de um nível de serviço superior.
Linguagem não técnica
O SLA é um documento para o cliente ler e compreender, não para impressionar com terminologia técnica. Substituir "MTTR inferior a 4 horas para incidentes de severidade crítica" por "se o seu site ficar completamente em baixo, começamos a trabalhar na resolução em menos de 1 hora e comprometemo-nos a tê-lo operacional em 4 horas". O significado é idêntico; a compreensão é muito diferente.
O serviço white-label da Vuvo inclui modelos de SLA adaptáveis que as agências podem usar com os seus próprios clientes, com os tempos de resposta que a Vuvo garante como subcontratante técnico.
Quer um parceiro técnico que garanta os seus SLAs?
O nosso serviço white-label permite que a sua agência ofereça SLAs exigentes aos clientes, com a Vuvo como suporte técnico em background.
Conhecer serviço white-label