Como configurar um sistema de mensagem do dia funcional
O conceito de mensagem di dia aparece em contextos bem diferentes dependendo de onde você trabalha. Pode ser um script simples que exibe um aviso no login de um servidor Linux, pode ser um serviço de notificações diárias para uma equipa de desenvolvimento, ou pode ser simplesmente uma rotina de enviar uma frase ou informação relevante todos os dias para os membros de uma comunidade. O problema é que quase todo mundo tenta complicar isso desde o início e depois se arrepende. Eu configurei o meu primeiro sistema desses em 2018 para uma equipa de cerca de quarenta pessoas. A gente ia usar um bot no Telegram que enviava uma mensagem às oito da manhã, todo dia, com um lembrete diferente. Parecia simples até o primeiro mês passar. A maioria dos scripts que eu vejo por aí falha num ponto específico: eles não tratam o caso em que o serviço de envio fica fora do ar durante um fim de semana ou feriado. Aí, quando o bot volta, ele despeja cinquenta mensagens acumuladas de uma vez e a equipa toda bloqueia o canal porque não aguenta o spam.
A solução que eu encontrei foi muito mais simples do que qualquer biblioteca complexa de orchestração. Basicamente, o script precisa verificar se já enviou a mensagem daquele dia antes de enviar de novo, usando uma flag de data no arquivo de estado. Se o serviço caiu, ele envia apenas uma mensagem de recuperação, não todas as pendentes. Isso economiza bastante dor de cabeça.
mensagem di dia na prática
Se o seu objetivo é criar um sistema de mensagem di dia para comunicação interna, aqui está o caminho que funciona na prática e não só no papel. O primeiro passo é escolher a plataforma de entrega. No Brasil e em Cabo Verde, WhatsApp e Telegram são os mais usados. Se for para uso profissional, eu recomendo Telegram porque a API é mais flexível e permite programar mensagens com cron jobs sem depender de bibliotecas de automação de navegador que quebram a cada atualização. WhatsApp Web com bibliotecas como selenium ou puppeteer funciona, mas exige manutenção constante porque a interface muda com frequência.
Depois vem a parte do conteúdo. A armadilha comum aqui é tentar automatizar totalmente a geração das mensagens. Você acaba dependendo de uma API externa de frases motivacionais ou de um banco de dados que fica desatualizado. Eu já vi equipas inteiras abandonando o sistema porque as mensagens geradas automaticamente viravam clichê repetido em duas semanas. O workaround que eu uso é ter um arquivo JSON com pelo menos sessenta entradas manuais, organizadas por tema, e um script que rotaciona selecionando aleatoriamente sem repetição consecutiva. Se o grupo tiver mais de duzentas pessoas, o ideal é ter pelo menos cento e vinte entradas para garantir variabilidade por pelo menos dois meses. Para a parte técnica, um script Python rodando num cron job é suficiente na maior parte dos casos. Algo básico como verificar a data atual, carregar a próxima mensagem do arquivo, enviar via webhook ou API do Telegram, e atualizar o índice no arquivo de estado. Leva cerca de duzentas linhas de código, menos de quinze minutos para rodar, e praticamente não quebra se você evitar dependências pesadas. Um exemplo simplificado seria:
👉 Clique no botão abaixo para saber mais sobre o assunto!
Um arquivo de configuração chamado config.json com os dados do bot, um arquivo messages.json com as sessenta a cento e vinte mensagens, e um script principal que lê o último índice enviado, calcula o próximo, faz a requisição e salva o novo índice. Se quiser algo mais robusto, adicione um log de erros e uma tentativa de retry com backoff exponencial caso a requisição falhe. Se o seu caso for diferente e você precisar de mensagem di dia para um servidor Linux, o formato MOTD padrão do sistema já resolve isso sem instalar nada. Você edita o arquivo /etc/motd ou cria um script em /etc/update-motd.d/ e o sistema exibe automaticamente no login. Para ambientes de produção onde múltiplos usuários acessam via SSH, eu costumo adicionar um check simples que só mostra a mensagem se o usuário não a visualizou naquele dia, gravando um timestamp num arquivo oculto no home directory de cada um.
O principal ponto de falha que eu vejo é a falta de um mecanismo de rollback. Quando algo dá errado na rotação das mensagens, você precisa conseguir voltar rapidamente para o estado anterior. Ter um backup do arquivo messages.json e do índice no mesmo diretório, com ou data no nome, resolve isso em dois minutos. Sem isso, você passa horas qual mensagem causou o erro de formatação ou qual índice ficou corrompido. Outra coisa que pouca gente considera é a questão do fuso horário. Se a sua equipa ou audiência espalha por vários fusos, definir um horário fixo de envio como "oito da manhã" vai entregar mensagem muito tarde para alguns e muito cedo para outros. A solução mais prática é enviar no horário de pico de cada região ou simplesmente usar um intervalo fixo de vinte e quatro horas a partir do último envio, independentemente do relógio. É menos elegante visualmente, mas funciona sem dor de cabeça.
Quando não vale a pena automatizar
Existem cenários em que mensagem di dia automatizada piora a situação em vez de melhorar. Se o grupo tem menos de dez pessoas, o custo de manutenção do script geralmente supera o benefício. Nessas situações, uma planilha compartilhada com as mensagens da semana ou até um quadro Kanban com post-its digitais é mais simples e mais fácil de ajustar. Automação tem custo: teste, deploy, monitoramento, backup, fallback. Se o sistema quebra e ninguém sabe consertar, a mensagem simplesmente deixa de ser enviada e as pessoas esquecem que existia. Também não recomendo automação total para mensagens que envolvam dados sensíveis ou informações operacionais críticas. Um script mal configurado pode enviar dados errados para o grupo certo sem nenhum alerta. Nesses casos, o fluxo manual com revisão prévia é mais seguro, mesmo que menos conveniente.
O que funciona na prática é começar pequeno. Um script básico, um arquivo de mensagens manualmente curado, um cron job rodando todo dia no horário certo, e um log simples para acompanhar se algo saiu do esperado. Se o sistema crescer e precisar de mais recursos, aí sim você avalia migrar para uma solução mais completa com fila de mensagens, template engine e painel de controle. Na maioria das vezes, o básico resolve e não precisa evoluir.
