Zero e-mail no Comex: como eliminar a comunicação por fora do sistema e parar de perder informação

O analista de Comex enviou 47 e-mails hoje. Doze foram para saber o status de cargas que deveriam estar no sistema. Oito foram para cobrar documentos pendentes que o parceiro não enviou pelo canal correto. Seis foram para repassar informação que já estava registrada em algum lugar — mas que ninguém conseguia encontrar sem perguntar. E três foram em resposta a e-mails respondendo e-mails que respondiam e-mails de duas semanas atrás. O problema não é o volume de e-mails. É o que eles representam: informação que deveria estar no sistema, mas está nas caixas de entrada de pessoas.

O FollowNet One é a plataforma de Control Tower da e.Mix: centraliza eventos, documentos e alertas de todas as operações de importação e exportação — para que a informação esteja no sistema, não no e-mail de quem vai de férias semana que vem. A meta de zero e-mail no Comex não é proibir a comunicação: é fazer com que nenhum dado operacional relevante exista apenas fora do sistema.

Neste artigo mostramos por que o e-mail prolifera nas operações de Comex, quais são os quatro pontos de origem do desvio e como estruturar a transição para que a comunicação operacional passe a acontecer onde deve — no sistema, com rastreabilidade, com owner e sem depender da memória de ninguém.

• → O problema: a informação operacional crítica — status, documentos, divergências, cobranças — vive no e-mail de analistas específicos, invisível para o sistema e para o gestor.
• → O custo-risco: decisão tomada com dado desatualizado, informação perdida quando o analista sai de férias ou deixa a empresa, retrabalho constante de reconstrução de histórico.
• → O mecanismo: centralizar toda comunicação operacional relevante no sistema de Control Tower — com regras claras de o que vai para o sistema, quem alimenta e quando.
• → Como começar: mapear os três tipos de e-mail mais frequentes do time de Comex e identificar qual dado de cada tipo deveria estar no sistema — esse mapeamento define o protocolo de migração.

O e-mail como sintoma, não como causa

O e-mail não é o problema original — é o sintoma de que a informação não encontrou o caminho para o sistema. Quando o analista manda um e-mail para saber se o navio chegou, é porque o ETA não está atualizado na plataforma. Quando cobra o documento por e-mail, é porque o sistema não gerou um alerta de pendência documental. Quando repassa status para o parceiro por e-mail, é porque o parceiro não tem acesso — ou não foi treinado para consultar a plataforma diretamente.

Eliminar o e-mail sem fechar essas origens é inútil: a comunicação migra para WhatsApp, ligação ou planilha compartilhada — e o dado continua fora do sistema. A mudança real começa no diagnóstico das origens, não na proibição do canal.

As quatro origens do desvio — por que a informação vai parar no e-mail

Origem 1 — ETA e status não atualizados no sistema. Quando a plataforma não recebe eventos de rastreamento em tempo real, o analista precisa perguntar ao agente para saber onde a carga está. O e-mail substitui o que o sistema deveria entregar automaticamente.

Origem 2 — Ausência de alerta de pendência. Quando o sistema não gera alertas de documentos pendentes, vencimentos ou divergências, o analista se torna o sistema de alertas — cobrador manual de tudo que deveria chegar por notificação.

Origem 3 — Parceiro que não alimenta o sistema. Quando o agente de carga, despachante ou fornecedor comunica por e-mail porque não foi integrado ao fluxo da plataforma — ou porque o processo de integração nunca foi exigido — o dado nasce fora do sistema e nunca entra.

Origem 4 — Falta de padrão sobre o que vai para o sistema. Quando o time não tem clareza sobre qual tipo de comunicação deve ser registrada na plataforma e qual pode ficar no e-mail, a decisão fica na cabeça de cada analista — e cada um decide diferente.

Diagnóstico: onde a comunicação ainda está fora do sistema na sua operação

Antes de definir o protocolo de migração, é necessário mapear onde os desvios estão. Use o checklist abaixo como ponto de partida — cada “Fora do sistema” é um ponto de origem que precisa de endereçamento específico:

Três ou mais linhas em “Fora do sistema” indicam que o e-mail está preenchendo lacunas estruturais da operação — e que a solução não é disciplina do time, mas configuração da plataforma.

O que muda quando a comunicação entra no sistema

A mudança mais imediata não é a eliminação do e-mail em si — é o que o time passa a fazer com o tempo que era gasto produzindo e respondendo e-mails de status. Quando a informação está na plataforma, o analista trata exceções. Quando está no e-mail, o analista é o sistema.

O impacto aparece também na gestão. Quando o gestor precisa do status de uma carga para uma reunião de S&OP, a resposta está a um clique — não depende de interromper um analista, aguardar resposta ou cruzar três caixas de entrada para montar o quadro completo.

De “consultar várias analistas” para abrir a plataforma em tempo real

Antes: status de carga dependia de consultar várias analistas — a informação estava distribuída entre pessoas, não centralizada no sistema.

Depois: status consultado diretamente na plataforma em tempo real, inclusive durante reuniões de S&OP — sem precisar acionar o time para obter uma única informação.

Daniele Seleme Pioli — Gestora de S&OP — Positivo Tecnologia
Vídeo: https://www.youtube.com/watch?v=TLag_lr6PgI&t=96

Como eliminar o e-mail sem travar os parceiros — um protocolo em 3 fases

A transição não acontece por decreto. Proibir e-mail sem construir o caminho alternativo gera resistência e faz a comunicação migrar para canais ainda mais difíceis de rastrear. O protocolo abaixo funciona porque começa pelo que está dentro do controle do time interno — antes de exigir mudança dos parceiros externos:

Fase 1 — Fechar as origens internas (semanas 1–4). Configurar alertas de pendência, atualização automática de ETA e fluxo de registro de divergências na plataforma. O objetivo desta fase é eliminar os e-mails que o time manda para si mesmo — status interno, cobranças internas, atualizações para o gestor. O que estava no e-mail interno entra no sistema.

Fase 2 — Integrar os parceiros prioritários (semanas 5–8). Identificar os dois ou três agentes ou despachantes responsáveis pelo maior volume de e-mails externos. Definir com eles o protocolo de alimentação da plataforma — quais eventos precisam ser registrados, em qual prazo e em qual formato. A exigência de registro é parte do contrato de SLA com o parceiro, não uma solicitação opcional.

Fase 3 — Padronizar e expandir (semanas 9–12). Com o fluxo interno e os parceiros prioritários no sistema, o padrão se torna referência para os demais. Novos parceiros são integrados desde o onboarding com o protocolo já definido. A revisão semanal de e-mails operacionais ainda em uso revela os desvios residuais a fechar.

Como começar sem projeto infinito

Owner: Coordenador ou Gerente de Comex — responsável pelo mapeamento inicial dos tipos de e-mail mais frequentes e pela definição do protocolo de migração junto ao time e.Mix.

Cadência: Semanal — revisão dos e-mails operacionais ainda em uso pelo time para identificar qual origem ainda não foi fechada na plataforma.

KPI farol: Volume de e-mails de status enviados pelo time por semana — a queda consistente desse número nas primeiras 8 semanas indica que a migração está acontecendo.

Primeiro recorte: O tipo de e-mail mais frequente no time — tipicamente “qual o status da carga X?” — é o ponto de entrada. Fechar essa origem específica na plataforma entrega resultado visível e cria o argumento interno para expandir o protocolo.

Saiba mais

• FollowNet One: centralização de eventos e alertas no Comex
• FollowNet One vs. Excel: o que muda na gestão da informação
• O Modelo e.Mix: método e time que viabilizam a mudança
• FollowNet One para operações de importação
• Cases de resultado com centralização de informação no Comex

📖 Leia o guia completo: Planilha vs. sistema no Comex: guia completo