Cliente difícil de suporte: o que atender pessoa frustrada ensina sobre comunicação técnica
Quando a internet cai pela terceira vez no mesmo cliente, a solução técnica certa não é suficiente. O que aprendi sobre comunicar problema, causa e resolução para quem não faz ideia do que é BGP.
O cliente já estava irritado quando atendi o telefone.
Terceira vez que a internet caía naquela semana. Ele tinha perdido uma videoconferência importante. Não queria saber de explicação técnica — queria saber por que continuava acontecendo e quando ia parar de acontecer.
Eu sabia a resposta técnica. Havia instabilidade na rota upstream, problema que não estava na nossa infraestrutura local, e estava sendo tratado pelo time de NOC. Tecnicamente correto. Completamente inútil para aquela conversa.
O que aprendi nessa chamada: solução técnica e resolução do problema são coisas diferentes.
Resolver o problema técnico era parte do trabalho. Resolver a percepção do problema era a outra parte — e essa segunda parte eu não tinha treinamento nenhum.
Cliente frustrado não quer saber de sigla. Não quer saber que o problema é upstream. Quer saber três coisas: o que aconteceu, por que aconteceu com ele especificamente, e o que garante que não vai acontecer de novo.
Quando respondo "rota BGP instável no provedor upstream" estou respondendo a minha pergunta, não a dele.
Desenvolvi um padrão depois de algumas chamadas difíceis.
Primeiro: validar o impacto antes de explicar a causa. "Entendo que você perdeu a videoconferência — isso é sério e não deveria ter acontecido." Não é protocolo de atendimento. É reconhecer que o problema da pessoa é real antes de partir para diagnóstico.
Segundo: traduzir a causa sem simplificar demais. "A internet que chega até você passa por várias empresas diferentes antes de chegar. Uma dessas empresas teve instabilidade ontem à noite — e isso afetou vários clientes ao mesmo tempo, não só você." Isso responde "por que eu?" sem mentir e sem inundar de jargão.
Terceiro: comprometer com o que é possível comprometer. Se não sei quando vai ser resolvido, não digo um prazo inventado. Digo quando vou ter mais informação — e cumpro.
Anos depois, fazendo review de incidente em plataforma de software, percebi que estava aplicando o mesmo modelo.
Post-mortem que começa listando "mitigações técnicas implementadas" sem primeiro explicar o impacto para usuários não é post-mortem — é relatório interno disfarçado de comunicação. A ordem importa: impacto → causa → o que foi feito → o que garante que não repete.
Engenheiro que só sabe comunicar para outros engenheiros tem raio de ação limitado. A habilidade de traduzir problema técnico para impacto de negócio — sem perder precisão, sem inventar certezas — abre espaço em qualquer nível de senioridade.
Aprendi isso atendendo cliente irritado com internet caída. Não em treinamento de comunicação.
Essa semana: a última vez que você explicou um problema técnico para alguém não-técnico, você começou pelo impacto ou pela causa?