A maioria dos processos de aprovação falha do mesmo jeito. Ninguém discute a ideia. Aí um revisor some por dois dias, três publicações perdem o horário e alguém pergunta se pode simplesmente publicar por conta própria.
Por isso este texto fala menos de ligar as aprovações e mais de conduzi-las: quem revisa o quê, quanto tempo uma revisão deve levar e o que acontece naquela quinta-feira de manhã em que a aprovação chega depois do horário. Se você só quer ver o que o recurso faz, a página do fluxo de aprovação serve para isso. Aqui partimos do princípio de que você já decidiu usá-lo.
Uma ressalva antes. As aprovações são para pessoas da sua equipe, cada uma com um assento. Se quem revisa é um cliente sem conta, use um link de revisão, explicado em como conseguir feedback de clientes nas publicações.
Um exemplo completo: três pessoas, um cliente
Pense numa agência pequena no plano Pro, que tem três assentos.
- Maya é a dona da conta e cuida da cobrança.
- Dev é o aprovador. Ele conhece as regras de marca do cliente e os pontos sensíveis do ponto de vista jurídico.
- Sam é colaborador. Ele escreve e agenda a maior parte das publicações do cliente.
Na terça à tarde, Sam escreve uma publicação anunciando a liquidação de primavera do cliente e a agenda para quinta às 9:00. Como é colaborador, o botão diz Submit for Approval em vez de Schedule. A publicação é salva com o horário de quinta, mas ganha a etiqueta Awaiting approval e não sai até alguém liberar.
Dev recebe uma notificação. Na quarta de manhã ele abre a publicação e vê que a liquidação termina no domingo, não no sábado. Ele a rejeita e escreve o motivo: “A liquidação termina domingo às 23h59, não sábado.” A publicação volta para os rascunhos com a etiqueta Rejected, e Sam vê o recado do Dev no topo do compositor quando a abre.
Sam corrige a data e agenda de novo. Isso conta como um reenvio, então ela fica pendente outra vez e Dev é notificado de novo. Na quinta às 9:20, vinte minutos depois do horário, Dev chega nela. Esse é o caso incômodo. Como o horário passou há mais de 15 minutos, Dev precisa escolher: Approve and publish now ou Approve and pick a new time. Dev sabe que o e-mail da liquidação saiu às 9:00, então publica agora.
Se tivesse aberto às 9:10, dentro da janela de 15 minutos, aprovar teria publicado na hora, sem pergunta nenhuma.
Três coisas dessa história valem ser copiadas: a rejeição veio com motivo, o revisor era uma pessoa com nome e não “quem ver primeiro”, e a regra das aprovações atrasadas era conhecida de antemão.
Decida quem revisa o quê
A pergunta não é “quem é mais sênior”. É “quem ficaria mais constrangido se isso saísse errado”.
| Se o risco é… | O revisor deve ser… | Por quê |
|---|---|---|
| Voz e tom da marca | Um aprovador do time de conteúdo | Avalia em segundos e publica as próprias postagens direto |
| Afirmações jurídicas, de preço ou reguladas | Um administrador ou o dono | Alguém que responde pelo que está sendo afirmado |
| Precisão para o cliente | O responsável pela conta, como aprovador | O mais próximo dos fatos reais do cliente |
| Redatores novos | Seu colega mais experiente, como aprovador | As revisões também servem de treinamento |
Aprovadores podem publicar direto, então quem tem esse papel não espera ninguém. Só os colaboradores passam pela barreira, e leitores não conseguem criar publicações. A lista completa de papéis está em como convidar a equipe e definir papéis.
Nomeie pelo menos duas pessoas que possam aprovar. Com um revisor só, um dia de atestado vira congelamento de conteúdo.
Defina um prazo antes de montar o fluxo
Escolha um número e diga em voz alta. “Em até um dia útil” basta para conteúdo planejado.
Depois conte de trás para frente. Se uma revisão pode levar um dia, nada deve ser enviado com menos de um dia de antecedência. Uma convenção simples: enviar até o fim do dia anterior. O que chegar depois é um favor pedido, e todo mundo deve saber disso.
Quando uma revisão atrasa mesmo assim, a regra dos 15 minutos é uma rede de segurança, não um plano. Passado esse ponto, alguém precisa escolher entre publicar atrasado e reagendar, e essa não é uma decisão para um revisor tomar às 9:20 com o cliente esperando.
Escreva rejeições que fechem o ciclo
A nota de rejeição é o único retorno que o autor recebe no momento em que ele importa. Pode ter até 2.000 caracteres e é opcional, então é fácil deixar em branco. Não deixe.
- Ruim: “Não é isso.”
- Melhor: “Comercial demais para esta conta. Comece pela história do cliente e deixe o desconto para a última linha.”
- O ideal: a versão melhor, mais o que faria a publicação ser aprovada, para que o próximo envio seja o último.
Rejeição também não é veredito. A publicação volta para os rascunhos, o autor edita e agenda de novo, e ela volta para revisão. Pense nisso como uma rodada, não como uma recusa.
Erros comuns
Colocar barreira em tudo. Se cada resposta rápida e cada republicação esperam aprovação, os revisores passam a aprovar sem ler. Reserve a barreira para conteúdo planejado, voltado ao cliente ou regulado. Deixe os aprovadores publicarem direto o que é reativo.
Um aprovador só, sem reserva. Já falamos disso, e é a razão mais comum de um fluxo ser abandonado em silêncio.
Editar depois da aprovação sem perceber. Se um colaborador altera uma publicação aprovada e agenda de novo, ela precisa de aprovação outra vez. É de propósito. Avise as pessoas, ou elas vão achar que a ferramenta está quebrada.
Esquecer a automação. Agendamentos recorrentes e feeds RSS criados ou editados por alguém sem permissão para publicar passam a exigir aprovação, mesmo que a pessoa tente desligar. Quem pode publicar consegue desligar de novo. Se você está se perguntando por que as publicações de um feed estão esperando, comece por aí.
Usar aprovações para clientes. Clientes sem assento não podem ser aprovadores, e dar um assento só para aprovar gasta um dos seus três ou dez.
Supor que as notificações chegam igual para todos. Os avisos de aprovação seguem as configurações de notificação de cada pessoa: no app, por e-mail ou no celular. Um aprovador que silenciou o e-mail pode nunca ver um pedido. Peça que ele confira uma vez.
Agentes e integrações
Se scripts ou assistentes de IA criam publicações para você pela API, é possível criar uma publicação com requestApproval como true mesmo que o dono da conta pudesse publicar direto. Ela então espera como a de um colaborador, e uma pessoa decide. É o jeito mais simples de deixar a automação preparar sua semana sem publicar nada sem controle.
Lista de configuração
- Conte seus assentos. O Free tem 1, o Pro 3 e o Business 10, e convites pendentes contam para o limite.
- Convide as pessoas e dê a cada uma o menor papel que permita fazer seu trabalho. Colaboradores para quem escreve, aprovadores para quem revisa.
- Nomeie pelo menos duas pessoas que possam aprovar.
- Combinem um prazo de resposta e um horário-limite de envio.
- Decida qual conteúdo pula a barreira e avise os aprovadores de que podem publicá-lo direto.
- Faça uma rodada de teste: envie uma publicação, rejeite com um motivo, reenvie e aprove.
- Confirme que cada aprovador realmente recebe a notificação.
Os preços do Pro e do Business estão na página de preços. O processo de aprovação funciona do mesmo jeito em qualquer plataforma de destino.
E agora
Comece com um cliente ou um conjunto de canais, use por duas semanas e veja onde as publicações travam. Aperte o prazo ou adicione um segundo aprovador antes de ampliar a barreira. Quando estiver pronto, comece grátis e convide colegas quando passar para o Pro.