Gestão de escalações

Um processo de escalação é o caminho documentado que um problema de cliente percorre desde “o CSM percebeu” até “um dono responsável está resolvendo contra o relógio”. Sem ele, cada incêndio é trabalhado na velocidade de quem por acaso está no canal do Slack, e a percepção de severidade do cliente se afasta da sua. Isto é um how-to: construa as quatro peças — níveis de severidade, roteamento, cadência de comunicação e follow-up de causa raiz — nessa ordem, porque cada uma depende da anterior.

Pré-requisitos

• Uma plataforma de ticketing ou de CS que consiga guardar um campo de severidade e registrar timestamps das mudanças de estado. Zendesk, Pylon ou Gainsight servem; o campo importa mais que o tool.
• Um workspace do Slack com a capacidade de criar canais por incidente.
• Uma rotação on-call nomeada para engenharia, ou no mínimo um dono responsável por área de produto.
• Um sinal de health-score ou tier de conta para que uma atribuição de Sev possa fatorar o valor da conta, não só o impacto técnico.

Passo 1 — Defina níveis de severidade com SLAs de resposta e resolução

Severidade é uma decisão de dois eixos: impacto de negócio vezes peso da conta. Escreva a matriz uma vez e aplique mecanicamente, para que uma decisão de Sev não seja um debate às 16h numa sexta-feira.

O eixo de peso da conta é o que CS acrescenta e que o triage de suporte puro perde: um problema técnico Sev 3 numa conta em trimestre de renovação a 70% de health é um Sev 2 na prática. Codifique isso — se account_tier = strategic ou health_score < 60, suba o Sev em um. Não deixe cada CSM subir na mão; a regra faz isso.

Passo 2 — Roteie para um dono nomeado, não para uma fila

Uma fila é onde escalações vão envelhecer. Rotear significa que cada Sev tem um dono pré-acordado e um canal pré-acordado antes de o incidente existir.

1. Na atribuição do Sev, crie automaticamente um canal dedicado do Slack chamado #esc-<conta>-<data>. Canais por incidente ganham de uma única mangueira compartilhada porque o histórico fica pesquisável e o resumo voltado ao cliente é um único scroll, não uma reconstrução.
2. Convide automaticamente o dono responsável da rotação on-call, o CSM da conta e — para Sev 1/2 — o manager de CS. Para Sev 1, faça page, não @-mention: uma menção é uma notificação, um page é uma obrigação.
3. Abra um issue de tracking no Linear (ou seu tracker de engenharia) linkado ao canal, com o Sev, a conta e o relógio do SLA na descrição. O registro do lado de CS (no Gainsight ou seu CRM) linka para o mesmo issue para que o contexto de renovação e do CSM viaje junto.
4. O CSM é dono do relacionamento com o cliente o tempo todo; o dono de engenharia é dono do fix. Separar esses dois papéis explicitamente previne a falha onde o CSM fica em silêncio porque está esperando engenharia, e o cliente não escuta nada.

Passo 3 — Rode a cadência de comunicação

A ansiedade do cliente é função do silêncio, não da severidade. Um Sev 1 com um update a cada 30 minutos parece sob controle; um Sev 3 com três dias de silêncio parece Sev 1.

• Reconheça dentro do SLA de resposta com uma mensagem humana: o que você entende ser o problema, o Sev que atribuiu e quando chega o próximo update. Nomear o horário do próximo update é a jogada de maior alavancagem — converte a espera em aberto numa promessa cumprida.
• Atualize na cadência mesmo quando não há novidade. “Ainda investigando, causa raiz ainda não isolada, próximo update às 15h” é um update válido. Pular porque nada mudou é a escalação-da-escalação evitável mais comum.
• Separe a linguagem interna da externa. O canal interno pode dizer “a tempestade de retries está martelando a fila”; o cliente escuta “identificamos a causa e estamos fazendo o deploy de um fix”. Nunca cole o chatter cru de engenharia para o cliente.
• Feche explicitamente. Declare o que foi corrigido, confirme que o cliente vê resolvido e peça a confirmação dele antes de marcar como fechado. Um fechamento unilateral soa desdenhoso e frequentemente reabre.

Passo 4 — Follow-up de causa raiz

Fechar o ticket não é fechar o loop. Cada Sev 1 e Sev 2 recebe um post-mortem sem culpa dentro de cinco dias úteis.

1. Timeline. Reconstrua a partir dos timestamps do canal e do tracker: detecção, reconhecimento, mitigação, resolução. Meça tempo-para-reconhecer e tempo-para-resolver contra o SLA.
2. Cinco porquês até uma causa sistêmica. Pare na lacuna de processo ou de sistema, não na pessoa. “O CSM não viu o alerta” não é causa raiz; “os alertas roteiam para email, que o CSM não monitora durante o horário da EU” é.
3. Ações corretivas com donos e datas. Cada ação é um issue trackeado, não uma nota de reunião. Ações sem dono não existem.
4. Realimente o Passo 1. Se o mesmo Sev se repete, a matriz ou o roteamento estão errados — conserte o sistema, não a próxima instância.

Erros comuns

• Inflação de severidade. Tudo vira Sev 1, então nada é. Guarda: a matriz é a única autoridade; um override exige o nome do manager de CS no canal e uma razão de uma linha.
• Rotear para uma fila em vez de uma pessoa. Tickets envelhecem em inboxes compartilhados. Guarda: cada Sev autoatribui um dono nomeado na criação; um Sev sem dono mais velho que seu SLA de resposta faz page ao manager.
• Silêncio entre updates. Guarda: a cadência de update é forçada por um bot lembrete no canal do incidente, não pela memória do dono.
• Fechar sem causa raiz. A mesma queda se repete porque ninguém consertou o sistema. Guarda: um Sev 1/2 não pode ser marcado como “resolvido” até existir um issue de post-mortem linkado com ações corretivas e donos.
• Sem fator de peso da conta. O triage puramente técnico subprioriza um bug pequeno numa baleia que está churnando. Guarda: a regra de subir o Sev por tier e health score roda automaticamente.

Relacionados

• NRR vs GRR — o que escalações repetidas te custam em retenção
• Gainsight — health scores e contexto de conta para a regra de subir o Sev
• Pylon — tooling de suporte B2B que guarda severidade e contexto por conta
• Linear — o issue de tracking do lado de engenharia