Publicar o próprio conteúdo pelo módulo: o que quebrou

Por que publicar o próprio conteúdo pelo módulo

Software de marketing é vendido com demonstração, e demonstração é o ambiente onde tudo funciona: um post, um criativo, um clique.

Operação real é outra coisa: vinte e uma publicações, três semanas, criativo para cada uma, e a pressa de uma data que não se move. Foi assim que usamos o módulo de Publicações do Mineer para publicar o conteúdo do Mineer, em setembro de 2026.

Achamos três problemas em dois dias. Nenhum deles aparece numa demonstração, e os três valem mais escritos do que escondidos.

1. A série cria publicação que não pode ser aprovada

O módulo tem séries recorrentes: você define cadência e briefing, e ela materializa rascunhos no calendário, com a legenda escrita por IA.

Doze séries rodando geraram 283 publicações. Nenhuma podia ir ao ar.

O motivo é estrutural: a série escreve a legenda e não anexa criativo. Mas a aprovação valida a quantidade de mídia contra o formato — carrossel exige de 2 a 10 itens, feed e story exigem 1. Toda publicação nascida de série tinha zero.

O resultado é um calendário cheio que parece produtividade e é dívida: 283 rascunhos, e 332 vínculos manuais de criativo para torná-los publicáveis.

2. Cadência que enche o feed mais rápido do que se aprova

As doze séries somavam 28 publicações por semana — quatro por dia, em cinco faixas de horário. Somadas a uma linha editorial de uma por dia, davam cinco.

Nenhum perfil de empresa pequena sustenta cinco posts por dia, e nenhum time aprova isso. Reduzimos para 13 por semana mexendo só na frequência, sem apagar série nenhuma.

E aqui apareceu um detalhe que muda o planejamento de qualquer um: a materialização é idempotente e trabalha num horizonte de 30 dias. Ou seja, reduzir a cadência não limpa o que já foi criado — vale para a frente. O calendário do mês seguinte continuou cheio, e foi preciso decidir o que fazer com o acervo.

3. O erro que foi nosso

O terceiro não foi do produto.

Uma publicação tinha ficado com o criativo errado. Trocamos, o formulário mostrou a arte nova, salvamos, e demos por resolvido. Dois dias depois, alguém abriu a publicação salva: a arte antiga continuava lá.

A edição não tinha persistido, e nós tínhamos conferido no formulário — que mostra o que você acabou de digitar, não o que o servidor gravou.

A regra que ficou: conferir no registro salvo, nunca na tela que você preencheu. Vale para qualquer sistema, e é o tipo de coisa que só se aprende depois de afirmar que estava feito.

Calendário de publicações: o que sai, quando, e o estado de cada uma antes da aprovação.

O que mudamos na operação

1. Séries pausadas até conseguirem anexar arte. Pausar preserva briefing e cadência; é reversível.
2. Uma publicação por dia, com copy e criativo feitos um para o outro.
3. Criativo antes do perfil, no formulário — porque voltar da biblioteca limpa o campo de perfil.
4. Conferência no registro, nunca no formulário.
5. Acervo descartado. 283 rascunhos com copy repetida e sem arte não viram conteúdo bom; viram trabalho.

Quem for repetir o caminho: a peça sai do Estúdio de Design com o brand kit preenchido, e o destino dela precisa da landing page com LGPD em ordem. O módulo está em Marketing.

O que isso diz sobre usar o próprio produto

A parte desconfortável de publicar este post é que ele lista defeitos de um software que a gente vende.

A parte útil é que os três foram achados por nós, em dois dias, porque estávamos operando de verdade — e não por um cliente, em produção, com a marca dele em jogo.

Software de gestão que a própria empresa não usa para operar tem um tipo específico de problema: ele funciona na demonstração e trava no décimo quinto item. Só se descobre isso usando.

Referência rápida