Cliente com contrato cobrando
Um link dedicado ficou fora além do prazo de reparo e o cliente pede explicação formal.
Suporte N3 · Provedores
A queda explicada por escrito para diretoria, equipe e clientes empresariais: o que aconteceu, quem foi afetado, por que e o que muda.
Relatório pós-incidente é o documento que registra uma queda da rede depois que ela acabou: quando começou, quem foi afetado, qual foi a causa, o que a equipe fez e o que muda daqui para frente. É para o provedor que precisa explicar a parada a clientes com contrato, à diretoria ou a um órgão público. O resultado é um texto claro, com horários e evidências, e uma lista de ações que dá para acompanhar.
É a versão escrita e organizada de um incidente, feita para quem não estava na rede na hora da queda. Serve para prestar contas e para a lição virar mudança.
No suporte técnico N3, o relatório fecha o ciclo de um incidente grave: a rede volta, a causa é investigada e o documento conta tudo em ordem. Sem ele, cada pessoa lembra da queda de um jeito e as ações combinadas se perdem na semana seguinte.
Clientes empresariais costumam ter SLA com prazo de reparo e desconto por indisponibilidade. O relatório mostra a duração medida, a causa e o que foi feito, e é com ele que o provedor discute o desconto com números.
Quando a queda veio da borda, como uma sessão BGP perdida com a operadora, o relatório traz também o que a operadora informou e em que horário. Todo relatório tem quatro partes que não podem faltar:
O que aconteceu, em poucas linhas, para quem só vai ler o começo: diretoria, cliente empresarial ou prefeitura.
Início, detecção, primeira ação, volta parcial e volta total, cada momento com horário e a fonte de onde ele saiu.
Quantos assinantes, quais clientes empresariais, quais serviços e por quanto tempo, separados por região quando a queda foi parcial.
A causa com evidências, o que foi feito durante a queda e as ações para não repetir, cada uma com responsável e data.
Você precisa quando alguém de fora da equipe técnica vai cobrar explicação pela queda. Estes seis casos são os que mais pedem o documento.
Um link dedicado ficou fora além do prazo de reparo e o cliente pede explicação formal.
Prefeitura, escola ou posto de saúde atendidos pelo provedor pedem documento para o processo interno.
Os sócios querem saber se a queda pede gerador, segundo link ou equipamento novo antes de aprovar o gasto.
Parada geral com muitas reclamações no atendimento e nas redes sociais, que precisa de uma versão oficial.
Ataque ou invasão que pede registro formal. A resposta técnica fica na resposta a incidentes de segurança.
Cada incidente fica só na memória de quem atendeu, e a mesma falha é investigada do zero a cada vez.
São cinco etapas, da coleta dos dados à lista de ações. A sua equipe revisa o rascunho antes de qualquer versão sair para fora.
Logs, alarmes, gráficos, conversas do atendimento e chamados abertos com operadora ou fabricante.
Prazo: [PREENCHER]
Assinantes e clientes afetados, cruzando sistema de gestão, RADIUS e alarmes das ONUs.
Prazo: [PREENCHER]
Linha do tempo, causa e ações revisadas com a sua equipe para não sobrar erro de horário ou de fato.
Prazo: [PREENCHER]
Texto sem dados internos da rede, escrito na linguagem de diretoria, cliente ou órgão público.
Prazo: [PREENCHER]
Documento final e lista de ações para você acompanhar até a última ser cumprida.
Prazo: [PREENCHER]
O serviço vai da coleta dos dados à entrega do documento em duas versões. A investigação longa e o laudo com valor de prova são serviços à parte.
O preço depende do tamanho da queda e de quanto da história já está registrada. O valor fechado sai depois de olhar os dados disponíveis.
| Fator | Como influencia | Exemplo |
|---|---|---|
| Duração e alcance | Queda longa e ampla tem mais eventos para ordenar e mais impacto para contar | Parada de seis horas em três cidades |
| Dados disponíveis | Sem logs centralizados, a linha do tempo sai de vários equipamentos | Alarmes vistos só na tela da OLT |
| Causa conhecida ou não | Sem causa clara, entra uma análise antes do texto | Queda que voltou sozinha |
| Versões entregues | Cada leitor de fora pede outra redação e revisão | Relatório para três clientes empresariais |
| Prazo pedido | Entrega mais curta que o normal exige dedicação exclusiva | Cliente exigindo o documento em dois dias |
Faixa de preço para uma queda com causa já conhecida: [PREENCHER faixa aprovada pela Táquion Tech]. Clientes com contrato de suporte N3 para provedor podem ter o relatório incluído nos incidentes graves [CONFIRMAR oferta].
Confira qual documento o seu leitor precisa, os erros que derrubam a credibilidade do relatório e as perguntas que ele tem de responder. Vale para avaliar qualquer empresa de relatório pós-incidente, inclusive a Táquion Tech.
Três documentos parecidos com usos diferentes. Pedir o errado gera texto técnico demais para o cliente ou fraco demais para o advogado.
| Documento | Para quem | O que responde |
|---|---|---|
| Relatório pós-incidente | Diretoria, clientes e equipe | O que aconteceu e o que muda |
| Análise de causa raiz | Equipe técnica | Por que a falha aconteceu, com prova |
| Laudo técnico | Advogado, juiz ou seguradora | Estado técnico com responsabilidade formal |
A equipe de rede, a diretoria técnica e o fornecedor envolvido na falha.
Logs, nomes de equipamentos, comandos aplicados e a configuração antes e depois.
Cliente empresarial, prefeitura ou condomínio afetado pela queda.
Horários, impacto, causa em linguagem simples e o que muda, sem expor topologia, IPs nem senhas.
Falhas que fazem o cliente desconfiar do documento inteiro.
Relatório enviado no calor da queda, com causa suposta, precisa ser corrigido depois. Mande um aviso curto e o relatório quando a causa estiver provada.
Se o cliente tem monitoramento próprio e os horários não batem com os dele, o documento perde a credibilidade inteira.
Nome de técnico como causa faz a equipe esconder erro na próxima vez. O relatório trata de processo, configuração e equipamento.
Reforçar o monitoramento não é ação. Criar o alerta de memória no concentrador até uma data, com um responsável nomeado, é.
Se alguma ficar sem resposta, o leitor vai perguntar por escrito.
A distância entre os dois horários mostra se o monitoramento funciona. Uma hora de diferença já é um achado.
Número de assinantes e lista de clientes com contrato, separados por serviço e por região.
Causa com evidência, ou a indicação clara de que a investigação continua e quando termina.
Ações com responsável e data, e quando o cliente vai saber que elas foram cumpridas.
Referências que influenciam o que o relatório precisa conter.
O RQUAL trata de indicadores de disponibilidade e, em alguns casos, de comunicação de interrupções [CONFIRMAR na norma].
Muitos contratos empresariais fixam prazo para entregar o relatório depois da queda. Leia a cláusula antes de prometer uma data.
Prática comum em equipes de operação: o texto procura o que falhou no processo, não quem errou, e por isso a equipe conta tudo.
Porque o relatório é escrito por quem entende a rede e revisado por quem atendeu a queda. Seis compromissos de toda entrega.
Quem redige entende logs, OLT e BGP, e traduz para a diretoria sem distorcer o que aconteceu.
[PREENCHER: anos de experiência da equipe em operação de provedores]
A versão técnica e a dos clientes saem da mesma linha do tempo, sem contradição entre elas.
Duas versões em toda entrega
Cada evento diz de onde veio o horário, seja log, alarme, gráfico ou chamado.
Fonte citada em cada evento da linha do tempo
Antes da entrega, quem atendeu a queda lê o rascunho e corrige o que não bate.
Rascunho revisado antes da versão final
A versão para clientes não mostra IPs, topologia, marcas de equipamento nem senhas.
Dados internos só na versão técnica
A lista sai separada do texto, com dono e data, para você acompanhar item por item.
Lista de ações entregue junto do relatório
O relatório pós-incidente é feito à distância para provedores de todo o Brasil. A reunião presencial fica para o litoral de Santa Catarina, quando a diretoria prefere.
Dados recebidos por acesso seguro, entrevistas por vídeo e entrega do documento por escrito, de qualquer estado.
Para apresentar o relatório à diretoria ou ao cliente empresarial, ou levantar dados direto no POP. [CONFIRMAR área de atendimento]
O que os provedores mais perguntam quando precisam explicar uma queda por escrito. Se a sua dúvida não estiver aqui, pergunte no WhatsApp.
Resumo, linha do tempo, impacto, causa, o que foi feito e o que muda. Cada ação precisa de responsável e prazo, senão o relatório vira só um registro.
Um aviso curto pode sair logo; o relatório completo vem depois de confirmada a causa. O prazo padrão é [PREENCHER], e o do seu caso vai na proposta.
O preço do relatório pós-incidente muda com a duração da queda, os dados disponíveis e as versões pedidas. A faixa para uma queda com causa conhecida é [PREENCHER].
Para clientes empresariais afetados, costuma valer a pena. A versão para clientes explica a queda sem expor detalhes internos da rede.
Não. Ele aponta causas e ações. Procurar culpado faz a equipe esconder informação na próxima queda.
Sim, desde que existam dados: logs, alarmes, gráficos e o relato de quem atendeu. Quanto antes eles forem salvos, mais precisa fica a linha do tempo.
A análise de causa raiz descobre e prova a causa, com testes. O relatório conta a queda para quem não é técnico, usando essa causa.
Os mesmos dados apoiam as informações que o provedor pode ter de enviar sobre a interrupção [CONFIRMAR obrigações]. O envio continua sendo responsabilidade do provedor.
Ajuda, porque mostra a duração medida e a causa com evidência. A discussão passa a ser sobre números, não sobre impressões.
Horários aproximados, logs e alarmes do período, a lista de clientes afetados e o contato de quem atendeu. Se houver chamado com operadora ou fabricante, o número dele também.
Três serviços que vêm antes, durante ou depois do relatório. Cada um resolve uma parte que o documento não resolve.
Investigação com testes quando a causa da queda não ficou clara na hora.
Ver a análise de causa raiz
Página pública que avisa os assinantes durante a queda e reduz as ligações no atendimento.
Ver a página de status para assinantes
Documento técnico com responsabilidade formal para disputa com fornecedor, cliente ou seguradora.
Ver o laudo técnico de redeTrês guias sobre como tratar incidentes e registrar o que aprendeu com eles.
Como transformar incidentes repetidos em problemas tratados até a causa.
O que o ITIL muda na forma de registrar e revisar incidentes de rede.
Um exemplo de queda geral e os dados que precisam ser guardados durante ela.
Orçamento
Conte qual queda precisa de relatório e quem vai ler. Um Especialista devolve escopo, prazo e valor por escrito.
Falar com o André Comercial, no WhatsApp