Visibilidade de frota 24/7.
ADS-B ao vivo. Auto-refresh por SSE. Sem trocar de aba.

Flight following, devidamente integrado

O stack padrão de flight following para charter são duas ou três ferramentas separadas: um sistema de dispatch, um tracker ADS-B dedicado e um serviço de notificação por SMS para voos overdue. Cada ferramenta tem o próprio login, o próprio modelo de dados e o próprio gap por onde a informação se perde.

O AeroCopilot Ops funde tudo. O release que o dispatcher montou é o mesmo release que o mapa ao vivo está rastreando. O tail number no quadro de dispatch é o mesmo tail number no feed ADS-B. Quando o voo está overdue, o alerta referencia o ID do release e a última posição conhecida — não um ping genérico "tail N123AB late".

Lógica de overdue ciente do ETA

Um voo que está 10 minutos atrasado por causa de uma mudança de vento não é a mesma coisa que um voo 10 minutos atrasado porque o dispatcher não tem notícia do comandante há 90 minutos. O AeroCopilot Ops usa o ETA filed, o ground speed em voo e a última posição ADS-B para computar um threshold real de overdue por voo — não um timer estático de 15 minutos.

Quando o threshold é cruzado, o alerta escala: dispatcher primeiro, depois chief pilot, depois DOM. Cada passo é registrado. Se o voo virar um incidente §135, o template do report já vem pré-preenchido com a linha do tempo, a última posição conhecida e as tentativas de contato feitas.

Construído sobre MapLibre, não Mapbox

Usamos MapLibre GL JS (licença MIT, sem cobrança per-MAU) com fontes de vector tile customizadas para FAA sectionals, IFR low/high charts e overlays de radar meteorológico. Isso mantém o custo plano à medida que sua frota cresce — e nos permite enviar camadas que o seu incumbente nunca vai enviar.