Incident Voice: como automatizar o acionamento de plantão e reduzir o tempo de resposta a incidentes
Monitorar servidores, links, aplicações e serviços 24 horas por dia é apenas uma parte de uma operação realmente disponível. Quando um incidente crítico acontece às 2h da manhã, a pergunta deixa de ser apenas “o monitoramento detectou?” e passa a ser: “alguém assumiu efetivamente o problema?”
É exatamente nesse intervalo entre a detecção automática e a resposta humana que surgem alguns dos maiores riscos das operações de plantão.
O Incident Voice, desenvolvido pela Thinkout, foi criado para automatizar essa etapa: receber eventos de plataformas de monitoramento, identificar o profissional de plantão, realizar o acionamento por telefone através do 3CX, exigir uma confirmação explícita e iniciar automaticamente o escalonamento quando necessário.
O objetivo não é substituir o monitoramento. É fechar a lacuna entre detectar um incidente e garantir que alguém começou a tratá-lo.
Detectar um problema não significa iniciar sua resolução
Plataformas como Zabbix conseguem monitorar continuamente infraestrutura, serviços e aplicações e gerar eventos quando determinada condição é atingida.
O próprio Zabbix possui suporte a webhooks, permitindo realizar chamadas HTTP para integrar seus alertas a aplicações externas.
Imagine o seguinte cenário:
- um servidor ERP fica indisponível às 23h47;
- o sistema de monitoramento identifica a falha imediatamente;
- uma mensagem é enviada por e-mail, aplicativo ou grupo de mensagens;
- o alerta tecnicamente foi entregue;
- porém ninguém confirma que começou a trabalhar na ocorrência.
Do ponto de vista do monitoramento, o evento foi processado corretamente.
Do ponto de vista da continuidade operacional, ainda existe um problema: o incidente continua sem responsável confirmado.
É essa diferença que torna o processo de acionamento tão importante em ambientes 24x7.
O conceito de acknowledgement
Em gestão de incidentes existe uma métrica particularmente relevante para equipes de plantão: o MTTA — Mean Time to Acknowledge.
O MTTA mede o tempo entre a geração de um alerta e o momento em que alguém reconhece efetivamente a ocorrência e começa a trabalhar nela. A Atlassian, por exemplo, define essa métrica como o intervalo médio entre o disparo do alerta e o início do trabalho sobre o problema.
Isso é diferente do MTTR, que normalmente está relacionado ao tempo necessário para responder ou restaurar o serviço.
Uma operação pode detectar incidentes em segundos e, ainda assim, apresentar um MTTA elevado.
Por exemplo:
22:47:13 — monitoramento detecta indisponibilidade
22:47:20 — alerta enviado
22:53:00 — alguém percebe a mensagem
22:57:00 — responsável correto é localizado
22:58:10 — profissional confirma que assumiu o incidente
Nesse cenário, o monitoramento funcionou praticamente em tempo real, mas quase onze minutos foram consumidos somente para colocar a pessoa correta no processo.
Em sistemas críticos, esse intervalo pode ter impacto direto no SLA e no tempo total de indisponibilidade.
Onde entra o Incident Voice
O Incident Voice atua depois que o monitoramento identifica a ocorrência.
O fluxo conceitual é:
Monitoramento → Webhook/API HTTP → Incident Voice → escala de plantão → 3CX → ligação → confirmação → escalonamento ou encerramento do acionamento
A plataforma recebe o evento, identifica a política relacionada àquela ocorrência e verifica quem está responsável pelo plantão naquele momento.
A partir daí, o 3CX é utilizado para realizar o acionamento telefônico.
O ecossistema 3CX permite integração de aplicações externas com funções de telefonia e controle programático de chamadas, possibilitando construir aplicações que iniciam e controlam chamadas através do PABX.
No Incident Voice, o desenho e a integração utilizados são definidos durante a implantação e dependem do ambiente 3CX homologado para cada operação.
Um evento pode carregar contexto
Um dos pontos importantes desse tipo de integração é que a origem não precisa informar simplesmente que “existe um problema”.
O evento pode transportar informações que ajudem o fluxo de acionamento a identificar sua criticidade e apresentar contexto ao plantonista.
Conceitualmente, um evento poderia conter informações como:
{ "event_id": "984734", "severity": "critical", "host": "ERP-SRV01", "service": "ERP", "problem": "Service unavailable", "timestamp": "2026-08-21T22:47:13-03:00" }
Esse exemplo não representa necessariamente o formato da API do Incident Voice. Ele demonstra apenas como informações estruturadas de uma plataforma de monitoramento podem alimentar uma automação de resposta.
A partir desses atributos, políticas diferentes podem ser aplicadas.
Uma indisponibilidade crítica de ERP, por exemplo, pode exigir acionamento imediato, enquanto um alerta de menor severidade pode seguir outra política definida pela empresa.
A ligação transforma uma notificação passiva em uma ação ativa
E-mail, push notification e mensagens instantâneas são mecanismos importantes de alerta, mas normalmente continuam dependendo de uma ação espontânea do usuário.
A chamada telefônica possui outra característica: ela interrompe ativamente o plantonista.
No fluxo do Incident Voice, o profissional atende e recebe por voz informações relacionadas à ocorrência.
Dependendo da configuração, um menu pode apresentar opções como:
1 — Confirmar ocorrência
2 — Repetir mensagem
3 — Consultar mais detalhes
A confirmação é realizada pelo teclado do telefone utilizando DTMF.
Esse detalhe é importante.
Atender a ligação não significa reconhecer o incidente.
Uma chamada pode ser atendida acidentalmente, direcionada para caixa postal ou encerrada antes que o profissional compreenda o problema.
O acknowledgement precisa representar uma ação explícita do responsável.
E se ninguém responder?
Esse é provavelmente o ponto mais relevante de um sistema de automação de plantão.
O fluxo não pode terminar porque uma única ligação não foi atendida.
Uma política pode determinar, por exemplo:
- ligar para o plantonista;
- aguardar a confirmação;
- realizar uma nova tentativa;
- acionar o segundo responsável;
- escalar para um supervisor;
- continuar conforme os níveis definidos.
Assim, a política operacional deixa de depender de alguém consultar uma planilha de escala, procurar telefones ou decidir manualmente para quem ligar.
O processo passa a ser executado de maneira previsível.
O Incident Voice permite trabalhar com tentativas e níveis de escalonamento definidos e homologados para cada ambiente.
A escala de plantão passa a fazer parte da automação
Outro problema comum aparece quando o monitoramento sabe o que aconteceu, mas não sabe quem deve responder naquele momento.
Quem está de plantão nesta sexta-feira?
O responsável mudou?
Quem assume depois da meia-noite?
Existe um supervisor para escalonamento?
Essas informações normalmente estão distribuídas entre planilhas, agendas e grupos de mensagens.
Ao integrar a escala ao fluxo de acionamento, a aplicação pode determinar automaticamente quem deve receber a chamada naquele momento.
Isso transforma a escala de plantão em parte efetiva do processo operacional, e não apenas em um documento de consulta.
Rastreabilidade muda a gestão do incidente
Existe ainda uma diferença importante entre executar um processo e conseguir comprová-lo.
Sem automação, após uma ocorrência pode ser necessário reconstruir manualmente uma sequência como:
- quando o alerta ocorreu;
- quem recebeu;
- para quem alguém telefonou;
- quantas tentativas foram realizadas;
- quem respondeu;
- quanto tempo levou até alguém assumir.
No Incident Voice, tentativas, contatos, confirmações e resultados podem compor o histórico da ocorrência.
Isso permite transformar o processo de plantão em dados operacionais.
Em ambientes mais maduros, passam a fazer sentido indicadores como:
- tempo até o primeiro acionamento;
- tempo até confirmação;
- MTTA;
- quantidade de tentativas por incidente;
- taxa de confirmação;
- escalonamentos realizados;
- ocorrências por severidade;
- desempenho do processo de plantão ao longo do tempo.
Esses indicadores são particularmente relevantes quando existem SLAs internos ou compromissos de disponibilidade com clientes.
O Incident Voice não substitui o Zabbix
Essa distinção é fundamental.
O Zabbix ou outra plataforma de monitoramento continua responsável por detectar que algo está errado.
O Incident Voice não pretende descobrir se um servidor caiu, se a CPU chegou a determinado limite ou se uma aplicação deixou de responder.
Ele entra depois da detecção.
Podemos separar as responsabilidades desta maneira:
Monitoramento
Detecta o problema.
Incident Voice
Orquestra o acionamento.
3CX
Executa a comunicação por voz.
Plantonista
Confirma e assume a ocorrência.
Essa separação permite utilizar ferramentas especializadas em cada parte do processo.
Onde esse modelo faz mais sentido
A automação de plantão tende a trazer mais valor para organizações que possuem:
- servidores ou aplicações críticas funcionando 24x7;
- NOC, SOC ou equipes de infraestrutura;
- serviços que precisam de atendimento fora do horário comercial;
- contratos com SLA;
- equipes com escalas de plantão;
- clientes que exigem evidências de atendimento;
- operações nas quais alguns minutos de indisponibilidade têm impacto relevante.
Também é importante entender quando esse tipo de solução provavelmente não é necessário.
Uma empresa na qual todos os incidentes podem aguardar até o próximo horário comercial provavelmente não precisa de uma estrutura avançada de escalonamento telefônico.
Automação deve resolver um problema operacional real.
Da monitoração para a gestão efetiva do incidente
Durante muitos anos, grande parte dos investimentos em observabilidade e infraestrutura concentrou-se em reduzir o tempo necessário para descobrir problemas.
Isso continua sendo essencial.
Mas ambientes maduros precisam analisar também o que acontece depois que o alerta aparece na tela.
Existe alguém responsável?
Essa pessoa foi localizada?
Ela recebeu informações suficientes?
Confirmou que assumiu?
Se não respondeu, o próximo nível foi acionado?
Quanto tempo todo esse processo levou?
Ao automatizar essas etapas, o Incident Voice transforma uma sequência normalmente manual em um fluxo controlado e mensurável.
O objetivo final não é gerar mais alertas.
É reduzir o espaço entre “o sistema detectou um problema” e “alguém confirmou que está trabalhando nele”.
Para operações que precisam funcionar 24 horas por dia, essa diferença pode ser tão importante quanto o próprio sistema de monitoramento.
Conheça o Incident Voice
O Incident Voice integra sistemas de monitoramento compatíveis com Webhook/API HTTP ao processo de plantão utilizando o 3CX para acionamento por voz, confirmação DTMF, escalonamento e registro operacional.
A implantação é realizada após análise do ambiente de monitoramento, infraestrutura 3CX, escalas, políticas de acionamento e requisitos da operação.
Conheça o Incident Voice e avalie como automatizar o acionamento de incidentes críticos na sua operação.