Aula 24 — Onboarding de funcionários no buying clássico

01 Por que não dá pra simplesmente contratar do mercado

Fala, pessoal. Hoje vamos falar sobre o onboarding dos seus funcionários no buying clássico, usando como exemplo o nosso buying de Google Ads.

Você tem várias opções para trazer gente nova, ampliar o time e melhorar a eficiência da empresa. Existe o funil clássico de RH e recrutamento, que a gente já analisou, no qual você tenta achar os melhores especialistas, integrá-los nas posições correspondentes, pegar os melhores do mercado e por aí vai.

Mas a verdade é a seguinte: nem em toda fonte de tráfego e vertical — principalmente em certas combinações das duas — é possível contratar bons especialistas do mercado de forma contínua, mesmo usando um monte de recurso de RH e vários funis de recrutamento. E mais: mesmo quando você consegue, nem sempre é a melhor opção nem a melhor decisão, simplesmente porque, dentro de cada subnicho, o grupo de profissionais é muito específico — está concentrada em canais de Telegram, LinkedIn e coisa parecida. É um mercado de profissionais com características muito próprias. E ali existe uma escassez enorme de profissionais: especialistas fortes são poucos. E mesmo os bons profissionais costumam ter experiência restrita a contextos muito específicos.

Vou explicar com o Google. Tem o PPC, tem outros sources, tem o Demand Gen. Se no PPC em geral tem bastante buyer forte, no Demand Gen a situação no mercado é a seguinte: buyers fortes, que conseguem entregar volume mês após mês, que não são "papo-furado", que são gerenciáveis, que têm mentalidade voltada à adaptação e não a chorar nos chats, que tiveram experiência que não seja cripto ou algum histórico em operações black (fora das regras das plataformas) — esses são pouquíssimos. Em gambling, por exemplo, quase não existem.

Primeiro: times que rodam Demand Gen em gambling de forma constante devem ser uns 20, 30. E os que existem são compostos por poucos buyers, talvez até 10. Ou seja, no nicho inteiro, falando por alto, eu acho que tem até 500 pessoas que conseguem trabalhar com Demand Gen — possivelmente até menos — dentro do iGaming, com experiência real nesse source. E a maioria delas está em times pequenos, familiares.

São muito difíceis de alcançar. Frequentemente não são públicos. E quando são públicos, ali já tem owner por trás — ou seja, é muito difícil chegar neles. Não mantêm LinkedIn, são poucos até nos canais de Telegram. E nem todo canal de Telegram publica vaga.

Aí sobra: ou você tem a sua própria mídia — que foi o que a gente fez, fortalecer a mídia própria do time —, ou fica tentando pescar em conversa de chat, onde 95% vai ser lixo, papo-furado, ou caras com histórico tão concentrado em operações black que é inaplicável ao gaming. Além disso, os grades aqui são tão relativos que normalmente todos chegam se dizendo sênior, ou no mínimo middle, quando na prática muitas vezes são pessoas que no Google são junior, e na vertical não têm experiência nenhuma.

Por isso chegamos onde chegamos. A gente tentou contratar e pescar por muito tempo — LinkedIn, conferências, canais, mídia própria — e nada funcionou de verdade em volume. Deu certo talvez algumas vezes, e mesmo assim eram pessoas muito específicas; literalmente uma se adaptou e ficou.

02 A saída: onboarding em cadeia (crescer de dentro)

E o que a gente concluiu depois dessa longa introdução é o chamado onboarding em cadeia. É quando você, forma internamente um especialista para as necessidades específicas da sua operação, do assistente de buyer até o sênior.

Nem sempre isso é relevante. No buying de Facebook, por exemplo, eu acho que não é relevante de jeito nenhum — ali sobra gente. No PPC não é muito relevante. No UAC é mais ou menos, também usamos. Mas em alguns sub-nichos de pessoal específicos, em sources específicos — por exemplo o mesmo Google Demand Gen rodando gambling —, nesses segmentos esse sistema é o principal caminho que encontramos, e é a que consegue te criar um fluxo estável de pessoal, com possibilidade de planejar, escalar e crescer.

Chamamos essa aula de onboarding interno. E aqui é importante entender uma coisa:

Isso só funciona se você já tiver algum núcleo. Podem ser team leads, podem ser seniors. Se você já tem um núcleo no time — algumas pessoas que já conseguem, num nível aceitável pra você, rodar tráfego na fonte e na vertical necessárias, explorar essa fonte ou integrar profissionais fortes —, então esse sistema funciona muito bem.

03 Relembrando: o que é o sistema de esquadrão

O sistema de esquadrão é um sistema onde existe o Sênior, que é o líder de um grupo pequeno — a gente brinca chamando de "meio team lead", mas na prática é um head em formato de microestrutura dentro da empresa. Micromanagement no bom sentido da palavra.

Sênior é o buyer que, primeiro, pela grade de remuneração percentual corresponde ao nível de sênior na nossa empresa; segundo, já trabalhou no mínimo meio ano conosco — ou seja, sabemos que é de confiança (trust), que dá pra confiar nele, que ele bate com os nossos valores e com as soft skills e a cultura da empresa.

O que ele faz:

1. Em primeiro lugar, ele mesmo roda tráfego.
2. Em segundo lugar, ele gerencia o esquadrão: distribui as combinações de campanha (criativo, oferta, GEO e fonte de tráfego), ajuda na adaptação, ajuda a achar soluções para middles e juniors. Ou seja, ele cuida da otimização do processo dentro do esquadrão dele.
3. E recebe um percentual de cada middle abaixo dele — essa é a motivação dele pra compartilhar experiência e expertise, e pra ajudar a espalhar informação entre middles e juniors, e no esquadrão todo.

A gente montou isso, como vocês lembram, por dois motivos: de um lado, otimizar o compartilhamento de informação dentro da empresa — porque isso era um problema quando tínhamos muitos seniors e um buying bem espalhado, tipo 30, 40 pessoas. A gente inventou isso lá atrás no UAC, quando ainda estava começando, e funciona muito bem: acelera o compartilhamento de informação, dá ao buyer motivação para compartilhar, e simplifica um pouco.

A regra dos 7 ± 2

Do ponto de vista do team lead que gerencia o departamento, abaixo dele ficam vários seniors. Quando o seu buying é grande — digamos 6 seniors, 15 middles e mais uns 5 juniors —, para o team lead gerenciar o buying inteiro de forma eficiente… uma pessoa consegue gerenciar no máximo 12 pessoas, sendo que o bom mesmo é 7. Sete mais ou menos dois — 7 é o máximo ideal.

Nesse caso, o team lead passa a ter:

• um círculo próximo — os seniors, com quem ele faz brainstorm, faz call separada, discute as combinações;
• um círculo amplo — middles e juniors, com quem ele também pode fazer call, orientar e ajustar a remuneração, fazer qualquer remanejamento de pessoal.

Mesmo assim, o círculo próximo é o que o ajuda a resolver questões de forma mais rápida e eficiente, adaptar, coletar informação e espalhar essa informação. E o sênior, por sua vez, espalha essa informação por todo o esquadrão dele — e é por isso que ele recebe esse incentivo financeiro.

04 As quatro posições e o que cada uma faz

Middle

Faz o mesmo que o sênior, mas não entra no chamado conselho estratégico (que é team leads + seniors). Ele não gerencia seniors. Pode receber percentual de middles. Ele busca novas combinações, testa hipóteses, faz onboarding de juniors e escala as combinações atuais.

Junior

A diferença dele, além da grade de percentual: ele lança e escala exclusivamente as combinações atuais. Ele não faz teste de combinação nova, não busca combinação nova, não faz onboarding de ninguém. A tarefa dele é escalar o que já existe, sobre o qual já existem métricas claras — e, escalando, bater os KPIs necessários dentro dessas métricas.

Assistente de buyer

É essencialmente a porta de entrada do esquadrão. A tarefa dele é aliviar a carga de trabalho do buyer e passar no teste de execução de instruções (já explico o que é). É mais um estágio de onboarding do que uma posição de verdade.

Sênior

Tudo do middle + ajuda no onboarding de juniors, desenvolvimento dos middles e otimização do esquadrão.

05 Assistente de buyer — o perfil (o teste com dois grupos que a gente fez)

O assistente de buyer é a primeira posição, onde entra o funcionário novo, o futuro buyer. De quem a gente recruta esses caras? Falando de Google, tínhamos duas hipóteses:

Hipótese 1 — pegar do farm. Já tínhamos farmers (profissionais que preparam contas de anúncio), e a gente via que os farmers eram razoavelmente adequados: conseguiam cumprir as metas seguindo instruções, já eram remunerados, já tinham passado por alguns KPIs com sucesso, já recebiam salário nosso. Ou seja, já existe uma relação com a gente, entendemos mais ou menos os softs deles, sabemos que conseguem executar trabalho manual de forma adequada, já lançaram alguma campanha de aquecimento, passaram por verificações. Já existe alguma expertise. Em tese, poderiam virar buyers.

Hipótese 2 — pegar especialistas em tráfego de operações white. Ou seja, caras que já tiveram experiência no source relevante pra gente, só que em agências e empresas do mercado white, com publicidade dentro das regras das plataformas.

Tinha outras hipóteses, mas paramos nessas duas. Testamos dois grupos de candidatos (duas coortes). E o resultado:

Da coorte de farmers não sobrou ninguém no momento da transição pra junior. A coorte de especialistas em tráfego de operações white mostrou resultado — inclusive um deles mostrou resultado excelente e hoje é sênior.

Depois desse teste de coorte, paramos no perfil do especialista em tráfego de operações white, que é o que a gente escala pra junior.

Por que especialista em tráfego white e não farmer

Com farmer, o único critério que você tem pra saber se a pessoa é relevante ou não é a adequação e a lealdade dela. Ou seja: o quanto ele fisicamente consegue executar o trabalho com as mãos — uma certa capacidade de trabalho —, adequação em termos de comunicação e de execução de tarefas conforme as instruções (mandou, fez), e alguma lealdade à nossa empresa (a gente entende que ele gosta da gente e que a relação é boa). Só por esses princípios a gente conseguia "recrutar" gente pra promoção.

Com especialista em tráfego de operações white, apareciam muito mais dados de entrada:

1. Dá pra olhar se a pessoa já teve experiência no source relevante — Demand Gen, UAC (mais raro, é difícil achar um profissional do mercado white que tenha rodado UAC), Performance Max/PMAX, PPC (desses tem bastante). Isso já é uma triagem.
2. A questão do ferramental. Quando a gente for promover a pessoa de assistente pra buyer, ele vai ter que dominar uma série de skills e uma quantidade absurda de informação nova. O farmer normalmente não sabe nada disso — mesmo tendo lançado campanha de aquecimento, ele conhece link, configuração básica de campanha, vincular cartão à conta, e mais nada. O especialista em tráfego de operações white já conhece muito bem a interface, o ferramental, as regras automáticas, o sistema. Os métodos que ele usava antes não se aplicam em 95% dos casos; nesse aspecto, a experiência anterior não serve para a nova operação — mas ele já entende todo o ferramental, o significado de cada coisa, a interface. E muitas vezes tem domínio técnico do painel de anúncios melhor até que buyers fortes. E isso acelera o onboarding.
3. Dá pra olhar se a pessoa trabalhou em empresa com processos estruturados ou não. Se sempre foi um freelancer solo pegando pedido, é uma coisa. Se trabalhou em agência grande, em media buying interno, mesmo numa operação white, é excelente — porque é gente que provavelmente sabe trabalhar de forma consistente, entregar relatório de marketing, participar da daily. Com farmer é outro tipo de trabalho: é muito mais baseado em cumprir instruções, é completamente diferente. Com o especialista em tráfego você tem um CV pra examinar.

A frase que amarra tudo isso: cada dia de onboarding é dinheiro que a gente paga ao funcionário. Isso custa alguma coisa pra você.

É por isso que o especialista em tráfego de operações white vence: (a) no teste ele simplesmente performou melhor; (b) do ponto de vista pragmático, é menos tempo explicando o painel de anúncios e mais retenção do que foi explicado; (c) você tem mais fatores pra fazer uma triagem melhor antes de integrar a pessoa. E assim você barateia e acelera o seu onboarding.

Resumo do perfil que a gente pega: especialista em tráfego de operações white · experiência de trabalho em empresa · entendimento do source relevante.

06 Assistente de buyer — as funções

6.1. Teste de execução de instruções (um filtro antes de liberar verba)

A primeira coisa que a gente precisa olhar é o quanto a pessoa consegue executar tarefas seguindo instruções claras. Passou a tarefa, ele executa. Isso é importantíssimo.

Porque se a gente já der de cara um treinamento corporativo e disser "toma a grana, testa combinações", muito frequentemente vamos esbarrar numa pessoa que não consegue cumprir nem um item concreto, um pacote de tarefas específico — tipo "configura o cloak assim, faz isso desse jeito". E quando a pessoa não consegue cumprir tarefas concretas e claramente formuladas, sempre vai ter problema pra que ela execute tarefas sistêmicas de forma autônoma depois.

E para nós isso é mais barato. Porque se confiássemos o orçamento de lançamento logo de cara, e a pessoa não consegue nem executar tarefas simples seguindo instruções, ela cometeria muitos erros — e ficaria bem mais caro. O teste desse funcionário seria muito mais caro.

Aqui está a métrica mais importante da aula: o custo de UM middle. Ele é composto pelo tempo de onboarding + o dinheiro que a pessoa queima em cada etapa do onboarding.

Se conseguirmos encurtar o onboarding e, com isso, reduzir o valor pago de base fixa (por exemplo, quanto pagamos ao assistente de buyer), e se conseguirmos fazer com que pessoas que não se adaptam ao trabalho queimem menos dinheiro à toa na etapa de onboarding, a gente tem que fazer isso.

Por isso criamos esse filtro: no assistente de buyer a gente não dá nenhum orçamento, nada. A gente observa se ele consegue cumprir as instruções e se se adapta ao trabalho. Mesmo que seja um especialista em tráfego experiente, ele vai começar como assistente de buyer — a gente precisa verificar se ele consegue cumprir instruções antes de confiar verba a ele.

6.2. Treinamento (as variáveis + a lógica)

Segundo: ele aprende as variáveis. O que são as ferramentas de cloaking, como testar criativos, e se for UAC — o que é o app, o que é naming. Ele aprende todas essas coisas.

E depois, o mais importante: ele aprende a lógica dos lançamentos. Ele acompanha um middle, um sênior ou outro profissional que você designar. Assim, aprende a lógica de lançamento: como funciona o aquecimento, quantas contas são usadas no lançamento, o que se faz em caso de bloqueio, quais variáveis observar e quais ajustar. Em caso de verificação, no que se olha, como se otimiza. Nos cenários de desenvolvimento da campanha — lead caro, não tem tráfego, freeze, custo do lead oscilando — ele também acompanha a análise e anota.

E o entregável desse teste é: a lógica inteira escrita. A lógica do teste, do escalonamento das combinações, da resolução de problemas, da recomposição de variáveis, da otimização de campanha. Tudo, para que ele escreva pra gente a lógica completa como ele a entende.

Quando ele faz isso, entrega para o team lead ou para o sênior, e aí corrigem o que precisa ser corrigido. E se ele cumpriu bem as instruções, se o buyer deu um bom retorno sobre ele, se a gente vê que ele é adequado e que é OK trabalhar com ele em coletivo, e se ele entendeu a lógica — e repara: ele não gastou um dólar sequer —, ele passa.

6.3. Aliviar a carga de trabalho do buyer

Enquanto isso ele alivia a carga de trabalho do buyer: troca campanhas em algum lugar, mexe nas whitepages, ajuda no repasse das conversões, mexe num criativo, corrige alguma coisa. Ou seja, ele faz essa rotina — mas não lança nem otimiza nada por conta própria. A gente coloca ele em combinações medianas, meio moribundas — nunca na combinação principal em que estamos rodando tráfego.

O único dinheiro que a gente dá pra ele é algum salário de período de teste. Só isso.

6.4. E a gente também está olhando outra coisa: a convivência e a rotina

No nível de assistente de buyer a gente já observa a convivência com a equipe, porque ele já está inserido no time.

E tem a rotina. Ele pode ter 30, 50 contas sob gestão. Existem particularidades de como as contas são lançadas, como são controladas. É a rotina de trabalho do buyer. E ele precisa se acostumar a isso. A gente observa o quanto é normal pra ele se acostumar com essa rotina — e dá tempo pra isso. Se ele não sai por conta própria e passa, então está tudo OK: ele atende aos critérios dessa etapa, e passa pro próximo ponto, que é Junior.

07 Junior — escalar, nunca testar

Aqui ele lança e escala as combinações atuais, otimiza as combinações atuais com o objetivo de bater os KPIs necessários — mas não lança novas.

Repare de novo: aqui a gente está otimizando o custo de um middle na saída. Ou seja, aqui a gente não deixa o junior queimar grana em teste, e com isso deixa o funcionário final mais barato.

Ele já entende a lógica, já sabe executar tarefas seguindo instruções claras, já se acostumou à rotina, e a gente já entende que é uma pessoa OK no coletivo. Aí sim se confia orçamento a ele — mas ele não precisa testar. Ele precisa simplesmente escalar o que já funciona. E a gente olha o quanto ele consegue fazer isso de forma eficiente: sozinho, escalar e otimizar as combinações atuais. Tudo em cima do que já funciona, onde já sabemos quais KPIs devem sair — e a gente olha se ele consegue reproduzir.

Se sim, se ele bate os KPIs de forma eficiente, ele passa pro próximo ponto: Middle.

08 Middle-minus — o teste de saída

O que o middle faz? Lança e escala as combinações atuais, otimiza, faz busca de novas combinações, bate os KPIs necessários e ajuda no onboarding dos juniors.

Mas por enquanto ele é middle-minus, porque esse é o teste principal de saída dele — para sair do período de teste. Ele tem um período de tempo definido, com um burn rate definido (ritmo de consumo do orçamento), onde, além de escalar as combinações que já tem, precisa testar e buscar novas dentro daquele burn rate — ou escalar a combinação atual, por exemplo, para um GEO novo ou um produto novo. E aqui a gente olha o quanto a pessoa dá conta de criar combinação e buscar de forma autônoma.

Dá-se a ele um orçamento e um tempo. Dependendo de quão rápido ele queima e quão eficiente ele é nisso, normalmente são 2 semanas, 1 mês, 2 meses e 3 meses — quatro checkpoints, onde a gente olha o quanto ele consegue fazer isso de forma sistemática. Se a gente vê que ele consegue bater o KPI necessário de forma consistente — com o devido ajuste para o source —, então ele vira middle de fato e fica na empresa.

De novo: tudo depende do source. Se o teu Demand Gen simplesmente não roda por 2 meses, não sai da moderação, como aconteceu na primavera — bom, aí me desculpa. Isso você tem que ter previsto no cálculo.

09 O que mais importa: definir o prazo e o custo de cada etapa do onboarding

E agora, o mais importante. O que é preciso entender é o seguinte:

Cada dia de onboarding custa dinheiro.

Você tem que saber, com razoável precisão, quanto tempo vai levar e quanto vai custar cada etapa. Por exemplo:

Como referência da nossa operação, um middle sai do período de teste por volta de cinco meses depois de entrar. A faixa de quatro a seis meses acima é a estimativa geral de adaptação; o prazo de cada etapa precisa ser definido no plano.

Para cada um desses períodos você tem que separar uma quantia clara, composta de:

• base fixa;
• orçamento de teste;
• bônus para o sênior ou middle que ajuda no onboarding (o percentual do esquadrão);
• tempo do team lead;
• os testes e a triagem.

E além disso: o winrate (a taxa de aprovação)

Você tem que considerar quantas pessoas vão cair, quantas você vai eliminar.

Exemplo do próprio palestrante: se de 5 assistentes só 2 passam pra junior, você precisa entender que provavelmente vai pagar salário de período de teste para os 5. E vai pagar um incentivo ao sênior pelo acompanhamento dos cinco também.

Fazendo a conta com números redondos:

• 5 assistentes × US$500/mês de salário no período de teste = US$2.500 (você paga pelos 5, mesmo que 3 caiam)
• + o que você pagou a cada sênior pela ajuda no onboarding — digamos US$1.500 a US$2.000 de incentivo ao esquadrão
• → esses itens somam US$4.000 a US$4.500 só na etapa de assistente

Nota de conferência: a fala arredonda o exemplo para cerca de US$5.000, mas US$2.500 + US$1.500 a US$2.000 somam US$4.000 a US$4.500. O valor de US$10.000 ou mais adiante é uma estimativa do instrutor, com as despesas das etapas seguintes; não é um custo fixo para toda operação.

Aí vem o junior: junior tem orçamento. Um passa, o outro não. Então o custo de um middle-minus não é "o que ele mesmo gastou" — é tudo o que você gastou para adaptar as 5 pessoas no nível de assistente + o salário do junior (que estava numa base fixa + KPI, ou já em percentual) + o orçamento que ele queimou + o tempo do team lead.

Resultado: um único middle sai por US$10.000 ou mais. E ainda fica a pergunta em aberto se ele vai chegar a middle de fato.

Por isso você tem que calcular com muita clareza:

• o custo de um junior;
• o custo de um middle-minus;
• o custo de um middle.

O que influencia esse número, mais uma vez:

1. Como você distribui o gasto com insumos — o custo dos seus buddies, ou seja, das pessoas que ajudam a integrar na empresa (RH + team lead).
2. A duração do onboarding — porque durante esse tempo você paga salário, dá dinheiro pra insumos ou dá orçamento.
3. Os seus testes malsucedidos — as pessoas que no fim das contas queimaram o teu dinheiro na posição de junior ou middle-minus.

Esse é o custo total do teu único middle. E é por isso que em cada etapa é preciso cravar KPIs claros, benchmarks, e contar o dinheiro. E tentar ao máximo otimizar tudo — tanto em despesa quanto em tempo.

É isso. Muito obrigado a todos pela atenção e até a próxima.

📎 Anexo — slides e tradução

As seis imagens recebidas, com o conteúdo traduzido nas legendas. O pacote traz os slides 01–05 e 07 de uma apresentação numerada até 07; a imagem 06/07 não veio no material.