Como fazer análise de causa raiz de chamado: meça o gap de resposta, não só o sintoma

O problema: seu RCA está descrevendo o sintoma

Pegue qualquer relatório de causa raiz de chamado que você já leu. Provavelmente ele diz algo como: ‘o chamado foi aberto, passou pela triagem, foi escalado para o N2, recebeu uma solução e foi fechado’. Tudo verdade. E tudo inútil para melhorar o processo.

Isso é a descrição do QUE aconteceu — a cadeia de eventos. É o sintoma. Um chamado que demorou 30 dias para fechar com essa narrativa parece ter seguido o fluxo certo, só que devagar. Mas ‘devagar’ não é uma causa raiz. É um efeito.

O erro estrutural é olhar para os eventos (as caixinhas da linha do tempo) em vez de olhar para os espaços entre eles. A causa raiz de um chamado lento quase nunca está em quanto tempo a equipe levou para AGIR. Está em quanto tempo o chamado ficou parado SEM ninguém agir.

• RCA do sintoma: ‘levou 30 dias para resolver’ → conclusão genérica ‘precisamos ser mais rápidos’.
• RCA da causa: ‘ficou 29 dias parado entre a triagem e a primeira resposta técnica’ → conclusão acionável ‘a fila X não tem dono nas primeiras 48h’.
• O primeiro vira um slide. O segundo vira um SLA, uma regra de roteamento ou um alerta.

O que é o ‘gap de resposta’ (e por que ninguém mede)

Gap de resposta é o intervalo de silêncio entre dois eventos de um chamado: o tempo em que nada foi registrado, ninguém respondeu e o chamado simplesmente esperou. É o oposto do tempo de trabalho — é o tempo de espera.

Ninguém mede porque os relatórios padrão somam durações de etapas, não os vazios entre elas. O sistema sabe quando o N2 pegou o chamado e quando devolveu a solução; ele raramente destaca os 29 dias em que o chamado ficou na fila antes de alguém olhar. Esse vazio não tem um ‘responsável’ óbvio, então some do radar.

E é justamente aí que mora a melhoria. Otimizar o evento (a equipe resolver em 8 minutos em vez de 12) tem ganho marginal. Eliminar o gap (o chamado não dormir 29 dias antes de alguém pegar) tem ganho de ordem de grandeza.

• Gaps típicos: espera de triagem, espera de aprovação, espera de retorno do cliente, chamado ‘esquecido’ numa fila sem dono, reabertura silenciosa.
• Cada gap tem um culpado de processo diferente — e cada um pede uma correção diferente. Por isso medir ‘o tempo total’ não ajuda: ele mistura todos os gaps num número só.
• A pergunta certa não é ‘quanto demorou?’. É ‘onde, exatamente, ele travou?’.

Exemplo: a linha do tempo do chamado #2685787

Considere um caso real do módulo. O tempo total de resolução chamava atenção, mas o número sozinho não dizia nada. A análise de gaps reconstruiu a linha do tempo e isolou onde o tempo realmente foi embora.

Repare na coluna ‘gap’: a solução técnica em si foi rápida. O que destruiu o SLA foi um único intervalo de silêncio de cerca de 29 dias entre a triagem e a primeira ação técnica. Esse é o gap de resposta. Tudo o resto é ruído.

• Dia 0 — Abertura: chamado criado e classificado. Gap até o próximo evento: ~0.
• Dia 0 — Triagem: roteado para a fila técnica. Gap até o próximo evento: ~29 dias (← AQUI está a causa raiz).
• Dia 29 — Primeira resposta técnica: alguém finalmente pega o chamado. Gap: minutos.
• Dia 29 — Solução e fechamento: resolvido. Gap: ~0.
• Diagnóstico do sintoma: ‘chamado de 29 dias’. Diagnóstico da causa: ‘a fila técnica não tinha dono nem alerta de chamado parado — ficou 29 dias invisível’.

Como fazer análise de causa raiz de chamado pela ótica dos gaps

Aqui está o método prático de como fazer análise de causa raiz de chamado, independente da ferramenta. Ele troca a pergunta ‘o que aconteceu?’ por ‘onde travou?’. É esse giro que separa um relatório descritivo de um RCA acionável.

O segredo é tratar o silêncio como dado, não como ausência de dado. Um chamado parado por 29 dias não é ‘falta de informação’ — é a informação mais importante do chamado.

• 1. Reconstrua a linha do tempo evento a evento (abertura, triagem, escalações, respostas, esperas por cliente, fechamento, reaberturas).
• 2. Marque cada transição com timestamp e calcule o gap entre uma e a próxima.
• 3. Ordene os gaps do maior para o menor. O maior gap é seu suspeito número um — não o evento mais demorado.
• 4. Classifique cada gap por TIPO de espera (triagem, aprovação, cliente, fila sem dono). O tipo aponta para a correção.
• 5. Generalize: o mesmo tipo de gap se repete em vários chamados do mesmo serviço? Então não é um caso isolado, é um defeito de processo.
• 6. Só então escreva a causa raiz — uma frase que aponta o gap e o porquê dele, não a duração total.

De um chamado para o serviço inteiro: a visão agregada

Um gap em um chamado é um incidente. O mesmo gap repetido em dezenas de chamados do mesmo serviço é um diagnóstico organizacional. É por isso que a análise de causa raiz não pode parar no chamado individual.

No painel agregado da Service Up, os chamados do período são agrupados por serviço vinculado, com a causa raiz da IA como detalhe de cada grupo. Aí os padrões aparecem: um serviço cujos chamados sistematicamente travam na aprovação, outro cujos gaps estão sempre no retorno do cliente. Cada padrão é uma alavanca de melhoria diferente.

Os números do período tornam isso concreto: 974 chamados, 647 analisados (66% de cobertura), distribuídos por 85 serviços. Sinais úteis aparecem de imediato — 182 chamados sem serviço vinculado (um gap de cadastro, não de atendimento) e ‘Consultoria::Dúvida’ como serviço de maior volume (142). Cada agrupamento é uma hipótese de causa raiz esperando ser confirmada.

• Por chamado: onde ESTE travou.
• Por serviço: onde a CATEGORIA inteira costuma travar.
• Sem serviço vinculado (182 chamados): um gap antes do gap — falta de vínculo que cega a análise agregada.

Onde a Service Up entra: o Relatório de Causa-Raiz

Tudo isso é trabalho manual demorado se feito chamado a chamado. O Relatório de Causa-Raiz é o módulo do AI Copilot da Service Up, dentro do Znuny, que automatiza exatamente esse método. Ele lê o chamado, reconstrói a linha do tempo, mede os gaps e escreve a causa raiz — usando o motor DeepSeek (deepseek-chat).

Por chamado, ele gera um PDF completo com 8 seções: resumo executivo, linha do tempo, análise de gaps + causa raiz, sentimento, status técnico, recomendações, métricas e conclusão. A seção de gaps é o coração — é ela que expõe o intervalo de 29 dias do #2685787 em vez de só dizer ‘demorou’.

O processamento roda sob demanda (‘Processar agora’) ou em lote pelo console (bin/znuny.Console.pl Maint::AICopilot::RCAScan). E vale a tese de sempre: a IA não substitui o analista. Ela acelera a reconstrução e a leitura dos gaps; o humano decide o que fazer com eles. A IA acelera; o humano decide.

• 8 seções no PDF por chamado — gaps + causa raiz no centro.
• Painel agregado por serviço com a causa raiz da IA como detalhe.
• Motor DeepSeek; execução via ‘Processar agora’ ou Maint::AICopilot::RCAScan no console.
• É um módulo DA Service Up (parceira Znuny/OTOBO). Quer ver no seu Znuny? Fale com a gente.