Do incidente ao board: como um único chamado vira um relatório de incidente para diretoria que o C-level lê e decide

O problema: o board não fala a língua do help desk

Toda diretoria já recebeu aquele e-mail: “segue o histórico do chamado para análise”. Anexo: uma thread longa, e-mails encaminhados, prints, jargão técnico, horários, mudanças de status. Ninguém no board vai ler isso por inteiro — e, se ler, vai sair sem saber o que aconteceu de fato nem o que fazer a respeito.

O conflito é estrutural. O help desk trabalha em eventos: cada resposta, cada reabertura, cada transferência de fila é um registro. A diretoria trabalha em decisões: o que falhou, por que falhou, quanto custou e o que muda a partir de agora. Entre os dois mundos existe um trabalho de tradução que normalmente recai sobre um analista sênior — horas montando slide, recortando timeline, tentando lembrar o que realmente aconteceu três semanas atrás.

O resultado costuma ser um de dois extremos: ou o relatório é raso demais (“problema resolvido, cliente satisfeito”) e não serve para decisão, ou é técnico demais e o board não consegue extrair a causa raiz. Em ambos os casos, o incidente não vira aprendizado organizacional.

O caso: chamado #2685787 e o gap de 29 dias

Pegue um chamado real do nosso ambiente: o #2685787. Na superfície, mais um atendimento encerrado. Por dentro, uma thread longa, várias trocas de mensagem, mudanças de responsável e — o detalhe que importa — um intervalo de cerca de 29 dias entre dois marcos do atendimento. Esse gap é exatamente o tipo de informação que o board precisa saber e que fica invisível quando você só lê o chamado de cima para baixo.

Lendo a thread manualmente, esse gap é fácil de perder: ele não está escrito em lugar nenhum como “gap de 29 dias”. Ele só existe quando você compara duas datas distantes na linha do tempo. É trabalho de detetive, e ninguém na diretoria tem tempo para isso.

Foi esse chamado que usamos para testar a tese central do módulo: dá para transformar esse caos em um relatório de incidente para diretoria sem um analista passar a tarde recortando a thread? A resposta é o restante deste estudo de caso.

O que aconteceu: da thread crua a um PDF executivo

No Znuny, abrimos o módulo Relatório de Causa-Raiz para o chamado #2685787 e acionamos a geração do relatório. O Copilot lê todo o histórico do chamado — não um resumo, o histórico completo — e devolve um PDF estruturado em 8 seções, na ordem que a diretoria espera ler.

A primeira seção é o resumo executivo: poucas linhas que dizem o que aconteceu, sem jargão. Logo abaixo, a linha do tempo — e foi aqui que o gap de ~29 dias apareceu sozinho, explícito, porque a IA comparou as datas dos marcos e destacou o intervalo anômalo. O que estava enterrado na thread virou a informação mais visível do documento.

Na sequência vêm a análise de gaps e causa raiz, a análise de sentimento do cliente ao longo do atendimento, o status técnico, as recomendações (o plano de ação), as métricas e a conclusão. O board lê resumo, causa raiz e plano de ação em poucos minutos — e o material técnico continua ali embaixo para quem quiser descer ao detalhe.

As 8 seções: por que essa estrutura convence a diretoria

A força do relatório não é só o conteúdo — é a previsibilidade da estrutura. Quando todo relatório de incidente chega no mesmo formato, o C-level para de gastar energia entendendo o documento e passa a gastar energia decidindo sobre o conteúdo. Isso é o oposto do anexo cru da thread, onde cada caso vem de um jeito.

As 8 seções foram desenhadas para casar com a forma como uma diretoria lê: começa pelo que importa (resumo executivo), mostra a sequência dos fatos (linha do tempo), explica a raiz (análise de gaps + causa raiz), mede o impacto humano (sentimento) e técnico (status técnico), propõe o que fazer (recomendações) e fecha com números (métricas) e síntese (conclusão).

• 1. Resumo executivo — o que aconteceu, em linguagem de board.
• 2. Linha do tempo — a sequência de fatos, com gaps destacados (como os ~29 dias do #2685787).
• 3. Análise de gaps + causa raiz — por que aconteceu, a parte que a diretoria mais cobra.
• 4. Análise de sentimento — como o cliente se sentiu ao longo do atendimento.
• 5. Status técnico — o estado atual, para quem precisa descer ao detalhe.
• 6. Recomendações — o plano de ação, ponto que transforma relatório em decisão.
• 7. Métricas — números do atendimento (tempo, SLA, interações).
• 8. Conclusão — a síntese que o board leva para a próxima reunião.

As duas faces: o chamado e o board inteiro

O caso do #2685787 mostra a primeira face do módulo: o relatório por chamado. Mas a diretoria raramente pergunta sobre um chamado isolado — ela pergunta sobre o mês. É aí que entra a segunda face: o painel agregado.

O painel pega os chamados do período e os agrupa pelo serviço vinculado, trazendo a causa raiz identificada pela IA como detalhe de cada grupo. Em vez de “tivemos 974 chamados”, a conversa vira “o serviço X concentrou os incidentes e a causa raiz recorrente foi Y”. É a mesma tradução do caos para a linguagem do board, só que na escala da operação inteira.

Os números reais dos últimos 30 dias dão a dimensão: 974 chamados no período, 647 analisados (66% de cobertura), distribuídos em 85 serviços. A cobertura de causa raiz nos chamados analisados chega a 84%, a de sentimento a 88%. Para o board, isso significa que a maioria esmagadora dos incidentes analisados já chega com causa raiz mastigada.

O que a IA faz e o que continua sendo do humano

É importante ser honesto sobre o limite. O Copilot não decide o plano de ação — ele propõe recomendações e organiza a evidência. Quem aprova a recomendação, prioriza o investimento e responde ao board continua sendo o gestor. A tese da Service Up é exatamente essa: a IA acelera; o humano decide.

Na prática, o que a IA elimina é o trabalho braçal de tradução: ler a thread inteira, achar o gap de ~29 dias, escrever o resumo executivo, montar a timeline, padronizar o formato. Esse trabalho — que tomava a tarde de um analista sênior — vira um PDF gerado sob demanda. O analista deixa de ser um recortador de threads e passa a ser quem valida a causa raiz e refina o plano de ação.

O ganho não é só velocidade: é consistência. Quando todo incidente vira o mesmo relatório de incidente para diretoria, o board passa a comparar maçãs com maçãs ao longo dos meses — e a tomar decisões melhores sobre onde investir para o próximo incidente não acontecer.