Documentação de operações de marketing: o que registar e onde entram as alterações

O que é a documentação de operações de marketing?

A documentação de operações de marketing é tudo aquilo de que um novo elemento da equipa precisaria para gerir o marketing sem ter de perguntar: como as ferramentas estão ligadas, como se faz o trabalho recorrente, que regras se aplicam e o que mudou e quando. Menos manuais extensos, mais páginas curtas, fáceis de encontrar e atualizadas.

Quase todas as equipas já têm partes disto espalhadas por uma wiki, uma pasta partilhada, as definições das plataformas e a memória das pessoas. O problema surge em três momentos: quando alguém entra na equipa, quando uma conta muda de mãos e quando um cliente ou a direção pergunta porque é que os resultados mudaram. A Forrester resume o primeiro caso de forma direta: a última coisa que um novo colaborador deveria estar a fazer é andar a clicar na plataforma de automação para perceber como funciona.

Pense em quatro camadas: referência (o que existe), procedimento (como fazer o trabalho recorrente), regras (o que todos cumprem) e histórico (o que mudou). A maioria das equipas escreve as três primeiras e esquece a quarta, que é precisamente a necessária quando uma métrica cai.

O que deve uma equipa de operações de marketing documentar?

Documente o que é difícil reconstruir de memória e o que estraga os resultados quando duas pessoas o fazem de forma diferente. A tabela seguinte é um ponto de partida prático; cada linha deve ter um responsável identificado e um motivo claro para ser atualizada.

A lista da Forrester vai no mesmo sentido: aponta os programas de scoring, nutrição e atribuição de leads, os processos de relatório e as funções como o que deve ficar escrito fora das plataformas. As convenções de nomes merecem uma página própria, porque uma mudança de nome silenciosa divide um relatório em dois; veja o nosso artigo sobre convenções de nomes de UTM para um modelo.

Como escrever um runbook de marketing que a equipa use mesmo?

Escreva um runbook por tarefa recorrente, pela ordem em que alguém a faria, com as verificações que provam que correu bem. Se um passo depende de critério pessoal, indique quem decide. Sempre que possível, que caiba num ecrã.

1. Nomeie a tarefa e o responsável
2. Liste os passos por ordem
3. Junte a verificação de cada passo
4. Indique o que registar no fim

Um bom runbook para um aumento de orçamento, por exemplo, indica onde alterar o valor, o aumento máximo acordado pela equipa, o que verificar na manhã seguinte e que a alteração entra no registo com o motivo. Este último passo é o que transforma um procedimento em histórico que se consegue ler mais tarde.

O manual de incidentes da Atlassian descreve playbooks que reúnem runbooks, checklists e modelos para que a equipa responda sempre da mesma forma. A ideia aplica-se ao marketing: uma pasta por processo, páginas curtas e uma ligação para o sítio onde o resultado fica registado. Os runbooks também facilitam a mudança de agência; a nossa checklist de transição de agência lista o que entregar.

Onde entra o registo de alterações na documentação?

O registo de alterações é a camada de histórico: guarda o que aconteceu de facto, enquanto os runbooks e as regras descrevem o que deveria acontecer. Sem ele, a documentação ensina a lançar uma campanha, mas não explica porque é que as conversões caíram em março.

Cada plataforma guarda uma parte desse histórico. O Histórico de Alterações do Google Ads mostra as alterações dos últimos 2 anos, com o email de quem editou na interface e entradas como "Google Ads system" para as automáticas. O Google Tag Manager mantém um histórico de publicação com quem publicou cada versão e permite dar nome e descrição à versão. O GA4 permite a utilizadores com a função de Analista ou superior criar anotações (título de 60 caracteres, descrição de 150, até 1000 por propriedade). Nenhuma vê as outras, nem as alterações na landing page, no CRM ou nos preços.

Por isso, o registo fica acima de todas: uma entrada por alteração, com data, plataforma, responsável, motivo e efeito esperado. O nosso guia do registo de alterações de marketing explica o formato e o modelo de registo de alterações dá-lhe as colunas para começar.

Exemplo: na quarta-feira, um cliente pergunta porque é que os leads caíram na terça. Os runbooks mostram que os lançamentos seguiram a checklist, por isso a equipa abre o registo. Lá estão uma redução do CPA alvo no Google Ads na sexta, um novo formulário na landing page no sábado e uma versão do GTM publicada na segunda. O formulário tinha perdido o redirecionamento para a página de agradecimento e o evento de lead deixou de disparar. No CRM, os leads mantinham-se; só a contagem medida caiu.

Como isolar a alteração que causou a queda com a documentação?

Use a documentação por uma ordem fixa: confirme o tracking com o plano de tracking, liste todas as alterações dos dias anteriores à queda e teste uma hipótese de cada vez. O mapa de ferramentas diz onde procurar; o registo diz o que mudou.

1. Exclua primeiro o tracking. Compare o número da plataforma com a fonte de referência definida no plano de tracking (CRM, encomendas, formulários submetidos). Se só um dos lados caiu, é um problema de medição.
2. Reúna todas as alterações do período. Retire do registo os 7 a 14 dias antes da mudança e preencha as lacunas com o Histórico de Alterações do Google Ads e a lista de versões do GTM.
3. Compare com os runbooks. Uma alteração feita fora do procedimento (sem verificação no dia seguinte, sem motivo registado) é a principal suspeita.
4. Teste uma hipótese de cada vez. Reverta ou segmente pela alteração mais suspeita e acompanhe a métrica, em vez de desfazer tudo ao mesmo tempo.

Com todas as alterações numa única cronologia, o exemplo acima resolve-se em minutos: a versão do GTM surge um dia antes da queda, logo depois da mudança no formulário, e é aí que se olha primeiro. O Changeline mantém essa cronologia por projeto de cliente: as alterações do Google Ads podem ser importadas automaticamente através de uma ligação só de leitura, e a equipa regista o resto (site, tracking, CRM, preços) com responsável e motivo. Para o método completo, veja o guia sobre como explicar uma queda de conversões ao cliente.

Como manter a documentação de operações de marketing atualizada?

Associe cada documento ao acontecimento que o torna obsoleto e faça da atualização parte da conclusão da tarefa. A documentação fica desatualizada quando vive à parte do trabalho; mantém-se atual quando o último passo de cada tarefa é atualizá-la.

Três hábitos resolvem a maior parte. Primeiro, um responsável identificado para cada página, para que "alguém tem de atualizar isto" tenha resposta. Segundo, uma revisão curta com ritmo fixo: mensal para o registo e o plano de tracking, trimestral para runbooks e funções. Terceiro, a regra de que nenhuma alteração entra em produção sem registo: quem altera o orçamento, a tag ou o formulário escreve uma linha com o motivo.

Se já tem um processo de revisão, o nosso artigo sobre gestão de alterações no marketing mostra como acrescentar aprovações sem atrasar lançamentos, e o artigo sobre post mortem de campanhas mostra como transformar uma má semana em runbooks melhores.