Como usar o Jev para qualificar e priorizar leads no seu funil

Lead scoring costuma morrer de dois jeitos

Ou vira uma regra fixa que alguém escreveu em 2021 ("e-mail corporativo vale 10 pontos") e ninguém mais tem coragem de mexer, ou vira um resumo bonitinho gerado por LLM que o vendedor não lê, porque ele tem 80 leads na fila e quer saber só quem ligar primeiro

O Jev ataca exatamente esse meio de campo. Ele é o primeiro modelo da classe System One da TypeSafe AI, anunciado em 15 de setembro de 2026, e a graça dele é o que ele NÃO faz: não gera texto

Você descreve um estado (o lead) e faz perguntas com resposta restrita ao schema que você definiu. Volta probabilidade, opção escolhida ou nível numa escala, e o campo de confiança aparece em alguns tipos, não em todos. Nada de parágrafo

Neste post a gente monta o esquema completo: o schema de perguntas do lead, o score composto com pesos no seu código e as faixas de prioridade que o CRM consegue consumir sem ninguém traduzir nada na mão 🙂

O que você precisa antes de começar

Antes de sair codando, três coisas

1. Uma chave de API. O Jev está em early access com lista de espera no typesafe.ai, e as chaves saem em lotes. Então se você ainda não entrou na fila, entra agora e vai lendo o resto pra chegar com o schema pronto

2. SDK ou HTTP puro. Tem SDK oficial nos dois mundos:

# JavaScript / TypeScript (precisa de Node.js 20 ou mais novo)
npm install @typesafe-ai/sdk

# Python (precisa de Python 3.10 ou superior)
pip install typesafe-sdk

Se você não quiser dependência nova, a chamada nativa é um POST simples e resolve

3. Entrada em texto ou campos estruturados. Jev avalia linguagem natural. Gravação da call, áudio do WhatsApp, PDF da proposta, print do CRM: tudo isso precisa ser pré-processado (transcrito, extraído, virado campo) ANTES de entrar no payload

Pré-inscrição Curso Jev

Domine o Jev e coloque decisões de IA dentro do seu sistema

Você vai aprender a usar o Jev, o System One Model da TypeSafe AI, pra automatizar decisões com resposta tipada e confiança medida, sem depender de chat nem de alguém revisando cada passo. Entre na lista de espera para garantir a condição de lançamento!

Quero minha vaga

E tem o orçamento de contexto do Jev 1.13, que funciona em dois níveis:

• 64k para o state mais todas as perguntas somadas
• 32k para o state mais a pergunta individual mais longa

Na prática isso é o teto do quanto de histórico de lead cabe numa chamada. Thread de e-mail de dois anos inteira não vai caber, e nem precisa

Sobre custo: o preço listado do Jev 1.13 é de US$ 0,042 por milhão de tokens de entrada, com saída a US$ 0,00. Faz sentido, né? Não tem saída pra cobrar, a resposta é tipada 😀

Passo a passo: do lead bagunçado ao score que o CRM consome

1. Monte o state juntando as fontes que você já tem

O campo state aceita string simples, objeto ou array. Ou seja, você não precisa transformar o lead num textão: pode mandar estruturado do jeito que sai do seu banco

{
  "formulario": {
    "empresa": "Fintech XPTO",
    "cargo": "Head de Engenharia",
    "tamanho_time": "12 devs",
    "mensagem": "Preciso trocar nosso processo de onboarding de clientes, hoje é tudo manual"
  },
  "emails": [
    { "de": "lead", "texto": "Conseguem faturar via PJ? Queremos fechar ainda neste trimestre" }
  ],
  "eventos_produto": [
    { "evento": "signup_trial", "dias_atras": 6 },
    { "evento": "convidou_3_usuarios", "dias_atras": 4 },
    { "evento": "abriu_pagina_de_planos", "dias_atras": 1 }
  ]
}

O erro comum deste passo: jogar binário cru lá dentro. Base64 de PDF, áudio da call, imagem do cartão de visita… nada disso é state válido. Transcreva ou extraia antes, sempre

2. Escreva as perguntas escolhendo a primitiva certa

São três tipos, e escolher errado aqui estraga o score inteiro. Cada pergunta tem uma chave (o id, escolhido por você), um type, um instructions e o criteria do próprio tipo

O criteria do Choice é um mapa de opção para descrição. O do Score é um array com a descrição de cada nível. Se liga:

{
  "fit_industria": {
    "type": "noul",
    "instructions": "A empresa do lead atua em serviços financeiros, seguros ou meios de pagamento?"
  },
  "intencao_compra": {
    "type": "noul",
    "instructions": "O lead declarou intenção de contratar uma solução paga em algum momento do texto?"
  },
  "estagio": {
    "type": "choice",
    "instructions": "Em que estágio de compra este lead está, considerando o que ele escreveu e o uso do produto?",
    "criteria": {
      "curiosidade": "Está explorando o tema, sem problema concreto descrito",
      "avaliacao": "Descreve um problema concreto e está comparando soluções",
      "decisao": "Fala de prazo, orçamento, contrato ou processo de compra"
    }
  },
  "urgencia": {
    "type": "score",
    "instructions": "Qual o nível de urgência do problema descrito pelo lead?",
    "criteria": [
      "Nenhuma urgência: interesse genérico, sem prazo",
      "Urgência baixa: problema existe, mas há alternativa ou contorno em uso",
      "Urgência alta: problema atrapalha a operação hoje e há prazo citado",
      "Urgência crítica: problema está bloqueando a operação agora"
    ]
  }
}

O erro comum deste passo: escrever pergunta com negação ou escopo ambíguo. A página de jaggedness do Jev 1.13 avisa que o modelo é bastante literal: ele responde a pergunta ESCRITA, não a pretendida, e lê negação, escopo e condição implícita ao pé da letra. "O lead não é um concorrente disfarçado?" é pedido de encrenca. Pergunte no positivo e um fato por pergunta

3. Mande tudo numa única chamada

O corpo tem state, model e o mapa questions. As respostas voltam sob as mesmas chaves que você escolheu

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d @lead.json

E por que uma chamada só? Porque o Jev lê o state uma vez e avalia todas as perguntas em paralelo contra aquele mesmo estado. Adicionar pergunta quase não muda o tempo de resposta

O cookbook oficial de perguntas paralelas mostra o tamanho do estrago: juntar todas as perguntas numa requisição saiu 12,2x mais barato e 10,0x mais rápido, sem mudança nas respostas

O erro comum deste passo: montar um for que dispara uma requisição por pergunta. Você paga o state inteiro de novo a cada chamada. É o jeito mais caro e mais lento de chegar no mesmo lugar

4. Leia a resposta do jeito certo

Cada tipo volta com um formato próprio. Os dois blocos abaixo são os exemplos da doc oficial, de um caso de suporte, não do nosso schema de lead: o que importa aqui é o FORMATO, porque as opções do Choice e a legend do Score sempre voltam com o que VOCÊ definiu no criteria:

{
  "type": "choice",
  "choice": "billing",
  "probabilities": { "billing": 0.88, "technical": 0.12, "sales": 0.0 },
  "confidence": 0.81
}

{
  "type": "score",
  "score": 1.3,
  "confidence": 0.54,
  "legend": {
    "0": "Cosmetic; no impact to functionality",
    "1": "Broken or degraded feature, but workaround exists",
    "2": "Blocking issue; no workaround exists"
  },
  "probabilities": { "0": 0.0, "1": 0.7, "2": 0.3 }
}

Traduzindo pro nosso schema: no lugar de billing e technical viriam curiosidade, avaliacao e decisao, e no lugar daquela legenda de bug viriam os quatro níveis de urgência que a gente escreveu no passo 2

Repara no Score: o valor 1.3 é a soma de cada nível multiplicado pela sua probabilidade (0.7 no nível 1 e 0.3 no nível 2). Não é "o modelo chutou 1.3", é a esperança da distribuição

Já o Noul devolve só a probabilidade de 0 a 1 de que a resposta seja sim, e não traz campo de confiança, diferente de Choice e Score

O erro comum deste passo: tratar P(noul) e 1 menos P(not noul) de perguntas SEPARADAS como a mesma coisa. A doc de jaggedness é explícita: isso não é identidade aritmética entre perguntas diferentes. Se você precisa do inverso, use o próprio valor, não faça outra pergunta invertida esperando bater

5. Calcule o score composto no SEU código

Esse é o padrão de Composite scoring da TypeSafe: quebrar um julgamento complexo em dimensões separadas e combinar com pesos definidos no seu próprio código

O exemplo oficial com nouls é assim:

quality = 0.4 * answers["answers_request"].noul
        + 0.4 * answers["citations_are_supported"].noul
        + 0.2 * (1 - answers["contradicts_context"].noul)

E tem um exemplo de prioridade combinando três Scores com pesos 0.6, 0.3 e 0.1, que dá 0.6 x 0.62 + 0.3 x 0.725 + 0.1 x 1.0 = 0.6895

No nosso caso de lead, fica mais ou menos assim:

// os pesos são decisão do time comercial, não do modelo
const fit        = answers["fit_industria"].noul        // já vem de 0 a 1
const intencao   = answers["intencao_compra"].noul      // já vem de 0 a 1
const urgencia   = answers["urgencia"].score / 3        // Score de 0 a 3 normalizado pra 0 a 1
const decisao    = answers["estagio"].probabilities["decisao"]

const prioridade =
  0.35 * fit +
  0.30 * intencao +
  0.20 * urgencia +
  0.15 * decisao

Coloque tudo na mesma escala antes de somar, senão uma dimensão de 0 a 3 esmaga as outras sem você perceber

O erro comum deste passo: pedir pro modelo fazer essa conta. Jev tem dificuldade declarada com tarefas que exigem precisão numérica. Pergunta é julgamento, peso é aritmética, e aritmética é trabalho do seu backend

Se você for escrever esse trecho com ajuda de IA, vale ter clareza de quando usar agente e quando o autocomplete resolve, porque é código curto e bem definido

6. Grave no CRM como campo, nunca como texto

O ponto do fluxo inteiro é esse. O que vai pro CRM:

• jev_prioridade (número de 0 a 1)
• jev_faixa (enum: A, B ou C)
• jev_estagio (enum vindo do Choice)
• jev_confianca (número de 0 a 1)
• jev_versao_schema (string, pra você saber qual schema gerou aquele score)

Filtro, ordenação e automação funcionam em cima de campo tipado. Em cima de parágrafo, não funciona nada

O erro comum deste passo: criar um campo "resumo da IA" e achar que resolveu. Ninguém ordena fila por textão

E já que o payload vai carregar dado de contato de gente real saindo do seu backend, é uma boa hora pra passar o olho em falhas de segurança no código, antes de subir pra produção

Como definir as faixas de prioridade (e o que o comercial faz em cada uma)

Número de 0 a 1 não diz nada pro vendedor. Faixa diz

Aqui os cortes são escolha SUA (o modelo não define isso), mas a lógica costuma ser essa:

Só que faixa de prioridade sozinha não basta. Precisa cruzar com a confiança

A confidence vai de 0 a 1 e é derivada do formato da distribuição de probabilidades: pico único indica alta confiança, probabilidade espalhada indica baixa. Faz sentido, né? Se o modelo dividiu 0.5 e 0.5 entre duas opções, ele está em cima do muro e o número te conta isso

A documentação recomenda três faixas de confiança, cada uma com uma ação diferente:

• Alta: agir automaticamente (roteia o lead direto, dispara a cadência)
• Média: pedir confirmação, marcar pra revisão ou buscar mais informação (aqui entra aquele enriquecimento que você adiaria)
• Baixa: não agir, mandar pra humano ou pra outro sistema

E tem um detalhe que muita gente ignora: o threshold muda conforme o risco da ação. Mandar um e-mail automático de boas-vindas é barato de errar. Descartar um lead como C e nunca mais tocar nele é caro. Ação cara pede corte de confiança mais alto

Os casos de uso oficiais do Jev listam lead scoring na cara dura: pontuar fit de indústria e maturidade da empresa, detectar relevância do comprador, dores e intenção de compra, e priorizar e rotear leads. É basicamente o schema que a gente montou lá em cima, dimensão por dimensão

O resultado prático pro time: o vendedor abre a fila ordenada por jev_prioridade, olha a faixa, olha o estágio e liga. Ele não lê nada gerado, porque não tem nada gerado pra ler 😀

Problemas comuns na pontuação de leads com Jev

Confidence sempre baixa

Sintoma: quase todo lead cai na faixa de baixa confiança e vai pra revisão humana, o que mata o ganho do automático

Causa: probabilidade espalhada. Ou a pergunta está ambígua (duas interpretações possíveis), ou o state é pobre demais pra sustentar um julgamento

Solução: quebre a pergunta em duas mais específicas e enriqueça o state com os eventos de uso que você já tem no banco

Como prevenir: uma pergunta, um fato. Se você usou "e" ou "ou" no instructions, provavelmente são duas perguntas

O score não bate com a intuição do time

Sintoma: o vendedor olha um lead óbvio de faixa A e o Jev deu 0.3

Causa: literalidade. O modelo é bastante literal em negações, escopo e condições implícitas. Se o seu instructions dizia "o lead tem budget aprovado?" e o lead só falou de prazo, a resposta correta é baixa mesmo

Solução: reescreva a pergunta dizendo exatamente o que você quer capturar, incluindo o escopo ("considerando apenas o que está escrito no formulário e nos e-mails")

Como prevenir: rode o schema numa amostra de leads antigos que o time já qualificou na mão e compare. Divergência é sinal de pergunta mal escrita, quase nunca de modelo quebrado

Você tentou fazer o modelo somar os pesos

Sintoma: score composto instável, mudando entre execuções sem o state mudar

Causa: tarefas que exigem precisão numérica são uma limitação declarada do Jev 1.13

Solução: tire a conta do prompt. O modelo julga dimensões, seu código multiplica e soma

Como prevenir: regra simples de arquitetura: nenhuma aritmética atravessa a fronteira da API

O state estourou o orçamento de contexto

Sintoma: payload gigante com histórico completo do lead e a requisição não passa

Causa: 64k cobrem state mais todas as perguntas somadas, e 32k cobrem state mais a pergunta individual mais longa. Thread de e-mail inteira come isso rápido

Solução: recorte. Últimos N e-mails, últimos N eventos, campos do formulário que importam pro julgamento

Como prevenir: trate o state como seleção, não como despejo de banco. Já ganhei dor de cabeça achando que "mandar tudo" era mais seguro

Mídia sem pré-processamento

Sintoma: você quer pontuar o lead usando a gravação da call de descoberta e não sai do lugar

Causa: Jev avalia entrada em linguagem natural. Imagem, áudio, vídeo e binário precisam virar texto ou campo estruturado antes

Solução: transcreva a call no seu pipeline e mande a transcrição (ou um recorte dela) como parte do state

Como prevenir: deixe a etapa de pré-processamento explícita no desenho do fluxo, nunca como "depois a gente resolve"

Enquanto isso, no canal

Pra começar do zero com IA lendo o seu próprio código, esse vídeo do canal mostra uma skill que faz a IA ler o projeto e desenhar a arquitetura sozinha (Archify)

Próximo passo

Recapitulando o fluxo todo, que é curto quando você vê junto:

1. state com formulário, e-mail e eventos de uso, em texto ou estruturado
2. perguntas tipadas: Noul pro sim/não, Choice pro segmento e estágio, Score pra maturidade e urgência
3. uma chamada só, com todas as perguntas avaliadas em paralelo
4. composite scoring com pesos no seu código
5. faixas de prioridade cruzadas com as faixas de confiança
6. tudo gravado no CRM como número e enum

O próximo passo prático é entrar na waitlist do early access e, enquanto a chave não sai, separar uma amostra de leads antigos que o time já qualificou manualmente. É com ela que você calibra peso e threshold, porque calibrar no escuro com lead novo é caro demais

Se quiser explorar outros caminhos de acesso, o Jev também está disponível como modelo na Cloudflare Workers AI, e a Vercel publicou um guia oficial de classificar, rotear e pontuar com Jev usando o AI SDK

Monta o schema, roda na amostra, ajusta os pesos… o resto é operação

Até o próximo post!