用 Jev 做线索评估:匹配度、购买阶段和时间表
贴上一条来自表单、在线客服或邮件的入站消息,Jev 会告诉你:这条线索和你的产品匹配度如何、处于哪个购买阶段、有没有提到明确的时间表。结果是 CRM 可以直接分流的概率,而不是销售还得先读一遍的备注。
用你自己的文本试试
修改示例后运行。无需账号,每天免费 3 次。
场景
给一条销售线索的匹配度打分,并判断它处于哪个购买阶段。
可以随意修改,Jev 会针对这里的内容回答该场景的问题。
这个工具检查什么
上面的示例是一家 40 人物流公司发来的入站消息。他们想对收到的货运邮件做分类,每月大约 2 万封,需要在 Q1 之前上线,并询问团队套餐的价格,希望这周约个电话。Jev 在一次调用里回答三个问题:
| 问题 | 类型 | 返回什么 |
|---|---|---|
fit | Score | 在 Poor fit → Weak → Possible → Good → Ideal 五级上的位置,以及置信度 |
buying_stage | Choice | researching、evaluating、ready_to_buy 各自的概率,以及置信度 |
has_timeline | Noul | 线索提到明确时间表的概率,0 到 1 |
这条线索是个好测试,因为它卡在两个阶段之间。它说公司"正在评估工具",这正是 evaluating 的描述;但它又问了价格、约了电话,这恰好是 ready_to_buy 的定义。只给一个标签会把这种矛盾藏起来,而 buying_stage 上的概率分布会把它摆出来,置信度则告诉你要不要直接把线索交给销售。
消息很短,问题只有三个,所以这是一次标准评估:在 JevStation 上扣 1 点。三个问题针对同一份 state 并行作答,在匹配度和阶段之外再问一个时间表,几乎不增加延迟。
怎么写好线索评估问题
在匹配度问题里描述你的理想客户。 示例问的是线索和"一个 B2B API 产品"的匹配度,这是有意写得笼统。换成你真正卖的东西、真正会买的人,并给 Score 的每一级写一句说明。Jev 会按字面理解指令,所以"什么是好线索"的定义就写在评分表里。
阶段之间要互斥。 示例里每个选项都有一句定义:researching 是"刚开始了解这个问题",ready_to_buy 是"询问价格、合同或约电话"。如果两个阶段都可能完全成立,置信度就会因为与线索本身无关的原因而下降。把边界写进 criteria。
给时间表的 Noul 写上 criteria。 预设里只问了"线索是否提到明确的时间表?"。"Q1 之前""这周"算明确,"尽快"不算。把这点写清楚:
{
"type": "noul",
"instructions": "Does the lead mention a concrete timeline?",
"criteria": {
"true": "The lead names a date, a quarter, a week or a deadline for going live or deciding.",
"false": "The lead gives no time frame, or only a vague one such as soon or eventually."
}
}
数字交给代码。 "40 人""每月 2 万封邮件"正是销售最关心的细节,但 TypeSafe 把计数和数字比较列为弱项。如果公司规模或业务量决定线索等级,先做数据补全、在代码里比较,再把结果放进 state。
更多关于问法的内容,见设计 Jev 能回答的问题。
从一条线索到流水线里的一步
- 用已经有结果的线索回测。 50 到 200 条标好"成交""丢单""未转化"的历史线索,就足以看出 Jev 的回答在哪里把它们分开。批量页面可以对 CSV 里的每一行跑同一组问题,这一步不用写代码。
- 定几个区间,而不是一个阈值。
fit分高且ready_to_buy有把握的,立刻交给销售;evaluating有把握的,放进跟进序列;中间区间人工复核。 - 在一条规则里组合答案。 处于
ready_to_buy、同时has_timeline概率高的线索,就是今天该打电话的那一条。三个答案来自同一次调用,这条规则在 CRM 集成里就是一行代码。 - 记录答案。 保存各项概率,以及每次响应都会返回的
model字段。模型变化时重新校验阈值,销售的修正就是你下一批标注数据。 - 从表单处理程序里调用。 同样的评估可以用 API Key 通过 System One API 调用,扣点规则和试验台一样。
信任之前先验证
- 拿真实结果对比,而不是拿示例。 在一条消息上看着合适的阈值,不是你的阈值。用已知结果的线索来定。
- 关注中间区间。 如果大多数线索都落在两个阈值之间,说明阶段定义有重叠。先把 criteria 写清楚,再考虑加问题。
- 把 Score 当作阈值检查。 TypeSafe 说明 Score 各级在数值上的校准较弱,所以把
fit和一个分界线比较,而不是把两级之间的某个值当作精确分数。 - 非英文线索单独测试。 英文是 Jev 最强的语言,其他语言能处理,但效果不如英文。
哪些时候 Jev 不是合适的工具
- 你需要把回复写出来。 Jev 只返回带类型的答案。跟进消息交给生成式模型或销售。
- 评估依赖数字或日期。 员工规模档位、合同续约日期、预算门槛,都应该放在代码里。
- 你的理想客户画像每月都在变。 按一套定义调好的阈值,会随着评分表一起漂移。每次修改后重新跑一遍标注集。
- 每个分数都需要一个解释。 Jev 给出的是概率,不是理由。如果销售经理必须看到某条线索为什么被降级,就记录输入,并保留人工环节。
如果你在比较 Jev、通用 LLM 和自己训练的分类器,Jev 与 LLM 分类对比讲了各自适合的场景。成交之后进来的客服消息怎么分流,见客服工单分拣。
常见问题
- 怎么用 Jev 这样的 AI 评估入站线索?
- 把线索的原始消息作为 state 发送,也可以附上 CRM 里已有的字段,然后提出带类型的问题:用 Score 评匹配度,用 Choice 判断购买阶段,用 Noul 判断是否有时间表。Jev 在一次调用里回答全部三个问题,每个选项都有概率。
- 评估一条线索要多少钱?
- 在 JevStation 上,8,000 字符以内、最多 5 个问题的消息属于标准评估,扣 1 点。文字更长或问题更多扣 3 点。评估失败会自动退还。
- Jev 能替代我现有的线索评分模型吗?
- 它能替代其中"读自由文本"的那部分。公司规模、营收这类公司属性规则留在代码里——TypeSafe 把数字比较列为弱项——再把 Jev 的回答作为输入之一,汇入你的评分。
- Jev 能写跟进邮件吗?
- 不能。Jev 不生成文字。它决定先跟进哪些线索、多快跟进;回复仍由销售或生成式模型来写。
相关页面
把它接进你的流程
注册即送 200 点,保存自己的问题集,并通过 API 调用同样的评估。