Como comunicar downtime a clientes sem parecer amador

O site do cliente está em baixo há doze minutos. Já sabes qual é o problema, já sabes que não é teu, e já sabes que vai demorar mais meia hora. A pergunta que tens à frente não é técnica: é se escreves agora ou se esperas para escrever quando estiver resolvido. Comunicar downtime a clientes não é um problema de redacção — é um problema de momento.

Quase toda a gente espera. E é quase sempre a decisão errada.

O que decide a percepção não é a falha.

Um cliente que descobre a falha por ti, com a hora e uma explicação, arquiva o episódio como “eles estão em cima disto”. O mesmo cliente, na mesma falha, que descobre porque um funcionário dele não conseguiu abrir o site, arquiva o episódio como “eles não deram por nada”.

A falha é idêntica. A duração é idêntica. O que muda é a ordem — e a ordem é a única variável desta equação que tu controlas totalmente.

Daí a regra que vale mais do que qualquer conselho de redacção: a comunicação de um incidente começa antes de ele existir. Se souberes da falha vinte minutos depois do teu cliente, não há mensagem no mundo que recupere aqueles vinte minutos.

Comunicar downtime a clientes, em três mensagens.

Um incidente comunica-se em três momentos, e cada um tem um objectivo diferente.

1. O aviso, nos primeiros minutos.

Objectivo único: chegares primeiro. Não é para explicar, é para existir.

O site esteve inacessível a partir das 10h14. Estamos a tratar do assunto e voltamos a escrever assim que houver novidade.

Três linhas, e nenhuma delas especula sobre a causa. Nunca dês uma causa nos primeiros minutos — a primeira hipótese está errada com frequência desconfortável, e uma causa retirada depois custa mais do que a ausência dela.

Também não dês uma previsão de tempo. “Deve estar resolvido em dez minutos” é uma promessa que vais falhar em metade dos casos, e falhá-la transforma um incidente técnico num problema de credibilidade.

2. O ponto de situação, se demorar.

Se passou meia hora sem resolução, escreve outra vez mesmo sem ter novidades. Uma mensagem a dizer “continuamos sem resolução, o alojamento está a investigar” vale mais do que o silêncio, porque o silêncio lê-se como abandono.

O intervalo razoável é de trinta a sessenta minutos. Menos do que isso é ruído; mais do que isso é o cliente a escrever primeiro. Uma página de estado tira-te boa parte destas mensagens de cima: quem quer saber vai lá ver em vez de perguntar.

3. O fecho, que é a mensagem que fica.

Esta é a única que alguém vai reler, e é a que vale a pena escrever com cuidado. Leva quatro coisas, por esta ordem:

• O que aconteceu, em linguagem de pessoa. “O servidor do alojamento reiniciou e o site demorou a voltar.” Não 502 Bad Gateway.
• A janela exacta. Das 10h14 às 11h02, quarenta e oito minutos. Se tens histórico, dá o número a sério. Se não tens, diz que não tens.
• O que foi feito. Uma frase.
• O que muda daqui para a frente. Ou uma frase honesta a dizer que não muda nada, porque a causa era externa e não tens controlo sobre ela.

Os cinco erros que custam mais.

Explicar demais. Um cliente não técnico que recebe uma explicação de cinco parágrafos com termos que não conhece não fica tranquilo — fica com a sensação de que lhe estão a atirar palavras para cima. Uma frase clara vale mais.

Culpar o alojamento em todas as mensagens. É verdade em muitos casos e é péssimo em série. O cliente não distingue “o alojamento falhou” de “vocês escolheram este alojamento”. Ao terceiro incidente, a pergunta vai ser sobre a tua escolha.

Pedir desculpa em excesso. Uma desculpa curta e factual passa profissionalismo. Três parágrafos de desculpas passam culpa, e convidam a uma conversa sobre compensações que ninguém tinha começado.

Comunicar só as falhas grandes. Se comunicas as de uma hora e escondes as de oito minutos, estás a ensinar o cliente a desconfiar da tua definição de “grande”. Ou comunicas todas acima de um limiar que combinaste com ele, ou o critério é teu e imprevisível.

Mandar a captura de ecrã do painel. Um gráfico com um vale vermelho não é comunicação, é matéria-prima. Se o cliente tem de interpretar, não comunicaste.

Combina o limiar antes de precisares dele.

A melhor conversa sobre comunicação de incidentes é a que acontece no início da relação, quando não há nenhuma falha em cima da mesa. Três perguntas resolvem-na:

1. A partir de quantos minutos avisamos? Cinco é ruído para a maioria dos sites institucionais; quinze é um número que quase toda a gente aceita. Numa loja online em campanha, dois.
2. Por onde avisamos? Email chega tarde. Uma mensagem no telemóvel de uma pessoa nomeada chega quando é preciso.
3. Quem é essa pessoa? Ter nome é metade do trabalho feito. Avisar geral@cliente.pt é avisar ninguém.

Isto escrito num parágrafo do contrato de manutenção poupa toda a discussão que viria a seguir ao primeiro incidente a sério.

Onde é que isto encalha na prática.

Encalha no primeiro passo, e vale a pena ser directo sobre isso: nada disto funciona se souberes da falha depois do cliente. Comunicar downtime a clientes pressupõe um aviso automático a chegar-te ao telemóvel dentro de poucos minutos, e a maior parte das agências não tem — tem uma ferramenta gratuita que verifica de cinco em cinco minutos e manda email para uma caixa partilhada.

Também não resolve tudo. Uma comunicação impecável não compensa três incidentes por mês: a partir de certa frequência, o problema deixa de ser comunicação e passa a ser alojamento. E há clientes que vão ficar chateados de qualquer forma — a comunicação reduz o dano, não o elimina.

A De Olho está a ser construída à volta desta ordem: verificação ao minuto, confirmação antes de disparar para o alerta não perder o significado, e o aviso no canal que já tens aberto. Abre em 2026, e quem entrar na lista de espera sabe primeiro.