Dashboards simples para monitorar sua esteira de conteúdo
Como acompanhar ideias, rascunhos, traduções, builds e publicações sem transformar sua operação editorial em um painel complexo demais.
Uma esteira de conteúdo não quebra de uma vez. Ela começa a quebrar em silêncio.
Uma ideia fica parada sem dono. Um rascunho nasce sem fonte. Uma tradução é gerada, mas não revisada. Um post é publicado em português, mas as versões em inglês e espanhol ficam esquecidas. Um deploy falha, ninguém vê, e o site continua parecendo normal até alguém perceber que a última publicação não entrou.
É por isso que dashboards simples importam. Não para criar mais uma tela bonita, mas para enxergar gargalos antes que eles virem dívida operacional.
O que é saúde editorial
Saúde editorial não é publicar todos os dias. Também não é ter uma lista enorme de ideias.
Para mim, uma esteira saudável é aquela em que cada item tem estado claro, próximo passo visível e baixo risco de ficar esquecido.
Isso vale tanto para um blog pessoal quanto para uma rede de sites. A diferença é que, em uma rede, o erro escala mais rápido. Se o processo depende de memória, abas abertas e mensagens soltas, ele funciona enquanto o volume é pequeno. Depois vira ruído.
Uma operação saudável responde perguntas simples:
- quantas ideias estão aguardando triagem?
- quantos textos estão em revisão?
- quais posts já têm versão PT, mas ainda não têm EN e ES?
- quais builds falharam?
- quais fontes precisam ser conferidas?
- quais conteúdos estão prontos, mas ainda não foram publicados?
Se eu não consigo responder isso em poucos minutos, o problema não é falta de produtividade. É falta de visibilidade.
Métricas que importam
O erro comum é começar pelo dashboard ideal. Gráficos, filtros, cores, rankings e telas complexas. Quase sempre é cedo demais.
Eu começaria com métricas operacionais, não vaidosas.
As primeiras seriam:
- Ideias por status: sugerida, aprovada, em produção, em revisão, publicada, rejeitada.
- Tempo parado por etapa: quantos dias um item está sem mudança de status.
- Cobertura por idioma: PT publicado, EN pendente, ES pendente.
- Falhas de automação: execuções com erro no n8n.
- Falhas de build/deploy: commits que não chegaram ao site.
- Posts sem fontes suficientes: conteúdo técnico sem referência mínima.
- Posts sem relacionamento interno: páginas órfãs dentro do próprio blog.
Essas métricas não servem para impressionar. Servem para decidir a próxima ação.
Um bom dashboard editorial precisa apontar trabalho, não apenas mostrar números.
Um painel simples
Na arquitetura deste laboratório, o painel mais pragmático começa no Baserow.
Ele já pode guardar ideias, status, idioma, prioridade, origem, palavras-chave, URL final e observações. Com algumas views bem desenhadas, o Baserow vira um cockpit editorial simples:
- uma view para triagem;
- uma view para textos em revisão;
- uma view para traduções pendentes;
- uma view para publicações prontas;
- uma view para erros ou bloqueios;
- uma view por projeto ou domínio.
O n8n entra como motor. Ele pode atualizar status, registrar logs, gravar data da última execução, salvar resposta do GitHub API e marcar se o deploy foi disparado.
O Astro continua como camada pública. Ele não precisa saber da bagunça operacional. Ele recebe arquivos válidos e gera páginas estáticas.
Essa separação é importante: painel mostra operação; site público entrega conteúdo.
Alertas antes de dashboards bonitos
Antes de gastar energia em layout de dashboard, eu criaria alertas simples.
Alguns exemplos:
- ideia aprovada há mais de 7 dias sem rascunho;
- post PT publicado sem tradução depois de 5 dias;
- workflow do n8n com erro;
- build do Cloudflare Pages com falha;
- post técnico sem fonte;
- conteúdo marcado como pronto, mas ainda com
draft: true; - canonical duplicado ou ausente.
O alerta certo reduz a necessidade de ficar olhando painel.
Dashboard é bom para revisão periódica. Alerta é bom para exceção. Misturar os dois costuma gerar ansiedade operacional: a pessoa passa a monitorar tela em vez de melhorar processo.
Rotina de revisão
Um dashboard só funciona se existir uma rotina por trás.
Minha sugestão para uma operação enxuta seria:
- segunda-feira: revisar ideias novas e aprovar prioridades;
- quarta-feira: conferir textos em produção e traduções pendentes;
- sexta-feira: revisar publicações, links internos, fontes e falhas;
- uma vez por mês: limpar ideias rejeitadas e revisar pilares editoriais.
Nada disso precisa ser complexo. O objetivo é impedir que a esteira vire um depósito de intenções.
No fim, um dashboard bom não é aquele que mostra tudo. É aquele que mostra o suficiente para você tomar a próxima decisão com clareza.
Para um Systems Builder, essa é a diferença entre apenas produzir conteúdo e construir uma operação editorial que aguenta crescer.