Como usar o Jev para aprovar ou escalar pedidos de desconto do time comercial?

Sexta, 17h40, o vendedor manda mensagem: "cliente só fecha com um desconto fora da minha alçada, consigo aprovar?"

O gestor tá em reunião

A proposta esfria, o cliente some no fim de semana e na segunda vira aquele papo de "perdemos por preço"

O gargalo aqui quase nunca é a política de desconto, é o ser humano que precisa ler o caso e bater o martelo

É exatamente esse tipo de decisão repetitiva e de resposta curta que o Jev foi feito pra resolver

Ele é o primeiro modelo público da TypeSafe AI e é classificado como modelo System One: tu entrega um estado e perguntas tipadas, ele devolve decisões tipadas com probabilidades calibradas, em vez de texto

Ou seja: ele não escreve justificativa bonita, não conversa, não gera código

Ele escolhe, pontua e responde sim ou não, com um número de confiança do lado

E isso muda tudo pra um fluxo de aprovação, porque tu para de fazer parsing de parágrafo e passa a trabalhar com valor de campo mesmo 🙂

O que você precisa antes de começar

Tem duas metades aqui: a técnica e a do negócio

A técnica é rápida

Do lado técnico:

• Uma conta no console pra criar tua API key, em console.typesafe.ai
• Novas contas começam com US$ 5 de crédito, que equivalem a cerca de 120 milhões de tokens de entrada, então dá MUITA margem pra testar antes de colocar em produção
• SDK Python (pip install typesafe-sdk ou uv add typesafe-sdk, exige Python 3.10 ou superior) ou SDK JavaScript/TypeScript (npm install @typesafe-ai/sdk, exige Node.js 20 ou superior)
• A variável de ambiente TYPESAFE_API_KEY, que é de onde o cliente Python lê a chave

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

Sobre preço, vale saber antes de modelar: o Jev cobra apenas por token de entrada, a US$ 0,042 por 1 milhão de tokens, e a saída estruturada é gratuita

Isso tem uma consequência prática que volta lá embaixo: o que pesa na conta é o tamanho do teu state, não a quantidade de respostas

Do lado do negócio, e essa parte é a que o pessoal pula:

• A política de desconto escrita em faixas, com alçada clara (até quanto o vendedor aprova sozinho, até quanto o gestor, a partir de quanto sobe pra diretoria)
• A lista dos campos da proposta que vão virar state: valor, margem, desconto pedido, histórico do cliente, justificativa do vendedor

Se a política tá só na cabeça do gestor comercial, o Jev não vai adivinhar

Ele é bom em decidir dentro de um critério descrito, não em inventar o critério

Passo a passo: do pedido de desconto à decisão tipada

Os exemplos aqui vão em HTTP puro, que roda em qualquer linguagem

O endpoint é POST https://api.typesafe.ai/v1/systemone, com header Authorization: Bearer <API_KEY> e Content-Type: application/json

Os nomes exatos dos campos de cada tipo de pergunta tu confere na documentação de primitives, o que importa aqui é a forma de pensar o fluxo

Bora?

1. Modelar o state com a proposta:

O state é o conteúdo a avaliar e ele aceita string simples, objeto JSON ou array de textos

Pra desconto, objeto JSON é o formato natural, porque o pedido já é estruturado no teu CRM

{
  "cliente": "Alfa Log",
  "tipo_cliente": "recorrente",
  "meses_de_casa": 26,
  "valor_proposta": 48000,
  "margem_padrao_pct": 34,
  "desconto_pedido_pct": 18,
  "alcada_vendedor_pct": 10,
  "alcada_gestor_pct": 20,
  "inadimplencia": false,
  "justificativa_vendedor": "Concorrente entrou com proposta 15% menor e o cliente quer fechar ainda nesta semana"
}

Repara que eu coloquei a alçada dentro do state

Isso é de propósito: a regra vira dado, e não texto solto numa pergunta gigante

O erro comum deste passo: despejar a thread inteira do CRM ali dentro

O Jev tem janela de contexto limitada, e o preço é por token de entrada

Então mandar 40 e-mails de negociação faz duas coisas ruins ao mesmo tempo: encarece e dilui o sinal

Manda os campos que decidem, não o histórico emocional da conta 😀

2. Escrever as perguntas tipadas:

O Jev tem três tipos de pergunta (os primitives):

• Choice: escolher uma opção de um conjunto fixo sem ordem, com no máximo 255 opções
• Score: nota em níveis ordenados que você descreve, de 2 a 10 níveis
• Noul: sim ou não, que retorna a probabilidade de sim

Pro nosso caso isso mapeia quase que sozinho

O Choice vira a rota da decisão, o Score vira o risco de margem, o Noul vira a checagem de alçada

{
  "rota_aprovacao": {
    "type": "choice",
    "question": "Considerando a política de alçadas presente no estado, qual rota este pedido de desconto deve seguir?",
    "options": [
      "aprovar",
      "escalar_gestor",
      "escalar_diretoria",
      "recusar"
    ]
  },
  "risco_margem": {
    "type": "score",
    "question": "Qual o risco deste desconto para a margem do negócio?",
    "levels": [
      "muito baixo: desconto dentro da faixa padrao e margem preservada",
      "baixo: margem levemente reduzida, ainda confortavel",
      "medio: margem apertada, exige atencao",
      "alto: margem perto do limite aceitavel",
      "muito alto: desconto compromete a margem do contrato"
    ]
  },
  "dentro_da_alcada": {
    "type": "noul",
    "question": "O desconto pedido esta dentro da alcada do vendedor informada no estado?"
  }
}

As chaves (rota_aprovacao, risco_margem, dentro_da_alcada) são definidas por você, e as respostas voltam sob as mesmas chaves

Isso é o que deixa o código limpo depois: nada de regex em resposta de modelo

O erro comum deste passo: pergunta torta

A documentação lista como limitação conhecida do Jev a perda de acurácia em dupla negativa, indireção complexa e raciocínio de múltiplos saltos

Então nada de "este desconto não está fora da alçada, considerando que o cliente não é novo?"

Quebra em perguntas simples e independentes, que é justamente o que o modelo faz bem

3. Montar a requisição e ler as respostas:

O corpo tem três partes: state, model e questions

O modelo padrão dos exemplos da doc e dos SDKs é o alias jev-latest

import os
import requests

resp = requests.post(
    "https://api.typesafe.ai/v1/systemone",
    headers={
        "Authorization": f"Bearer {os.environ['TYPESAFE_API_KEY']}",
        "Content-Type": "application/json",
    },
    json={
        "state": proposta,       # o dict do passo 1
        "model": "jev-latest",
        "questions": perguntas,  # o dict do passo 2
    },
)

respostas = resp.json()
rota = respostas["rota_aprovacao"]
risco = respostas["risco_margem"]
alcada = respostas["dentro_da_alcada"]

Choice e Score voltam com um valor de confidence entre 0 e 1, calculado a partir da distribuição de probabilidade da própria resposta

Noul não tem campo separado de confidence, porque a distribuição só tem dois resultados: o próprio valor já é a probabilidade de sim

O erro comum deste passo: esperar um parágrafo explicando a decisão

Não vem, e não é bug

O Jev não gera texto, não escreve código e não mantém conversa, ele aceita só entrada de texto (string, objeto JSON ou array) e devolve decisão tipada

Se o teu processo exige justificativa escrita pro vendedor, essa parte é do teu template ou de um modelo generativo, não dele

4. Mandar tudo numa requisição só:

Esse passo é o que mais economiza dinheiro e tempo

Cada pergunta é avaliada de forma independente contra o mesmo state

Ou seja: mandar N perguntas numa requisição dá as MESMAS respostas que N requisições separadas, só que tu paga o custo do documento uma vez só e as perguntas rodam em paralelo

O erro comum deste passo: fazer uma chamada por pergunta

Três chamadas separadas com o mesmo state significa pagar três vezes pelos mesmos tokens de entrada e comer três round trips de rede

Junta tudo no mesmo questions e pronto

5. Rotear por confidence no seu código:

O último passo é onde o pessoal erra de conceito: o modelo não decide o que é automático e o que sobe pra humano

Ele te dá a decisão e o quanto ela é confiável

Quem decide o que fazer com isso é o teu if

E quais números usar nesse if? O padrão de Confidence-gated routing da documentação já dá dois pontos de partida: um piso de 0,6, pra descartar os casos genuinamente incertos, e limiar acima de 0,85 pra ação de alto risco, tipo aprovar sozinho

No código fica assim:

PISO = 0.6
LIMIAR_APROVAR = 0.85

if rota["confidence"] < PISO:
    encaminhar_para_humano(proposta, motivo="confianca abaixo do piso")
elif rota["value"] == "aprovar" and rota["confidence"] >= LIMIAR_APROVAR:
    aprovar_desconto(proposta)
else:
    escalar(proposta, rota["value"])

O erro comum deste passo: tentar embutir a regra de escalonamento dentro do enunciado da pergunta, tipo "se você não tiver certeza, responda escalar"

Isso joga fora a informação mais valiosa que o Jev te dá, que é a probabilidade calibrada

Deixa o modelo responder o que ele acha e deixa o threshold no código, onde tu consegue versionar, medir e mudar sem retreinar nada

Como calibrar os limiares para escalar sem travar o vendedor

A documentação recomenda dividir a confiança em três faixas: alta (agir automaticamente), média (prosseguir com cautela) e baixa (mandar para um humano)

E o padrão de Confidence-gated routing deixa claro uma coisa que eu acho a parte mais importante disso tudo: o limiar não é um número único

Cada ação recebe um limiar conforme a consequência do erro

O piso sugerido é 0,6, pra descartar os casos genuinamente incertos, e ações de alto risco pedem limiar acima de 0,85 (o exemplo da própria doc é aprovar transferência)

Traduzindo pro comercial:

Repara na assimetria: escalar errado custa alguns minutos de alguém

Aprovar errado ou recusar errado custa margem ou custa o contrato

Por isso escalar pode viver com limiar mais baixo, e é justamente isso que evita travar o vendedor: no meio termo o pedido continua andando, só que com um par de olhos humanos junto

Nada de deixar a proposta parada esperando certeza absoluta

Se tu quiser aprofundar esse ajuste fino, tem um material dedicado a definir thresholds de confiança que entra na lógica de agir, escalar ou recusar

E lembra do detalhe do Noul: ele não traz confidence separado

O valor devolvido JÁ é a probabilidade de sim

Então dentro_da_alcada em 0,93 significa "muito provavelmente está dentro da alçada", e um valor perto de 0,5 é o modelo te dizendo que a informação no state não resolve essa pergunta

Quando isso acontecer, o problema quase sempre é o state, não a pergunta 😛

Três cenários comuns de desconto e como configurar cada um

Bora aterrissar em caso real de operação comercial

Cenário 1: desconto na faixa padrão, cliente recorrente

Desconto pedido dentro da alçada, cliente de casa, sem inadimplência

Aqui o Noul de alçada volta alto, o Score de risco de margem cai nos níveis baixos e o Choice aponta aprovar

Configuração: mantém o limiar de aprovação acima de 0,85 e exige as duas condições juntas (Choice em aprovar com confiança alta e Noul de alçada alto)

É o caso que libera o vendedor na sexta às 17h40 sem acordar ninguém

Cenário 2: acima da alçada, justificativa fraca

O desconto pedido passa da alçada do vendedor e a justificativa é genérica, tipo "cliente pediu"

Nesse cenário vale acrescentar um Noul específico:

{
  "justificativa_sustenta": {
    "type": "noul",
    "question": "A justificativa do vendedor apresenta um motivo concreto e verificavel para o desconto solicitado?"
  }
}

Se esse Noul vem baixo e o Score de risco de margem vem nos níveis altos, a rota natural é escalar_gestor

E como escalar é barato de errar, tu roda com limiar mais folgado, perto do piso

O gestor recebe o caso já com a leitura pronta: fora da alçada, risco de margem alto, justificativa fraca

A decisão dele leva 20 segundos em vez de 20 minutos

Cenário 3: dados incompletos ou confiança abaixo do piso

Proposta sem margem preenchida, cliente novo, campo de histórico vazio

O Choice vai voltar com confiança baixa, e é EXATAMENTE pra isso que existe o piso de 0,6

Abaixo dele, humano, sem discussão

E aqui tem um truque de operação: loga o caso com os campos que faltavam no state

Depois de algumas semanas tu descobre que metade dos casos de baixa confiança é sempre o mesmo campo vazio no CRM, e o conserto não é no prompt, é no formulário 😀

Esse raciocínio de roteamento por faixa não serve só pra desconto, é o mesmo motor de quem usa o modelo pra priorizar leads no funil, muda o state e mudam as perguntas

Um conteúdo extra do canal

Saindo um pouco da API e indo pro lado humano da coisa

Este vídeo do canal fala sobre o sentimento de não ter vocação para TI e o que fazer quando ele aparece

Próximo passo

Recapitulando o fluxo inteiro

Tu modela o state com os campos da proposta que realmente decidem, escreve as perguntas tipadas (Choice pra rota, Score pro risco de margem, Noul pra alçada), manda tudo numa requisição só e aplica o roteamento por confidence no teu código, com limiar diferente por ação

O Jev entra como a camada que transforma "posso dar esse desconto?" numa decisão estruturada com probabilidade do lado

E o próximo passo eu não recomendaria de outro jeito: começa em modo sombra

Roda uma pergunta Choice em cima dos pedidos de desconto que já estão acontecendo, guarda a resposta e a confiança, e compara com a decisão que o gestor tomou

Sem automatizar nada ainda

Depois de algumas dezenas de casos tu vai ter dado real pra escolher teus limiares, em vez de chutar 0,85 porque alguém na internet escreveu 0,85

Os US$ 5 de crédito inicial dão bastante fôlego pra essa fase de comparação, ainda mais considerando que a saída não é cobrada

E aí tu automatiza a faixa alta primeiro, que é a mais segura, e vai subindo conforme a confiança no processo (a tua, não só a do modelo) aumenta

até o próximo post!