Caso de uso
Lead scoring
Pontue aderência e estágio de compra a partir de um formulário da página de preços, em uma única requisição.
O problema
SDRs tratam todo pedido de demo da mesma forma e perdem engenheiros de alta intenção.
O que seu código faz com a resposta
Acione vendas quando a aderência for forte e a intenção estiver em evaluating ou ready.
Um payload de formulário, três sinais
O payload da página de preços é o state: company_size, role, a nota que o lead escreveu e a origem. Três perguntas voltam em uma chamada — fit (score de poor a strong), intent (choice entre researching, evaluating, ready) e contact_sales (sim/não). No exemplo, a mensagem sobre rotear 40k tickets por mês com custos de LLM explodindo lê-se claramente como um lead de aderência forte e estágio evaluating — o caso em que a pessoa vale uma resposta humana no mesmo dia.
O que vendas faz com a resposta
Contato em até 24 horas quando a aderência é forte e a intenção é evaluating ou ready — uma regra simples em código sobre três números. Abaixo dessa barra, tudo continua roteado: pesquisadores com forte aderência para nurturing, avaliadores com possível aderência para uma fila de SDR, aderência fraca para drip. O modelo lê a mensagem escrita — "custos explodindo", não apenas os campos — então uma nota séria de uma empresa pequena pontua como valendo uma olhada, em vez de ser filtrada por headcount.
Pitfalls específicos de lead scoring
Não deixe o score substituir a decisão humana: scores informam quem recebe uma chamada, pessoas são donas dessa decisão — especialmente recusas. Um "strong fit" cuja descrição é, na verdade, "qualquer um técnico" é um pega-tudo, e pega-tudos carregam a fila errada. Inclua o campo de mensagem toda vez: é a entrada de maior sinal, e largá-lo degrada silenciosamente tudo para regras de dados de campos.
O formato da requisição
Esta é a requisição completa que o playground envia para este preset — o mesmo JSON que o seu servidor envia para /v1/systemone com uma chave Bearer.
curl https://jevai.website/api/v1/systemone \
-H "Authorization: Bearer $JEV_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"state": {
"form": {
"company_size": "200-500",
"role": "Head of Engineering",
"message": "We route ~40k support tickets a month with an LLM and costs are exploding. Looking for something faster."
},
"source": "pricing page"
},
"questions": {
"fit": {
"type": "score",
"instructions": "How well does this lead fit a developer API product?",
"criteria": [
"Poor fit",
"Possible fit",
"Strong fit"
]
},
"intent": {
"type": "choice",
"instructions": "What is their buying stage?",
"criteria": {
"researching": "Early research",
"evaluating": "Comparing options now",
"ready": "Ready to buy"
}
},
"contact_sales": {
"type": "noul",
"instructions": "Should sales reach out within 24 hours?"
}
}
}'FAQ sobre este caso de uso
- Uma decisão de lead é uma decisão sensível à justiça?
- Sim — mantenha-a em uma faixa definida: os scores informam o roteamento, humanos decidem quem é chamado e quem é recusado. Defina um threshold para leads de baixa confiança e deixe esses esperar por uma pessoa, em vez de um não automatizado.
- O que o modelo pega que as regras perdem?
- Ele lê o campo de mensagem, que as regras ignoram por completo. A combinação vencedora costuma ser uma decisão tipada para o sinal mais regras estáticas para compliance: restrições por país, dedupe de clientes existentes, checagens de listas de fornecedores.
- O campo source importa?
- Sim — passe-o no state ("página de preços" vs uma introdução por indicação). A probabilidade de contact_sales lê esse contexto de intenção, e as suas regras ainda podem ponderar origens de forma diferente.