Caso de uso
Puntuación de leads
Puntúa encaje y etapa de compra desde un formulario de la página de precios en una sola solicitud.
El problema
Los SDR tratan toda solicitud de demo igual y se les escapan los ingenieros con alta intención.
Qué hace tu código con la respuesta
Avisa a ventas cuando el encaje sea fuerte y la intención evaluating o ready.
Un payload de formulario, tres señales
El payload de la página de precios es el estado: company_size, role, la nota que escribió el lead y la fuente. Tres preguntas vuelven en una llamada — fit (score de poor a strong), intent (choice entre researching, evaluating, ready) y contact_sales (sí/no). En el ejemplo, el mensaje sobre enrutar 40k tickets al mes con costes de LLM disparados se lee claramente como un lead de encaje fuerte en etapa evaluating — el caso donde la persona merece una respuesta humana el mismo día.
Qué hace ventas con la respuesta
Contacto en menos de 24 horas cuando el encaje es fuerte y la intención es evaluating o ready — una regla simple en código sobre tres números. Por debajo de esa barra todo se sigue enrutando: investigadores de encaje fuerte a nutrición, evaluadores de encaje posible a una cola de SDR, encaje débil a goteo. El modelo lee el mensaje escrito — «costes disparados», no solo los campos — así que una nota seria de una empresa pequeña puntúa como digna de mirar en lugar de filtrarse por plantilla.
Riesgos propios de la puntuación de leads
No dejes que el score sustituya la llamada humana: los scores informan a quién se llama, la gente es dueña de esa decisión — especialmente los rechazos. Un «encaje fuerte» cuya descripción es en realidad «cualquiera técnico» es un cajón de sastre, y los cajones de sastre cargan la cola equivocada. Incluye el campo del mensaje siempre: es la entrada de mayor señal, y quitarlo degrada todo en silencio a reglas sobre datos de campos.
La forma de la solicitud
Esta es la solicitud completa que el playground envía para este preset — el mismo JSON que tu servidor envía a /v1/systemone con una clave 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?"
}
}
}'Preguntas frecuentes sobre este caso de uso
- ¿Una decisión sobre leads es una decisión sensible a la equidad?
- Sí — manténla en un carril definido: los scores informan el enrutamiento, los humanos deciden a quién se llama y a quién se rechaza. Fija un umbral para los leads de baja confianza y deja que esos esperen a una persona en lugar de a un no automatizado.
- ¿Qué captura el modelo que las reglas no ven?
- Lee el campo del mensaje, que las reglas ignoran por completo. La combinación ganadora suele ser una decisión tipada para la señal más reglas estáticas para el cumplimiento: restricciones por país, deduplicación de clientes existentes, comprobaciones de listas de proveedores.
- ¿Importa el campo de la fuente?
- Sí — pásalo en el estado («página de precios» frente a una presentación por referencia). La probabilidad de contact_sales lee ese contexto de intención, y tus reglas pueden seguir ponderando las fuentes de forma distinta.