CTA com formulário de captura

Seção de conversão em duas colunas sobre foto esmaecida. À esquerda, o argumento: olho, título, apoio e lista de benefícios — e ele acompanha a rolagem, para não sair de vista enquanto a pessoa preenche. À direita, um card de vidro com o formulário: três campos de texto, um select customizado, botão e nota de consentimento.

⚠️ O envio é só front-end

O script valida, trava o formulário e mostra a mensagem de sucesso — mas não manda nada para lugar nenhum. Publicar assim significa perder todos os leads em silêncio, com o visitante achando que deu certo. Ligue o bloco marcado ENVIO no script.js a um endpoint real antes de subir. É por isso que o status é revisar.

Quando usar

• Fecho de landing ou de home de serviço de alto ticket, onde a conversão é uma conversa, não uma compra.
• Quando existe uma oferta concreta de entrada: diagnóstico, auditoria, análise, proposta.

Quando não usar

• Como formulário de contato genérico. Aqui a promessa é específica; "fale conosco" não justifica 4 campos.
• Quando a conversão é WhatsApp. Aí o navegacao/botao-flutuante e um botão grande convertem mais.
• Mais de 5 campos. Cada campo a mais derruba a taxa; se o time comercial pede 8, a resposta é qualificar na ligação.

Padrão editorial

O requisito de qualificação em cima do formulário economiza o tempo dos dois lados. Parece que afasta lead; na prática afasta lead errado.

Especificação da imagem

• Paisagem, mínimo 2000×1400, até 400 KB.
• Entra em opacity:.2 com gradiente por cima: é textura, não assunto. Escolha por atmosfera, não por detalhe.

Como usar

<link rel="stylesheet" href="componentes/conversao/select-custom/estilo.css">
<link rel="stylesheet" href="componentes/conversao/cta-formulario-lead/estilo.css">
<script src="componentes/conversao/select-custom/script.js"></script>
<script src="componentes/conversao/cta-formulario-lead/script.js"></script>

Este componente compõe o conversao/select-custom — carregue os dois. O select usa o .lead-field como wrapper, então o bloco .csel-field do CSS dele fica sem uso aqui (pode ficar; não conflita).

Ligando o envio

No script.js, o bloco marcado ENVIO chama sucesso() direto. Troque por:

fetch('/api/lead', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify(Object.fromEntries(new FormData(form)))
}).then(sucesso).catch(erro);

Falta um estado de erro visual — hoje existe só o de sucesso. É o segundo motivo do status revisar.

Variações

• Sem foto de fundo — apague .lead-media.
• Formulário sozinho — apague .lead-intro e centralize o card em max-width:560px. Para página de obrigado ou landing curta.

Gotchas

• .lead-intro é sticky. Em tela baixa o formulário é mais alto que a viewport; sem isso o argumento sai de vista enquanto a pessoa preenche. No mobile volta a static, senão o texto gruda por cima do formulário.
• gap:0 26px nos campos — zero na vertical. O respiro entre linhas vem do padding do próprio campo; com gap vertical, a régua de um campo fica longe demais do seguinte.
• Campo com régua embaixo, não caixa. Menos peso visual dentro de um card que já é de vidro.
• novalidate no <form> é proposital. A validação nativa mostraria um balão do sistema, que destoa de tudo — a validação aqui é manual e o foco vai para o campo vazio.
• O select obrigatório valida separado. Ele não tem :invalid nativo: a checagem é pelo input[type=hidden] dentro de [data-csel-required], e o retorno é o tremor.
• role="status" na mensagem de sucesso faz o leitor de tela anunciar sem mover o foco.
• O .grain dentro do card precisa dos filhos em z-index:1. Ele é position:absolute e cobriria os campos.

Histórico

Normalizações aplicadas na extração: prefixo único lead-; .cfield → .lead-field, .full → .is-full, .on → .is-on; ids → [data-lead-form] / [data-lead-ok], permitindo mais de um formulário na página; o vidro virou a primitiva .glass; cores cruas → tokens, com color-mix no fundo do aviso; adicionado role="status"; o bloco de envio virou um ponto de extensão marcado, em vez de um comentário solto no fim.

Divergências e pendências: o envio continua sem backend (herdado da origem) e não há estado de erro visual. Enquanto isso não for resolvido, o componente fica em revisar.