Gestão de incidentes WordPress: como comunicar com clientes em situações críticas

Um site em baixo, um hack, dados perdidos — são incidentes que testam não só a competência técnica da agência, mas a relação com o cliente. A forma como se comunica durante e após um incidente é frequentemente mais determinante para a continuidade da relação do que a velocidade de resolução técnica.

O erro mais comum: comunicar apenas quando está resolvido

A reação natural de qualquer equipa técnica é focar-se em resolver o problema e só depois comunicar. "Quando estiver resolvido, explico tudo." Esta abordagem está errada por uma razão simples: o cliente está a sofrer o impacto do problema agora, e o silêncio da agência amplifica a ansiedade.

Comunicação proactiva durante o incidente, mesmo sem solução, transmite controlo e presença — que é exactamente o que o cliente precisa de sentir.

Os três tipos de incidente WordPress e como abordá-los

Tipo 1: Site em baixo (downtime)

O site está inacessível. Pode ser problema de hosting, de DNS, de plugin que causou erro fatal, ou de certificado SSL expirado.

Comunicação imediata (dentro de 15 minutos de detecção):

"Detectámos que o [nome do site] está inacessível. A nossa equipa está a investigar activamente a causa. Actualizamos em 30 minutos com diagnóstico."

Actualização com diagnóstico (30 minutos):

"A causa do downtime foi identificada: [causa]. Estamos a resolver. Estimativa de resolução: [tempo]. Continuamos a actualizar."

Comunicação de resolução:

"O [nome do site] está novamente operacional desde as [hora]. A causa foi [causa]. Implementámos [medida preventiva] para evitar recorrência. Enviamos relatório detalhado amanhã."

Tipo 2: Site comprometido (hack)

Conteúdo injectado, redireccionamentos maliciosos, ficheiros maliciosos — qualquer sinal de acesso não autorizado.

Este é o incidente mais sensível. O cliente vai perguntar "como é que isso aconteceu?" antes mesmo de "como vai ser resolvido?" A resposta honesta, sem defensividade, é essencial.

Comunicação inicial:

"Identificámos sinais de acesso não autorizado ao [nome do site]. Colocámos o site em modo de manutenção preventivamente para proteger utilizadores e dados. A nossa equipa está em recuperação activa. Actualizamos em 1 hora."

Para detalhes sobre o processo técnico de recuperação, ver o artigo sobre WordPress hackeado: guia de recuperação.

Tipo 3: Perda de dados ou funcionalidade após update

Um update quebrou funcionalidade crítica, ou um restore de backup não correu como esperado.

O que não dizer: "O plugin actualizou automaticamente." A responsabilidade é da agência — quem gere o site é responsável pelos updates, mesmo que automáticos.

O que dizer:

"Uma actualização de software causou um problema inesperado no [funcionalidade]. Assumimos total responsabilidade pela resolução. Estamos a reverter para a versão anterior e estimamos restauro em [tempo]."

Princípios de comunicação em incidentes

• Comunicar primeiro, resolver depois: a primeira mensagem deve sair antes de ter a solução. O cliente precisa de saber que estamos a trabalhar no problema.
• Actualizações regulares com hora de próxima actualização: nunca deixar o cliente em silêncio por mais de 30-60 minutos. Mesmo que não haja novidades, comunicar "ainda em diagnóstico, próxima actualização às X horas".
• Linguagem simples, sem jargão: "o servidor de base de dados ficou sem memória disponível" → "um componente técnico do servidor ficou sem recursos e causou a interrupção".
• Assumir responsabilidade sem se prostrar: reconhecer o problema, não culpar terceiros (hosting, plugin developer), focar na resolução.
• Post-mortem após resolução: 24-48 horas depois, enviar um relatório resumindo o que aconteceu, como foi resolvido, e que medidas foram implementadas para prevenir recorrência.

Template de post-mortem para o cliente

Um documento simples enviado 24h após resolução:

• O que aconteceu: descrição clara e não técnica do incidente
• Quando aconteceu: timeline do incidente e da detecção
• Qual o impacto: duração do downtime ou da degradação de serviço
• Causa raiz: o que causou o problema
• Como foi resolvido: acções tomadas
• Medidas preventivas: o que foi implementado para evitar recorrência

Este documento demonstra profissionalismo e transforma um incidente negativo numa prova de competência e transparência.