RC Business

Contexto

RC Business é uma empresa de treinamento em desenvolvimento profissional e gerencial, em Juiz de Fora, e foi onde comecei minha carreira. Entrei em fevereiro de 2022 como desenvolvedor front-end e fiquei até novembro de 2024 — quase três anos em que entreguei 14 sites, quase todos landing pages e funis de captura para as ofertas da própria empresa e de parceiros ligados a ela: imersões, consultorias e eventos.

Este case não é sobre um site: é sobre o padrão que se repetiu nessas entregas — e sobre a operação de mantê-las no ar depois do deploy. Dois projetos aparecem como exemplo nas seções abaixo: o funil da imersão Dono Sniper (Acelerador Pessoal) e a página de consultoria do Alessandro Balbino.

O problema

O problema se repetia com nomes diferentes: uma oferta com tráfego pago precisa de uma página que capture, integre e venda — em prazo curto, com conteúdo que muda a cada campanha. Cada item abaixo decidia se a campanha funcionava:

• fricção de entrada: o público vem de redes sociais, muitas vezes pelo celular; cada campo a mais no formulário é uma inscrição a menos;
• o lead precisa chegar inteiro: nome, e-mail e telefone têm que cair direto na ferramenta de e-mail, com a origem da campanha (UTM) preservada — sem planilha no meio;
• a venda não mora no site: o checkout precisa ser confiável e resolver pagamento, garantia e reembolso fora da página;
• as obrigações: política de privacidade, página de obrigado com o próximo passo, domínio próprio;
• e a página longa: uma operação com várias ofertas ao mesmo tempo perde o visitante no meio da rolagem — a ordem das seções passa a ser parte do trabalho.

Como foi construído

O padrão da casa, repetido a cada entrega:

• três páginas por funil — captura, obrigado e política de privacidade — montadas no Builderall, com rodapé compartilhado e âncora direta para o formulário;
• templates validados em campanhas anteriores: a estrutura da página e a ordem das seções já tinham trazido lead; o trabalho era ajustar ao conteúdo de cada oferta, não redesenhar o caminho;
• captura integrada ao MailingBoss: nome, e-mail e telefone obrigatórios na lista da campanha, com campos ocultos de UTM para cada inscrição chegar com a origem identificada, pronta para as automações;
• pixels do Facebook por comportamento: um pixel para cada tipo de sinal — pageview, lead e compra — com subdivisões como lead via WhatsApp e lead via formulário, para a campanha saber onde cada conversão nasceu;
• mb_tag_matcher: webhook serverless que eu escrevi para casar a classificação do lead no CRM com o público personalizado do Facebook — a etiqueta do MailingBoss vira segmentação de campanha;
• checkout pela Kiwify: os CTAs da página apontam direto para o pagamento, sem nada de transação dentro do Builderall;
• página de obrigado com próximo passo explícito: barra de progresso e entrada no grupo de WhatsApp — o funil não termina na inscrição;
• layout mobile configurado à parte, bloco a bloco: é onde a campanha chega primeiro.

Exemplo 1 — Acelerador Pessoal (imersão Dono Sniper)

O funil que mais longe foi, e o único em que a campanha também passou pela minha mão:

• criativo e anúncio sob minha responsabilidade: a peça criativa, a criação dos pixels do Facebook e o acompanhamento da campanha que trazia tráfego à página — o funil começa antes do formulário;
• resultado: 3 páginas, 2 integrações, tráfego de 100 para 420 visitantes e leads de 2 por semana para mais de 2 por dia.

Exemplo 2 — Alessandro Balbino / AGMV Consultoria

Uma página de oferta única, de outro tipo: sem data de evento, e sim um serviço — a consultoria In-Company AGMV.

• o serviço em módulos numerados: mentalidade, administração, gerência, marketing digital e vendas — cada bloco diz o que a equipe do cliente vai aprender; a numeração dá ritmo à rolagem;
• autoridade no meio da página: quem é Alessandro Balbino — trajetória, livro e prêmios — logo depois dos módulos, sustentando a decisão de contratar;
• mobile primeiro de verdade: numa página desse tamanho, quem chega do Instagram rola muito — o ajuste bloco a bloco foi o que decidiu a leitura.

Decisões e trade-offs

• Builderall em vez de página própria. Publicar e editar rápido valia mais que controle total: o conteúdo muda a cada edição de campanha, e o ajuste saía do editor, não de um deploy. Em troca, o layout fica preso à plataforma e mais pesado que HTML estático — uma troca que eu faria de novo naquele contexto.
• MailingBoss como fonte única do lead. O formulário grava direto na ferramenta de e-mail, com UTM; as automações nascem ligadas. Em vez de capturar “na mão” e sincronizar depois, o dado nasce no lugar certo.
• Checkout fora do site. Pagamento, garantia e reembolso ficam com uma plataforma especializada (Kiwify); a página não carrega nada de transação nem de dados de cartão.
• Um padrão por entrega, não uma página inédita por oferta. O esqueleto — captura, integração, checkout, obrigado — se repetia ajustado ao conteúdo de cada oferta em vez de recomeçar do zero; o tempo economizado ia para o que era específico da oferta.

Qualidade e verificação

Esta fase é de antes da disciplina de verificação que hoje guia o resto do portfólio, e vale ser honesto sobre o que isso significava ao longo de 14 entregas:

• a checagem era manual, de ponta a ponta no navegador: formulário caindo na lista, obrigado levando ao grupo, checkout abrindo — desktop e celular;
• depois do deploy, a operação era enxuta: hospedagem, domínio, correções e melhorias direto no ar, sem staging;
• e o aprendizado dessa fase virou regra nos projetos seguintes: nada é entrega sem uma forma de verificar que funciona. Foi ali que o custo de não ter essa forma ficou claro.

Resultados

Quase três anos e 14 sites entregues, entre landing pages de evento, funis de captura e páginas de venda — dois deles continuam publicados e são os que este case usa como exemplo. No funil do Acelerador, os números acompanharam o trabalho: o tráfego subiu de 100 para 420 visitantes, e os leads passaram de 2 por semana para mais de 2 por dia.

Para além dos números, foi o primeiro contato real com o ciclo completo de uma entrega web: construir, publicar, operar e melhorar depois do “pronto”.

O que aprendi

• Um funil não termina no formulário. O próximo passo — grupo, e-mail, checkout — é parte do design, não um extra.
• Um padrão que se repete é entrega, não preguiça. O mesmo esqueleto de funil, ajustado a 14 ofertas diferentes, transformou cada projeto novo em ajuste em vez de recomeço.
• Plataforma especializada rende mais que código próprio quando o objetivo é velocidade: captura e pagamento ficaram com ferramentas que fazem só isso, bem.
• Operação é metade do trabalho. Publicar é o começo; a diferença entre uma página boa e uma página que vende está em corrigir e iterar depois que o tráfego chega.