ユースケース
リードスコアリング
料金ページのフォームから、フィット度と購買段階を 1 つのリクエストでスコア化します。
問題
SDR はすべてのデモ申込を同じように扱い、強い意思を持つエンジニアを見逃します。
回答に対してコードが行うこと
フィットが強く、意図が evaluating または ready のときに営業を呼び出します。
1 つのフォームペイロード、3 つのシグナル
料金ページのペイロードが state です：company_size、role、リードが書いたメモ、source。3 つの質問が 1 回の呼び出しで返ります — fit（poor から strong のスコア）、intent（researching、evaluating、ready の選択）、contact_sales（はい／いいえ）。例では、月に 4 万チケットを振り分けているのに LLM コストが爆発しているというメッセージは、fit が強く、evaluating 段階のリードとして明瞭に読めます — 同じ日に人間の返信を払う価値がある人物のケースです。
営業が回答で何をするか
fit が強く、intent が evaluating か ready なら 24 時間以内に連絡します — 3 つの数字の上の、コード内の素朴なルールです。その基準を下回るものもすべて振り分けられます：fit の強い researching はナーチャリングへ、fit があるかもしれない evaluating は SDR キューへ、fit の弱いものはステップメールへ。モデルは書かれたメッセージを読みます — フィールドだけでなく "costs exploding" — なので、小さな会社からの真剣なメモが、従業員数でフィルタされる代わりに、見る価値ありとスコア化されます。
リードスコアリング特有の落とし穴
スコアに人間の判断を代用させないこと：スコアは誰に電話するかの情報であり、その決定 — とりわけ断るとき — の主体は人です。説明が実質 "anyone technical" であるような "strong fit" は万能の受け皿であり、万能の受け皿は間違ったキューを積み上げます。message フィールドは必ず含めること：これが最もシグナルの強い入力であり、落とすとすべてが静かにフィールドデータのルールへ劣化します。
リクエストの形状
これは、このプリセットについて Playground が送る完全なリクエストです — 自分のサーバーが Bearer キー付きで /v1/systemone に送るのと同じ JSON です。
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
- リードの判断は公平性に敏感な判断ですか？
- はい — 決まったレーンに留めてください：スコアは振り分けの情報であり、誰に電話し、誰を断るかは人が決めます。低信頼度のリードにはしきい値を設定し、自動のノーではなく人を待たせます。
- ルールが見逃すものを、モデルは何を捉えますか？
- ルールが完全に無視する message フィールドを読みます。勝ちパターンはたいてい、シグナルのための型付き判断＋コンプライアンスのための静的ルールの組み合わせです：国別の制限、既存顧客の重複排除、ベンダーリストのチェック。
- source フィールドは重要ですか？
- はい — state に渡します（"pricing page" 対 紹介による導入）。contact_sales の確率はその意図の文脈を読み、自分のルールはソースごとに別の重みを付けることもできます。