Exemplo de análise de causa raiz em TI: o chamado #2685787, o gap de 29 dias e o relatório que mudou a conversa com o gestor

O antes: um chamado que ninguém queria reabrir

Todo time de suporte tem um chamado assim. O #2685787 era o nosso exemplo. Um histórico longo de interações empilhadas, idas e vindas, anexos, um cliente que começou educado e terminou desgastado. E, no meio do encadeamento, um buraco: quatro semanas — aproximadamente 29 dias — em que a coisa simplesmente ficou parada.

Na reunião com o gestor, a pergunta era sempre a mesma: ‘o que aconteceu nesse chamado?’. A resposta honesta era ‘preciso reler tudo para te dizer com precisão’. Reler tudo significava abrir o histórico inteiro, reconstruir a ordem dos fatos e tentar lembrar de quem dependia o quê. Uma tarde de trabalho para responder a uma pergunta de trinta segundos.

O problema não era falta de competência. Era falta de tempo e de uma visão organizada do que já tinha sido dito. O contexto existia — estava todo lá no Znuny —, só que disperso demais para virar conversa.

• Histórico longo de interações que ninguém releria por vontade própria.
• Um gap de ~29 dias escondido no meio do encadeamento.
• Cliente desgastado e um gestor pedindo uma explicação clara.
• O custo real: o tempo de reler vs. o tempo de decidir.

O gatilho: pedir o relatório de causa-raiz do chamado

Em vez de reabrir o histórico na mão, abrimos o chamado #2685787 e acionamos o Relatório de Causa-Raiz — o módulo de RCA do Copilot da Service Up dentro do próprio Znuny. O motor por trás é o DeepSeek (deepseek-chat); a operação, do ponto de vista do analista, é um clique.

O Copilot leu o encadeamento completo de uma vez — todas as interações, na ordem em que aconteceram — e devolveu um PDF estruturado em oito seções: resumo executivo, linha do tempo, análise de gaps e causa raiz, análise de sentimento, status técnico, recomendações, métricas e conclusão.

O que levaria uma tarde de leitura saiu pronto rapidamente. E, mais importante que a velocidade: saiu organizado. Não era um resumo solto — era um documento que dava para colocar na mesa e discutir.

• Acionado de dentro do Znuny, no próprio chamado, sem trocar de ferramenta.
• Leitura do encadeamento inteiro em uma passada, não interação por interação.
• Saída em PDF com 8 seções padronizadas — o mesmo formato para qualquer chamado.

O que a IA enxergou: o gap de 29 dias com nome e lugar

A seção que mudou tudo foi a linha do tempo cruzada com a análise de gaps. O Copilot não disse apenas ‘o chamado demorou’. Ele apontou a janela específica: entre uma resposta e a próxima interação efetiva, havia um intervalo de cerca de 29 dias. Com data de início, data de fim e o que estava (e não estava) acontecendo nesse meio.

Esse é o coração de um bom exemplo de análise de causa raiz em TI: não é apontar culpado, é localizar o ponto onde o fluxo parou. A causa raiz proposta pela IA não foi ‘o analista X errou’; foi a evidência objetiva de uma janela de espera não tratada — algo que vira melhoria de processo, não bronca individual.

A análise de sentimento confirmou o que a gente sentia mas não conseguia provar: o tom do cliente azedou ao longo do encadeamento. Agora isso estava escrito, com base no texto real das mensagens, e não na memória de quem atendeu.

• Linha do tempo com o gap de ~29 dias datado e posicionado no encadeamento.
• Causa raiz formulada como problema de fluxo, não como erro pessoal.
• Sentimento do cliente medido a partir do texto real, virando evidência.
• Recomendações práticas para não repetir a janela de silêncio.

O depois: a conversa com o gestor mudou de assunto

Na reunião seguinte, a dinâmica foi outra. Em vez de ‘me explica de novo o que houve no #2685787’, o gestor leu o resumo executivo, olhou a linha do tempo e foi direto ao ponto: ‘entendi o gap, e o que a gente muda para isso não acontecer de novo?’.

Essa é a virada que o estudo de caso quer mostrar. O relatório não economizou só o tempo de reler — ele subiu o nível da conversa. Saímos da arqueologia (‘o que aconteceu?’) para a decisão (‘o que fazemos a respeito?’). A evidência já estava posta; sobrou energia para o que importa.

E vale o lembrete de sempre: a IA não decidiu nada. Ela acelerou a leitura e organizou a evidência. Quem decidiu o ajuste de processo, quem falou com o cliente e quem assumiu a ação foi gente. A IA acelera; o humano decide.

• De ‘me explica o que houve’ para ‘o que a gente muda’.
• O resumo executivo como abertura da reunião, não o chamado cru.
• Decisão de processo tomada por pessoas, com a evidência pronta na mão.

Por que isso escala além de um chamado

O #2685787 é um exemplo, não uma exceção. O mesmo Copilot que gerou esse relatório por chamado também monta o painel agregado: os chamados de um período agrupados por serviço vinculado, cada um com a causa raiz da IA como detalhe. É o pulo do gato para sair do caso isolado e ver o padrão.

Nos últimos 30 dias da operação real, foram 974 chamados, 647 analisados (66% de cobertura) distribuídos em 85 serviços. A cobertura de RCA está em 84% e a de sentimento em 88%. O processamento roda sob demanda (‘Processar agora’) ou em lote pelo console (Maint::AICopilot::RCAScan).

Quando um gap de 29 dias deixa de ser uma surpresa num chamado e vira uma métrica que você acompanha entre serviços, a análise de causa raiz deixa de ser autópsia e começa a virar prevenção.

• Painel agregado: chamados por serviço vinculado + causa raiz da IA.
• 30 dias reais: 974 chamados, 647 analisados, 66% de cobertura, 85 serviços.
• Cobertura RCA 84% e sentimento 88%, com processamento sob demanda ou em lote.
• Do caso isolado ao padrão: causa raiz como sinal de prevenção.

O que aprendemos com o #2685787

A lição não é ‘a IA leu mais rápido’. É que o gargalo de um time de suporte raramente é falta de informação — é falta de tempo para transformar histórico bruto em algo discutível. O contexto do #2685787 sempre esteve no Znuny. Faltava quem o lesse e organizasse antes da reunião.

O Relatório de Causa-Raiz fechou exatamente esse buraco: pegou o que a mão levaria uma tarde e entregou rápido, no formato em que o gestor consegue agir. E fez isso sem tirar a decisão das mãos de quem entende do cliente.

Se você tem um ‘#2685787’ na sua fila — e todo mundo tem —, esse é o tipo de chamado que vira o melhor argumento para mostrar o módulo funcionando de verdade.

• O gargalo é tempo de organizar, não falta de dado.
• RCA transforma histórico bruto em conversa de decisão.
• Todo time tem um chamado-exemplo esperando para virar prova.