23 de mai. de 2025·8 min
Criar um app web de anúncios internos com confirmação de leitura
Aprenda a planejar, construir e lançar um app web de anúncios internos com confirmação de leitura, papéis, segmentação e análises simples.
Aprenda a planejar, construir e lançar um app web de anúncios internos com confirmação de leitura, papéis, segmentação e análises simples.
Um app de anúncios internos resolve um problema simples, porém caro: atualizações importantes passam despercebidas, e ninguém consegue responder com confiança “Todos viram isso?”. Threads de email, canais de chat e publicações no intranet geram ruído, e a responsabilidade fica nebulosa — especialmente para mudanças de política, avisos de segurança, fechamento de escritórios e prazos de benefícios.
Com confirmações/recibos de leitura embutidos, o resultado muda de “enviamos” para “podemos confirmar que foi lido”. Essa clareza ajuda as equipes a agir mais rápido, reduz perguntas repetidas e dá ao RH e aos gestores uma maneira confiável de acompanhar sem chutar.
Isso não é só uma ferramenta de RH. É um sistema de comunicação interna usado por grupos diferentes para razões diferentes:
O ponto-chave é que toda audiência se beneficia: quem publica sabe o que aconteceu, e os funcionários sabem onde olhar para não perder avisos críticos.
Defina o propósito do app em uma frase: entregar anúncios chave às pessoas certas e confirmar quem os leu.
Isso implica algumas decisões de produto que você tomará depois (segmentação, controle de acesso por função, trilha de auditoria), mas mantenha o “porquê” claro. Se você não conseguir explicar por que uma confirmação de leitura importa para sua organização, terá dificuldade para decidir quais dados armazenar e quais relatórios construir.
Escolha métricas que reflitam tanto a eficácia de entrega quanto o comportamento dos funcionários:
Defina metas por tipo de anúncio. Um post “almoço grátis na sexta” e um post “novo requisito de segurança” não devem compartilhar a mesma meta. Para mensagens críticas, você pode mirar 95% de leitura em 24–48 horas e usar essa meta para moldar notificações e acompanhamentos.
Se quiser uma métrica norteadora, use: % dos anúncios críticos lidos pela audiência alvo completa dentro do prazo exigido.
Um escopo claro impede que seu app de anúncios se transforme em um portal “faz-tudo”. Comece escrevendo quem vai usar (comunicação, RH, TI, gestores, todos os funcionários) e como o sucesso vai parecer (p.ex., atualizações críticas reconhecidas em 24 horas).
Defina uma primeira versão que resolva o problema central: publicar anúncios segmentados e confirmar que foram lidos.
Recursos obrigatórios (v1):
Recursos desejáveis (posteriores):
Se quiser validar o escopo rapidamente, um protótipo rápido pode reduzir o risco das partes difíceis (segmentação, lógica de recibos, dashboards) antes de investir em uma construção completa. Por exemplo, times frequentemente usam Koder.ai para gerar um app interno via chat — então iteram nos fluxos (feed, visão de detalhe, reconhecer) e exportam o código-fonte quando os requisitos estão estáveis.
Anúncios diferentes exigem expectativas diferentes. Concorde num pequeno conjunto de tipos desde o começo:
Para cada tipo, capture campos obrigatórios (data de expiração, reconhecimento obrigatório, prioridade) e quem pode publicar.
Seja específico para que engenharia e stakeholders se alinhem:
Esse documento de escopo vira seu plano de construção e referência de controle de mudanças quando pedidos novos aparecerem.
Papéis e permissões claros mantêm os anúncios confiáveis, evitam postagens acidentais para toda a empresa e tornam os recibos defensáveis quando surgirem dúvidas.
Admin gerencia o sistema: provisionamento de usuários, configurações da organização, regras de retenção e integrações. Admins não precisam escrever anúncios no dia a dia.
Publisher cria e publica anúncios. Normalmente Comunicação, RH ou TI.
Manager pode rascunhar ou solicitar anúncios para sua equipe e ver recibos de anúncios que eles possuam (ou para sua linha de reporte).
Employee lê anúncios e pode reconhecê-los (se exigido). Funcionários geralmente não devem ver os recibos de outras pessoas.
Auditor (opcional) tem acesso somente leitura a anúncios publicados, trilha de auditoria e exportações para revisões de conformidade.
No mínimo, defina permissões para: criar, editar, publicar, arquivar, ver recibos e exportar. Implemente permissões no nível da ação (não apenas por papel) para poder adaptar sem reescrever lógica.
Um padrão prático:
Se aprovações importarem, separe redação de publicação:
Documente essas regras em uma página curta de “política de acesso” e vincule internamente (p.ex., /help/access-policy).
Antes de esboçar recursos, esboce momentos: o que um funcionário precisa fazer em menos de 10 segundos, e o que um admin precisa fazer sem treinamento. Uma UX clara também reduz disputas “não vi” quando você adicionar recibos de leitura.
Login deve ser sem atrito: sign-in com um botão único (se disponível), estados de erro claros e um caminho direto de volta para onde o usuário parou.
Feed é a base. Priorize escaneabilidade: título, prévia curta, categoria/tag, badge de segmentação (opcional) e status (Não lido/Lido/Requer reconhecimento). Adicione um filtro simples para Não lidos e uma barra de busca.
Detalhe do anúncio é onde os recibos são gerados. Mostre o conteúdo completo, anexos/links e um estado de leitura óbvio. “Ler automaticamente ao abrir” é tentador, mas considere aberturas acidentais. Se reconhecimentos forem exigidos, separe “Ler” de “Reconhecer” com texto claro.
Compor deve ser um editor leve: título, corpo, seleção de audiência, agendamento de publicação e pré-visualização. Mantenha opções avançadas recolhidas.
Admin pode começar como uma única página: gerenciar usuários/papéis, criar grupos e ver desempenho de anúncios.
Use tipografia legível, alto contraste e contornos de foco visíveis. Garanta que todas as ações funcionem por teclado.
Projete para leituras rápidas em mobile: alvos de toque grandes, um botão “Reconhecer” fixo quando necessário e estados de carregamento que não bloqueiem o conteúdo.
Um modelo de dados claro torna recibos confiáveis, segmentação previsível e relatórios rápidos. Você não precisa de dezenas de tabelas — apenas algumas entidades bem escolhidas e regras sobre como se relacionam.
No mínimo, modele:
Para Announcement, inclua:
Considere também metadados que você vai querer depois: created_by, updated_by, status (draft/scheduled/published) e timestamps. Isso suporta auditoria sem tabelas extras.
Segmentação é onde muitas ferramentas internas se complicam. Escolha uma estratégia cedo:
Lista explícita de usuários: armazene o conjunto exato de user IDs para um anúncio.
Melhor para audiências pequenas e precisas. Mais difícil de gerenciar em grandes organizações.
Filtros por grupo: armazene regras como “Team = Suporte” ou “Location = Berlin.”
Bom para padrões recorrentes, mas audiências mudam conforme pessoas trocam de time.
Snapshots (recomendado para recibos): guarde os filtros na autoria e então resolva num momento de publicação para uma lista fixa de destinatários.
Isso mantém relatórios e recibos estáveis: as pessoas que foram alvo na publicação continuam sendo a audiência, mesmo se alguém mudar de time depois.
Recibos podem crescer rápido. Facilite consultas:
Isso evita duplicatas e torna telas comuns rápidas (p.ex., “O Alex leu isto?” ou “Quantas leituras o Anúncio #42 tem?”).
Recibos de leitura parecem simples (“ele leu?”), mas os detalhes determinam se os relatórios são confiáveis. Comece definindo o que “lido” significa na sua organização — depois implemente essa definição de forma consistente.
Escolha um sinal primário e mantenha-o:
Muitas equipes rastreiam tanto read quanto acknowledged: “read” é passivo, “acknowledged” é confirmação intencional.
Crie um registro de recibo dedicado por usuário por anúncio. Campos típicos:
user_idannouncement_idread_at (timestamp, nullable)acknowledged_at (timestamp, nullable)Diagnósticos opcionais como device_type, app_version ou ip_hash devem ser adicionados apenas se realmente necessários e com aprovação de política.
Para evitar contagem dupla, imponha uma constraint única em (user_id, announcement_id) e trate atualizações de recibo como upserts. Isso evita números inflados por aberturas repetidas, refreshes ou cliques em notificações.
Anúncios são frequentemente atualizados. Decida de antemão se edições devem resetar recibos:
Uma abordagem simples é armazenar um announcement_version (ou content_hash) no recibo. Se a versão mudar e a alteração for marcada como “requer nova confirmação”, você pode limpar acknowledged_at (e opcionalmente read_at) mantendo a trilha de auditoria de versões anteriores.
Feito corretamente, recibos viram uma medida confiável — sem se transformar em vigilância ou dados inconsistentes e barulhentos.
Um app de anúncios internos manutenível é menos sobre caçar as ferramentas mais novas e mais sobre escolher peças bem suportadas que sua equipe consiga operar por anos. Mire numa stack com boa documentação, grande pool de talentos e hospedagem simples.
Uma linha de base comprovada é um framework mainstream pareado com um banco relacional:
Bancos relacionais tornam mais fácil modelar anúncios, audiências e registros de recibo com relacionamentos claros, restrições e consultas amigáveis para relatórios.
Se prefere ir mais rápido com um padrão moderno, Koder.ai costuma gerar frontends React com backend em Go e PostgreSQL — útil quando você quer uma base manutenível sem montar todo CRUD, telas e checagens de permissão do zero.
Mesmo se construir um app server-rendered, defina endpoints REST limpos para manter UI e integrações futuras simples:
GET /announcements (lista + filtros)POST /announcements (criar)POST /announcements/{id}/publish (fluxo de publicação)POST /announcements/{id}/receipts (marcar leitura)GET /announcements/{id}/receipts (visões de relatório)Isso mantém responsabilidades claras e facilita auditoria depois.
Tempo real é legal, não obrigatório. Se precisar de badges instantâneos de “novo anúncio”, considere:
Comece com polling; faça upgrade só se os usuários notarem atrasos.
Evite guardar arquivos grandes no banco. Prefira object storage (p.ex., compatível com S3) e mantenha apenas metadados (filename, size, URL, permissões) no banco. Se anexos forem raros e pequenos, dá para começar com armazenamento local e migrar depois.
Autenticação é a porta de entrada — acerte cedo para que toda funcionalidade posterior (segmentação, recibos, analytics) herde o mesmo modelo de confiança.
Para a maioria das empresas, SSO é o padrão, porque reduz risco de senha e combina com como funcionários já fazem login.
Escolha uma abordagem e seja consistente:
HttpOnly, Secure e SameSite=Lax/Strict. Roteie IDs de sessão no login e em mudanças de privilégio.Defina timeout por inatividade e tempo absoluto de sessão para evitar sessões em dispositivos compartilhados.
Autenticação prova identidade; autorização prova permissão. Aplique checagens de autorização em:
Trate essas checagens como regras servidor-side obrigatórias — não dicas na UI.
Mesmo apps internos precisam de salvaguardas:
Um bom compositor não é sobre formatação chique, e sim sobre evitar erros. Trate cada anúncio como um mini-processo editorial: propriedade clara, estados previsíveis e uma maneira de corrigir problemas sem bagunçar o histórico.
Use um modelo de status simples e visível:
Para responsabilidade, armazene quem moveu entre estados e quando (trilha de auditoria legível).
Agendamento evita pressão de “enviar agora” e suporta times globais.
Mostre o timezone atual na UI e avise se expire_at for anterior a publish_at.
Escolha um formato e seja consistente:
Para a maioria das equipes, Markdown básico (headings, bullets, links) é um meio-termo prático.
Se suportar anexos, defina expectativas:
Se scanners de vírus estiverem disponíveis no provedor de storage, habilite; senão, pelo menos restrinja tipos executáveis e registre uploads para acompanhamento.
Entrega é a ponte entre “publicamos” e “funcionários viram”. Mire em alguns canais claros, regras consistentes e preferências fáceis de entender.
Comece com uma experiência in-app: um badge “Novo” no header, contagem de não lidos e um feed que destaca itens não lidos primeiro. Isso mantém o sistema autocontido e evita depender de caixas de entrada.
Depois adicione notificações por email para quem não vive no app o dia todo. Mantenha emails curtos: título, primeira linha e um botão que linka para a página de detalhe do anúncio.
Notificações push podem ser opcionais (e posteriores), pois adicionam complexidade entre dispositivos. Se usar, trate push como um canal extra — não o único.
Dê controle ao usuário sem excessos:
Uma regra simples funciona bem: padrão para in-app + email em categorias de alta importância, e permita que usuários reduzam (exceto avisos legalmente exigidos).
Posts urgentes devem ser visualmente distintos e podem ser fixados no topo até serem lidos. Se a política exigir, adicione um botão “Reconhecer” separado do recibo normal, assim você pode reportar confirmações explícitas.
Adicione salvaguardas: limite de envio de emails em massa, permissões elevadas para enviar notificações urgentes, e controles administrativos como “limitar posts urgentes por semana” e “pré-visualizar contagem de destinatários antes de enviar”. Isso mantém o sistema confiável em vez de ignorado.
Recibos só valem quando respondem perguntas práticas: “Isso alcançou as pessoas certas?” e “Quem ainda precisa de um empurrão?”. Mantenha relatórios simples, fáceis de entender e limitados ao que os publicadores realmente precisam.
Comece com uma visão por anúncio que mostra três números:
Se você armazenar eventos, calcule esses números a partir da tabela de receipts em vez de misturar lógica na UI. Inclua também um pequeno timestamp de “última atualização” para que publicadores confiem nos dados.
Adicione filtros que reflitam cortes operacionais sem transformar o app num tool de BI:
Quando aplicar filtros, mantenha o mesmo resumo delivered/read/unread para facilitar comparações de segmentos.
CSV é útil para auditorias e acompanhamentos, mas deve incluir o mínimo necessário. Um bom padrão:
Evite exportar detalhes de dispositivo, endereços IP ou perfis completos de usuário a menos que haja política clara e aprovação.
Posicione recibos como meio para confirmar mensagens críticas (mudanças de política, avisos de segurança, interrupções), não para rastrear produtividade. Considere mostrar aos gestores estatísticas agregadas por padrão e exigir permissão elevada para aprofundar em dados por usuário, com uma trilha de auditoria de quem acessou isso.
Privacidade e confiabilidade determinam se as pessoas confiam no seu app. Recibos são especialmente sensíveis: podem facilmente parecer “rastreamento” se você coletar mais do que precisa ou guardar para sempre.
Comece com minimização de dados: armazene apenas o que precisa para provar que um recibo aconteceu. Para muitas equipes isso é user ID, announcement ID, timestamp e a fonte do cliente (web/mobile) — não endereços IP, GPS ou impressões digitais detalhadas do dispositivo.
Defina opções de política de retenção desde o início:
Documente isso numa nota curta e em linguagem simples dentro do app (linkada em /settings).
Mantenha trilha de auditoria para ações chave: quem publicou, editou, arquivou ou restaurou um anúncio, e quando. Isso ajuda a resolver disputas (“Isso foi alterado depois de enviado?”) e apoia conformidade interna.
Teste os caminhos de maior risco:
Use ambientes separados (dev/staging/prod), rode migrações de banco com segurança e configure monitoramento e backups. Acompanhe erros e falhas de jobs (notificações, gravação de recibos) para que problemas apareçam rapidamente.
Se usa uma abordagem de plataforma, priorize recursos operacionais que vai precisar na prática — deploys repetíveis, separação de ambientes e rollback. (Por exemplo, Koder.ai oferece deploy/hosting mais snapshots e rollback, o que pode reduzir risco enquanto vocês iteram nos fluxos internos.)
Upgrades comuns: anúncios multilíngues, templates reutilizáveis e integrações (Slack/Teams, email, sincronização com diretório de RH).
Um recibo de leitura responde à pergunta operacional: quem realmente viu (e possivelmente confirmou) uma mensagem crítica. Reduz o trabalho de acompanhamento para itens como mudanças de política, avisos de segurança, fechamentos do escritório e prazos de benefícios, e transforma “enviamos” em “podemos confirmar que foi lido”.
Bons métricas para o v1 são:
read_at (ou acknowledged_at) registrado.Defina metas diferentes por tipo de anúncio (p.ex., urgente/segurança vs. cultura/notícias).
Um escopo sólido para v1 normalmente inclui:
Mantenha “gostaria de ter” (aprovações, templates, reações, análises avançadas) para depois, a menos que sejam realmente necessários já no início.
Comece com papéis claros e permissões explícitas:
Escolha uma definição principal e aplique-a de modo consistente:
Muitas equipes rastreiam ambos: para leituras passivas e para confirmações requeridas.
Use uma tabela dedicada receipts com uma linha por usuário por anúncio:
user_id, announcement_idread_at (nullable)Decida desde o início como edições afetam recibos:
Um padrão prático é armazenar um (ou ) no recibo e limpar somente quando a mudança for marcada pelo publicador como “requer nova confirmação”, mantendo o histórico de auditoria do que mudou e quando.
As opções de segmentação geralmente caem em:
Snapshot mantém os recibos e relatórios estáveis: a audiência é “quem foi alvo na hora da publicação”, não “quem corresponde ao filtro hoje”.
Use SSO (SAML/OIDC) se possível; isso reduz riscos com senhas e alinha-se ao gerenciamento de identidade existente. Independentemente do método de autenticação:
Trate autorização como regra obrigatória no backend, não como indicativo no UI.
Mantenha os recibos úteis sem virar vigilância:
Defina permissões por ação (criar/editar/publicar/arquivar/ver recibos/exportar), não apenas por nome de papel.
read_atacknowledged_atacknowledged_at (nullable)Aplique uma restrição única/index em (announcement_id, user_id) e escreva recibos como upserts para evitar duplicações vindas de atualizações ou múltiplos dispositivos.
announcement_versioncontent_hashacknowledged_atInclua uma nota de privacidade curta e em linguagem simples dentro do app (p.ex., vinculada em /settings).