Como usar IA para criar um funil de vendas do zero
Como usar IA para criar um funil de vendas do zero
Gestores comerciais me pedem IA para criar funil de vendas e, na mesa, já chegaram com o slide pronto: topo, meio, fundo, setas coloridas. Eu não parto do canvas. Sistema de registro é o CRM comercial — Pipedrive, RD Station, HubSpot ou Salesforce — porque página de captura não é etapa e ticket de helpdesk não é deal. Percebi, em kickoffs brasileiros, que o time chama de “funil criado” qualquer diagrama que o modelo desenhou em minutos. Portanto o teste cabe na primeira tela: se no fim do desenho o CRM não tem etapas, dono, próxima ação e ID de atividade, não criou funil — só desenhou slide.
Escrevo em primeira pessoa de implementação contratada: o que eu gravo no schema, o que recuso e o que o closer herda quando a regra de entrada fecha. Landing de minutos descreve gerador de página, não o ofício que implanto em semanas, com resultado em 60 a 90 dias. Canal de WhatsApp, se existir, continua sendo envelope, não sistema de registro. Em suma, criar aqui significa gravar colunas, critérios, fatia autorizada do agente e writeback no CRM que a mesa já abre.
O que é criar o funil com IA — e o que ainda é slide ou chatbot
Quem busca a frase literal cai em construtor de captura, quiz em sessenta segundos e prompt que devolve TOFU, MOFU e BOFU. Recorto outro objeto. Criar o schema comercial é gravar etapa nomeada, dono do deal, próxima ação com data e identificador de atividade no CRM. Página, quiz e canvas continuam úteis para tráfego, no entanto nenhum deles prova que o funil existe. Gestor que celebra o diagrama e abre o Pipedrive vazio comprou teatro.
IBM, no texto IA para a área de vendas de 14 de fevereiro de 2025, descreve automação que registra calls e e-mails no CRM, dispara follow-up e lembra retorno — e trata a generativa como copiloto de conteúdo que o vendedor revisa. Rotulo IBM Think. Vocabulário serve para separar conversa de registro. Eu recuso, portanto, chamar de criação o pack de prompt que só organiza setas. Pack, portanto, organiza slide.
Página, quiz e canvas ainda são slide
Marketek descreve Funnel AI que gera páginas de captura, obrigado, vendas e checkout a partir de nicho e objetivo, em dezenas de segundos. Rotulo vendor de produto; cito como anti-ângulo, não como modelo. StartFunil vende quiz público em três campos. Maisfy monta diagrama no canvas a partir da URL da página de vendas e ainda devolve um score. Nenhuma dessas peças cria coluna no CRM, nasce dono ou devolve ID de atividade. Dessa forma o mercado chama de funil o que na operação é site.
Canvas colaborativo também mente com cara de processo. Time desenha caixas, debate nomenclatura e tira print. Print, porém, não move deal. Recomendo o teste cru na manhã seguinte: o HubSpot, o RD Station, o Salesforce ou o Pipedrive mostra as etapas que o workshop “criou”? Se a resposta é não, o workshop produziu artefato de reunião. Artefato de reunião não substitui schema. Schema, porém, só existe onde a mesa já trabalha o cartão.
Gestor que busca IA para criar funil de vendas na SERP encontra exatamente essa vitrine de minutos. Recuso o prazo como honestidade de implantação, pois piloto sério nasce em semanas. Resultado comercial se mede em 60 a 90 dias, não no cronômetro do gerador de página. Além disso, e-commerce de infoproduto e checkout de captura ficam fora deste recorte. Recorte da peça, portanto, é B2B no CRM comercial.
Chatbot responde FAQ; copiloto rascunha o mapa; agente executa e grava ID
Tríade deste how-to é operacional, não cosmética. Chatbot responde “em que etapa estamos?” e o CRM permanece igual. Copiloto rascunha o mapa de etapas e um humano ainda digita a coluna. Agente executa a fatia autorizada da etapa e a ferramenta devolve identificador. Sem identificador, o nome comercial “agente” continua sendo rascunho com marketing. Fluência, porém, não é schema. Schema, no entanto, é coluna + regra + writeback.
Gartner prevê que 40% das aplicações empresariais terão agentes task-specific até o fim de 2026, contra menos de 5% em 2025, e chama de agentwashing vender assistente como agente. Rotulo forecast, não KPI da sua mesa. Assistants dependem de input humano e não operam sozinhos; agents executam tarefa de ponta a ponta. Quando implementei diagnósticos, o padrão se repetiu: o time batizou de agente o chat que sugeria “mover para proposta”. Sugestão sem ID, portanto, é copiloto.
IBM, no texto em inglês AI agents in sales, coloca a integração com o CRM no núcleo do agente e lembra que o runtime analisa, planeja e executa — sem substituir o representante. Rotulo vendor. Copiloto de texto, se ainda faltar o recorte, está em IA generativa para vendas — uma frase: rascunhar parágrafo não grava etapa. Gestor que celebra “a IA desenhou o funil” e abre o RD sem coluna nova comprou parágrafo. Por isso eu recuso a fusão no mesmo slide de piloto.
Este recorte constrói o schema — não o agente e não a operação do funil
How-to de criar o agente — job, campos, catálogo de tools, teste de ID, piloto — já está em como criar um agente de IA para vendas. Não reabro, portanto, o runtime. Mapa do que a automação faz em cada etapa de um funil que já existe está em automação de vendas com IA. Não reescrevo, portanto, aquele TOFU. Aqui o objeto é o funil do zero: colunas, regras de entrada, fatia autorizada e writeback. Keyword desta peça leva criar. Não reabro, ainda, o TOFU “IA em cada etapa”.
Helpdesk também não entra neste schema. Ticket, por exemplo, não é deal. ERP de cobrança não entra neste recorte. Conta a pagar também não é oportunidade. Landing canvas, ainda, não entra. Página, ainda, não é etapa. Percebi que misturar os três sistemas no mesmo workshop infla o slide e esvazia o CRM. Recomendo escolher uma fonte da verdade antes de nomear a primeira coluna. Fonte desta peça é o CRM comercial que o closer já abre na segunda-feira.
Pedido de IA para criar funil de vendas, então, só se fecha quando o schema está gravado. Diagrama bonito sem dono continua sendo opinião. Opinião, porém, não avança receita. Receita, por conseguinte, só aparece onde o cartão muda de coluna com critério fechado. Em suma, criar é registrar. Registrar, portanto, é o oposto de desenhar.
Slide versus funil, no mapa
Se no fim do desenho o CRM não tem etapas, dono, próxima ação e ID de atividade, não criou funil — só desenhou slide. A BayAI grava esse schema no CRM que vocês já usam.
O mapa das etapas no CRM (não no canvas)
Mapa do zero cabe em poucas colunas de ação, no CRM que a mesa já usa. Recorte ilustrativo desta peça — não dogma — é prospect, qualify, propose, close e handoff. Salesforce, no guia de pipeline B2B, descreve uma sequência próxima: prospecting, qualification, meeting ou demo, proposal, negotiation, closing e handoff para customer success. Rotulo vendor. Uso o vocabulário brasileiro “funil”, pois é a keyword da busca. Distinção acadêmica entre pipeline do vendedor e funnel do comprador cabe numa frase, não num ensaio.
Pedido de IA para criar funil de vendas nesta seção vira coluna, não caixa no quadro branco. Pipedrive, na documentação de etapas do pipeline atualizada em 9 de abril de 2026, trata cada etapa como passo real até ganho ou perdido. Rotulo vendor doc. Canvas que, no entanto, replica as mesmas cinco caixas sem gravá-las no deal continua sendo slide. Slide, porém, não tem internal name. Internal name, então, é o que a API lê.
Prospect, qualify, propose, close e handoff viram colunas
Prospect, aqui, é o nome da primeira coluna — conta entrou no universo comercial. Não ensino, portanto, cadência de prospecção nem turno de achar lead; esse ofício mora em outro cluster. Qualify é a coluna em que a ficha mínima existe e o critério de entrada para a próxima etapa pode fechar. Propose é a coluna em que existe artefato de proposta no cartão, ainda sem preço publicado pela máquina. Close é a coluna da assinatura humana. Handoff é a passagem nomeada para quem opera o cliente depois do ganho.
HubSpot, na base de pipelines atualizada em 12 de agosto de 2026, descreve o pipeline padrão de deals com estágios e probabilidade, e lembra que cada estágio tem um internal name usado por API e integrações. Rotulo vendor doc. Internal name é o que o agente lê quando a regra autoriza mover. Rótulo bonito na tela sem nome interno, por exemplo, vira quebra na primeira automação. Por isso eu gravo os dois: o que o closer vê e o que a ferramenta chama.
RD Station, na página de funil de vendas do CRM, trata o funil como o processo do primeiro contato ao fechamento, com etapas personalizáveis e campos obrigatórios por etapa. Rotulo vendor. Não copio, portanto, plano nem preço. Campos por etapa são o germe da regra de entrada, então a coluna já nasce com o que precisa ser verdade. Coluna vazia de critério é corredor. Corredor, então, treina a mesa a furar ordem.
Nomes de ação, não “Em andamento”
Pipedrive recomenda nomes claros e orientados à ação — “Reunião agendada”, “Proposta enviada” — e recusa o genérico “Em andamento”. Uso, portanto, o conselho no kickoff. Nome de ação descreve um fato que aconteceu no mundo, porém nome de humor descreve o feeling do vendedor. Feeling não versiona, no entanto fato versiona. Deal em “Proposta enviada” implica que o PDF saiu e o ID da atividade existe, no entanto deal em “Em andamento” implica nada.
Quando implementei mapas do zero, o time insistia em dez colunas com sinônimos. Sinônimo vira debate eterno sobre onde o cartão “deveria” estar. Recomendo começar curto: as cinco do recorte, ou menos se o ciclo for simples. Menos etapas aumentam adesão, também segundo a mesma documentação do Pipedrive. Labirinto de dezoito estágios ensina o closer a ignorar o quadro. Quadro ignorado, portanto, não é funil. Funil, porém, é o conjunto que a mesa atualiza porque o nome descreve o trabalho.
Gestor pede IA para criar funil de vendas e espera que o modelo invente nomenclatura criativa. Recuso, portanto, criatividade aqui. Criatividade no rótulo, porém, custa higiene. Higiene pede verbo no particípio ou ação concluída: enviada, agendada, aceita, perdida. Salesforce, no guia de pipeline management, aponta que pipelines falham quando os estágios são unclear, o dado está velho ou o processo não é seguido. Rotulo vendor. Nome vago, por exemplo, é o primeiro unclear.
Menos etapas, mais adesão — e o que este mapa não cobre
Cinco colunas ilustrativas não são religião. Operação com ciclo curto pode viver com quatro, por exemplo, e operação com comitê de compras pode separar propose de negotiation. Teto honesto é o número que a mesa consegue atualizar sem cerimônia. Eu recuso, portanto, labirinto “para o dashboard ficar bonito”. Dashboard bonito com coluna morta, então, treina mentira. Mentira no funil, então, aparece no forecast da sexta.
Qualificação como capítulo de BANT, MQL e SQL fica fora. Critérios profundos de ficha já estão em outro texto do cluster; aqui qualify é só o nome da coluna e a porta de entrada da próxima. Cadência de prospecção também fica fora. Prospect neste mapa não é FIND nem turno de lista fria. Copiloto que rascunha e-mail de abordagem não cria a coluna. Coluna, portanto, nasce no admin do CRM, não no prompt.
Won e Lost precisam existir como destino, não como afterthought. HubSpot trata ganhos e perdas como obrigatórios para report de receita. Sem os dois, o funil não fecha a conta. Conta que não fecha vira estoque eterno de “ainda vai”. Ainda vai é slide com deal. Em suma, o mapa cabe no CRM. Canvas fica para a retrospectiva, se alguém insistir em desenhar depois de gravar.
As etapas, no mapa
Regras de entrada: o que precisa ser verdade para avançar
Coluna sem porta é corredor. Porta é a regra de entrada: o que precisa ser verdade no cartão para a etapa mudar. Salesforce formula o mesmo ofício como exit criteria — critérios específicos e mensuráveis que ditam o movimento. Exemplo da própria página B2B: sem convite de calendário com o diretor de TI, o deal não sobe para Demo. Rotulo, portanto, o exemplo. Feeling do vendedor (“está quente”) não substitui o fato. Fato, portanto, cabe em campo.
Pedido de IA para criar funil de vendas sem regra de entrada produz pipeline maquiado. Maquiagem é deal na proposta sem PDF, deal no close sem dono, deal no qualify sem ficha. Eu recuso maquiagem no kickoff, pois o forecast também herda o teatro. Recomendo escrever a porta em linguagem de campo obrigatório, não em slide de “princípios”. Princípio não trava o botão de avançar. Campo, porém, trava.
Exit criteria mensuráveis ditam o movimento
Critério mensurável responde sim ou não. Convite existe? Ficha mínima está completa? Artefato de proposta está anexado? Próxima ação tem data? Dono está nomeado? Cada pergunta vira um campo ou uma atividade. Sem o sim, a etapa não muda — nem com o agente, nem com o closer pressionado pelo mês. Pressão do mês é exatamente o motivo de gravar a porta. Porta fraca, então, cede na reta final.
Salesforce lembra que é preciso definir o que o lead deve fazer para ir à próxima etapa e rastrear atividades definidas por estágio. Uso o recorte no diagnóstico. Atividade definida por etapa é a próxima ação do ouro-teste, não um recado no grupo. Recado no grupo, por exemplo, some na quarta. Atividade no CRM sobrevive à troca de vendedor. Troca de vendedor, além disso, é o teste cruel: se o sucessor não entende por que o cartão está na coluna, a regra não estava escrita.
Gestor ama score “de IA” como atalho de critério. Score sem frase é painel, e painel não é porta. Porta pede evidência que um humano defende na alçada. Quando o modelo só pinta um número e o campo obrigatório continua vazio, você comprou cosmética. Cosmética, contudo, não segura forecast. Forecast, portanto, pede o fato que a regra descreveu.
Campos obrigatórios ao mover o deal
HubSpot permite propriedades condicionais obrigatórias ao criar ou mover o record para a etapa — senão o usuário não atualiza. RD Station descreve campos obrigatórios por etapa e regras para a negociação avançar. Dois vendors, a mesma higiene. Eu gravo o campo na etapa em que ele passa a ser verdade, não num formulário eterno de vinte perguntas no primeiro toque. Formulário eterno ensina a mesa a pular. Pular, então, destrói a porta.
Pedido de IA para criar funil de vendas costuma chegar com a fantasia de que o modelo “descobre” o campo. Modelo não descobre política, pois política é humana e versionada. Campo de fit, campo de dono, campo de próxima ação e campo de artefato são decisões de ops, não milagre do LLM. Recomendo recusar kickoff em que “obrigatório” ainda é combinado no corredor. Combinado no corredor, por exemplo, muda na terça. Campo no admin não muda sem dono do schema.
Internal name entra de novo aqui. Integração e agente leem o identificador estável, não o rótulo que o time rebatiza no workshop. Rótulo pode ficar amigável, no entanto o identificador precisa nascer no desenho. Sem os dois, a regra de entrada quebra na primeira ferramenta. Ferramenta, então, só acelera o pulo. Pulo acelerado, portanto, é pipeline pior, não funil criado.
Sem fit, sem dono ou sem próxima ação, a etapa não muda
Três recusas que eu escrevo no papel antes de ligar qualquer runtime. Cartão sem fit não entra na próxima coluna só porque “alguém respondeu”. Deal órfão, isto é, sem dono, também não avança, porque ninguém herda a próxima ação. Próxima ação sem data deixa o cartão estacionado, mesmo que o feeling esteja alto. BK7 formula o mesmo ofício sem percentual: próximo passo mais data; sem data, não existe. Uso a tese operacional, não os números da página. Rotulo agência.
Feeling, porém, não é critério. “Vendedor sentiu que está pronto”, por exemplo, não move. “Comprador pediu gente” também não é porta de proposta: é sinal para o humano, não autorização de etapa. Deal sem dono no close é teatro de meta. Teatro de meta treina a diretoria a desacreditar o quadro. Quadro descrente volta para a planilha. Planilha paralela, portanto, é o anti-funil da próxima seção de writeback.
Agente respeita a porta escrita e o humano também. Exceção existe, porém nasce nomeada, com dono e com motivo no cartão — não como atalho silencioso. Atalho silencioso vira política sombra, e política sombra é o contrário de schema. Schema, por conseguinte, só vale se a recusa também está gravada. Recusa gravada ensina o time, porém recusa falada ensina jeitinho.
A regra de entrada, no mapa
Máquina na fatia autorizada e no writeback. Humano no preço, na exceção e no close. Piloto em semanas; resultado em 60 a 90 dias.
O que o agente executa em cada etapa
Fatia autorizada não é o mapa de operação do funil existente. Mapa de o que a automação faz em cada etapa já foi publicado no cluster. Recorto o schema: o que o runtime pode executar quando a regra daquela coluna fecha, e o que jamais executa mesmo com fluência. Pedido de IA para criar funil de vendas que esquece esse teto produz agente que publica preço no chat. Preço no chat, então, vira proposta. Proposta sem alçada, então, vira prejuízo com cara de inovação.
IBM insiste que o agente de vendas não substitui o representante e que o time precisa saber quando o input humano é necessário. Rotulo, portanto, de novo. Uso o recorte no desenho da fatia: volume e registro na máquina; juízo na gente. Job do assento, se ainda faltar o day-in-life, está em o que um agente de IA faz no time comercial — uma frase: aqui não reconto o turno, só a autorização por coluna.
Fatia autorizada: volume e registro, não juízo
Prospect autorizado: criar ou enriquecer o lead, abrir a atividade, gravar a origem, deixar o cartão na primeira coluna com dono. Não autorizado: inventar fit, disparar rajada fora de território, declarar SQL. Qualify autorizado: gravar a ficha mínima que a porta pediu e, se o critério fechou, mover a etapa e devolver ID. Não autorizado: aceitar SQL no lugar do humano, perdoar campo vazio, “avançar porque a conversa foi boa”.
Volume cabe na máquina porque volume é repetível. Juízo não cabe porque juízo tem preço político. Quando implementei a fatia, o erro clássico foi pedir ao runtime o que a diretoria ainda não escreveu. Runtime sem política, por exemplo, executa feeling em escala. Feeling em escala é o pipeline maquiado da seção anterior, só que mais rápido. Por isso a autorização nasce no papel da etapa, não no prompt solto.
Recomendo uma lista curta por coluna, visível no mesmo lugar da regra de entrada. Lista eterna vira slide, no entanto lista curta vira guardrail. Guardrail, além disso, precisa caber no teste de writeback: se a ação não deixa ID, ela não estava autorizada de verdade. Ação sem ID, portanto, é conversa. Conversa, portanto, não constrói funil.
Propose anexa rascunho; close agenda e grava, humano assina
Propose autorizado: anexar rascunho de proposta no cartão, notificar o dono, abrir a próxima ação de revisão. Não autorizado: publicar preço, aplicar desconto, alterar valor do deal, enviar o PDF ao comprador como se fosse decisão. Comprador brasileiro, por exemplo, trata o print como oferta. Print da máquina sem alçada é a alucinação mais cara deste schema. Eu recuso, portanto, autonomia de cotação no primeiro ar. Copiloto pode rascunhar o texto. Humano, porém, envia.
Close autorizado: agendar a reunião de assinatura, notificar o closer, gravar o ID da atividade, atualizar o status para a coluna que a regra descreveu somente depois do fato humano. Não autorizado: marcar ganho sozinho, assinar no lugar do comprador, inventar data de fechamento para maquiar o mês. Salesforce descreve closing como o buyer que assina e o rep que faz handoff. Rotulo vendor. Assinatura continua humana neste funil, portanto.
Handoff autorizado: notificar o dono do pós-venda, gravar o ID, mover para a coluna de passagem quando o close humano fechou. Não autorizado: prometer escopo que o contrato não tem, abrir chamado de implantação no lugar do comercial. Passagem suja nasce de writeback incompleto, não de “IA fraca”. Writeback incompleto é schema incompleto. Schema incompleto, então, devolve o cartão para o canvas.
Autorização da etapa, não catálogo de ferramenta
Catálogo de tools, campos do ICP e scorecard de piloto pertencem ao how-to do agente, não a este desenho. Recuso virar esta seção em lista de API. Teste que importa para o funil é outro: a regra da coluna autoriza esta ação, e a ação devolve identificador no CRM? Se a resposta é não, você ainda está no copiloto. Copiloto continua útil, porém não cria a coluna.
Gestor pede “MCP”, “connector” e “dez ferramentas nativas” no workshop do funil. Workshop do funil, porém, não é vitrine de integração. Integração entra depois, quando a porta e a fatia já têm dono. Sem porta, a ferramenta só acelera o pulo; sem fatia, também publica o que a alçada evitaria. Dessa forma eu corto o catálogo deste texto de propósito. Corte, portanto, é recorte, não pobreza técnica.
Agente que executa fora da autorização não “errou o modelo”. Time, portanto, errou o schema. Schema que autoriza demais em propose é política de preço escondida no runtime. Política escondida, então, aparece no jurídico. Jurídico, porém, chega tarde. Tarde custa mais do que gravar o teto na coluna certa. Em suma, cada etapa nasce com um sim curto e um não curto. Sim e não curtos são o funil. Prompt longo, em suma, é slide.
O writeback no CRM: etapa, dono, próxima ação e ID
Ouro-teste desta peça cabe inteiro nesta seção, de novo: se no fim do desenho o CRM não tem etapas, dono, próxima ação e ID de atividade, não criou funil — só desenhou slide. Writeback é a prova, não o opcional técnico. Pedido de IA para criar funil de vendas que para no canvas falha aqui, mesmo com tríade correta no discurso. Discurso, porém, não move cartão. Cartão, porém, move quando a ferramenta grava.
Pipedrive trata activity como a ação que move o deal — call, meeting, task, e-mail — ligada a pessoa, organização, lead ou negócio, com identificador no report. Pipeline view prioriza pela próxima atividade. Rotulo vendor doc. Próxima ação sem ID é recado, e recado não entra no ouro-teste. Ouro-teste pede os quatro juntos, não três e um “a gente anota no grupo”.
Sem etapa, dono, próxima ação e ID, foi slide
Quatro peças, nenhuma negociável. Etapa nomeada no pipeline que a mesa abre. Dono do deal visível no cartão. Próxima ação com data, não com “depois a gente vê”. Identificador da atividade que a ferramenta devolveu. Falta uma e o desenho desaba; desenho que desaba, então, volta a ser workshop. Workshop, no entanto, já foi pago em atenção. Atenção, portanto, não substitui registro.
Closer que abre o Salesforce e vê a coluna igual descobre que o agente não trabalhou o funil. Dono ainda em branco ou marcado como “casa” significa que ninguém herda. Próxima ação só no chat interno, por exemplo, zera a fila da terça. Sem ID, ainda, você não tem como auditar. Auditar é o contrário de acreditar no transcript. Transcript, então, é teatro se o CRM ficou igual.
Recomendo o teste cru no dia seguinte ao piloto de schema — ainda sem discutir modelo. Cartões de amostra atravessaram as portas? IDs nasceram? Dono está certo? Se a resposta é não, você ainda está no copiloto ou no slide. Ainda, o teste vale para o humano: closer que avança sem gravar também fura o funil. Funil, portanto, fura dos dois lados quando o writeback é opcional.
ID de atividade é a prova — planilha e chat paralelo não
Planilha ao lado do CRM é o anti-padrão mais educado que eu encontro. Time “não quer sujar o Pipedrive” e suja o forecast. Chat paralelo com o resumo da call é o segundo. Resumo fluente, por exemplo, agrada o gestor na hourly e some no feriado. CRM comercial é a fonte única e, além disso, é o que permite o agente escrever no mesmo lugar que o closer lê.
Pedido de IA para criar funil de vendas com “vamos gravar depois” não cria, pois depois não chega e, em seguida, vira aba. Aba vira versão e, em seguida, a versão diverge na quinta. Divergência na quinta é reunião de alinhamento que o schema deveria ter evitado. Eu recuso, portanto, piloto em que o writeback fica “fase dois”. Fase dois, neste ofício, também é eufemismo de nunca. Nunca, em suma, é slide permanente.
Helpdesk paralelo também não serve de prova. Ticket pode existir no CX; deal precisa existir no CRM. ERP paralelo também não serve. Nota fiscal, porém, não é etapa comercial. Landing paralela registra conversão de página, não dono de oportunidade. Três paralelos, o mesmo buraco: o closer não encontra o cartão. Cartão inexistente não tem próxima ação. Próxima ação inexistente, portanto, não tem ID.
O que trava o funil é o registro
Agendor, no texto de funil de vendas com IA, acerta a tese que eu uso no kickoff: o que trava não é a decisão, é o registro. Rotulo vendor brasileiro. Não copio o roundup de ferramentas nem o recorte topo-meio-fundo daquela página, porque aquilo opera um funil já existente. Teses de registro, porém, nascem antes da operação. Sem registro, a inteligência fica fora do funil. Fora do funil, então, é copiloto com marketing.
Registro é etapa + dono + próxima ação + ID — quatro, ou seja, não é “o bot respondeu”, nem o canvas bonito, nem o quiz convertido. Conversão de página pode encher o topo e ainda assim o schema comercial não existir. Existir, nesse recorte, é o cartão auditável. Cartão auditável sobrevive a férias, a turnover e a diretoria nova. Diretoria nova que abre o CRM e entende o quadro herdou um funil; a que pede o slide de novo, porém, herdou teatro.
Gestor mede o piloto por mensagens, porém o indicador está errado. Indicador deste how-to é writeback visível no report de atividades, com dono e com data. Por conseguinte eu recuso dashboard verde de conversa. Verde de conversa esconde cartão parado. Cartão parado, em suma, é o funil que não foi criado, só narrado.
O que o humano ainda faz nesse funil
Máquina carrega volume e registro. Gente, porém, carrega risco. Pedido de IA para criar funil de vendas que promete “fecha sozinho” está vendendo o contrário deste schema. IBM, de novo, afirma que o agente não substitui o sales rep. Rotulo a tese, não o pitch de plataforma. Homepage de implementação assistida descreve o mesmo teto: o agente assume o repetitivo e entrega o que exige juízo. Juízo, neste funil, tem nome: preço, exceção, close, conta estratégica e aceite de SQL.
Landing self-serve sugere que o gestor liga um toggle e o comercial se resolve. Recuso, portanto, o toggle como honestidade. Piloto que eu desenho nasce em semanas e o resultado se lê em 60 a 90 dias. Semanas não são defeito: são o tempo de gravar porta, fatia e writeback no CRM que já existe. Toggle em minutos, por exemplo, descreve chatbot. Chatbot, porém, não assina contrato.
Preço e desconto continuam com gente
Política de preço é documento versionado com dono comercial, não prompt. Desconto, comitê, condição especial e alteração de valor do deal ficam fora da fatia do agente. Copiloto pode rascunhar a argumentação, porém o humano publica o número. Número publicado, portanto, é oferta. Oferta, no Brasil, tem consequência comercial, portanto o número na tela continua com gente.
Quando o runtime “sugere 12%” no chat, o comprador screenshot. Screenshot vira expectativa e, em seguida, a expectativa vira briga. Briga chega no jurídico com a fluência do modelo como prova. Eu recuso, portanto, essa prova no desenho. Recomendo campo de preço editável só por papel humano, com log. Log, portanto, ensina a alçada. Alçada, além disso, precisa aparecer no cartão — não no grupo interno da gerência, que já recusei como sistema de registro.
Gestor quer velocidade na proposta e tenta autorizar envio automático “só do padrão”. Padrão ainda é preço. Preço padrão enviado sem revisão ainda é oferta. Oferta sem dono humano, então, fura o teto desta seção. Teto existe para o funil sobreviver ao primeiro cliente chato. Cliente chato, portanto, é o teste real, não o workshop.
Exceção, conta estratégica e aceite de SQL
Exceção é o caso que a porta não previu. Conta estratégica pede tom, agenda e risco que o volume não cobre. Aceite de SQL é o “sim, este cartão merece closer” — juízo de território, não score solto. Três assentos humanos e, portanto, três recusas de autonomia no primeiro ar. Sem esses três, o schema vira esteira que empurra lixo caro para o AE. Lixo caro, portanto, queima o scorecard. Scorecard queimado, então, mata o piloto.
Humano nomeia a exceção no cartão, com motivo e com data. Máquina, porém, não “jeita” a porta. Jeitinho automatizado é política sombra em escala. Política sombra, no entanto, aparece no forecast como milagre. Milagre no forecast, então, é demissão na revisão trimestral. Recomendo fila visível de exceção, com teto de volume, para o gestor ver o custo do “caso especial”. Caso especial invisível, por exemplo, vira regra. Regra invisível, portanto, destrói a porta da seção anterior.
Aceite de SQL não é o capítulo de BANT: é o botão humano depois da ficha mínima. Ficha mínima a máquina grava, porém o botão o closer ou o líder aperta. Apertar, portanto, é juízo. Juízo não escala no mesmo ritmo do formulário, porém o slide da SERP finge que escala. Ficção da SERP, em suma, é exatamente o anti-ângulo desta peça.
Close e handoff com assinatura humana
Close é assinatura, isto é, pessoa. Handoff é passagem nomeada, também com pessoa do outro lado. Agente, então, agenda, notifica e grava o ID. Closer conduz a mesa, negocia o residual e confirma o ganho. Customer success herda o cartão com contexto, não com rumor. Rumor no handoff, por exemplo, é o custo escondido de writeback incompleto. Completo, o sucessor lê etapa, dono, próxima ação e identificador.
Implementação assistida entra aqui como ofício, não como login. BayAI desenha o schema no CRM que a empresa já usa — Pipedrive, RD Station, HubSpot ou Salesforce — com diagnóstico, implantação e operação assistida, sem vitrine self-serve. Funcionários de IA assumem o volume repetível da etapa autorizada e devolvem o juízo para o time. Piloto cabe em semanas. Resultado se discute em 60 a 90 dias. Cotação e toggle de minutos ficam de fora deste texto.
Gestor que chega com o canvas pronto ainda precisa do close humano no desenho, senão o ouro-teste falha no último metro. Último metro, ainda, é onde a SERP mais mente. Mente, por exemplo, porque checkout de página parece “fechamento”. Fechamento comercial B2B, contudo, é gente na mesa e ID no CRM. Em suma, o funil criado ainda tem assento. Assento vazio no close não é automação madura. Automação madura, portanto, sabe parar.
Três papéis no funil
Página, quiz e canvas: três jeitos de parecer que usou IA para criar funil de vendas e só gerar slide.
Conclusão
Se no fim do desenho o CRM não tem etapas, dono, próxima ação e ID de atividade, não criou funil — só desenhou slide. Frase vale, portanto, para o workshop, para o prompt e para o piloto. IA para criar funil de vendas, neste recorte, é gravar o schema no CRM comercial e autorizar só a fatia que a porta deixa executar. Canvas, quiz e página continuam sendo site. Site, porém, não substitui coluna.
Titular pode pedir revisão de decisão tomada unicamente com base em tratamento automatizado que afete seus interesses — perfil, consumo, crédito — nos termos do art. 20 da Lei 13.709/2018, com a redação da Lei 13.853/2019. Controlador, então, informa critérios e procedimentos. Parágrafo 3º do art. 20 foi vetado: a lei não exige que a revisão seja feita por pessoa natural. Recusa ou perfil automatizado no funil, portanto, precisa de revisão humana pedível, mesmo sem o mito do “sempre um analista na cadeira”. CDC cabe só se o recorte for B2C de oferta: preço e close continuam com gente.
Runtime do agente — job, campos, tools, teste de ID — continua em como criar um agente de IA para vendas. Operação do mapa já existente continua em automação de vendas com IA. Lista de espera da implementação assistida existe para quem já tem o desenho e ainda não gravou os quatro no CRM. Quatro gravados, o funil nasceu; quatro faltando, porém, o slide continua no ar.
Perguntas frequentes
Tire suas dúvidas sobre IA para criar funil de vendas no CRM que vocês já usam. Não encontrou o que procurava? Fale com a BayAI.
Processo
Recortes
Operação
Coloque Funcionários de IA no funil do CRM, sem painel self-serve
Diagnóstico, implementação e operação assistida. Você não recebe um login e um manual.
