用 Jev 做线索评估:匹配度、购买阶段和时间表

贴上一条来自表单、在线客服或邮件的入站消息,Jev 会告诉你:这条线索和你的产品匹配度如何、处于哪个购买阶段、有没有提到明确的时间表。结果是 CRM 可以直接分流的概率,而不是销售还得先读一遍的备注。

用你自己的文本试试

修改示例后运行。无需账号,每天免费 3 次。

场景

给一条销售线索的匹配度打分,并判断它处于哪个购买阶段。

217 / 2,000

可以随意修改,Jev 会针对这里的内容回答该场景的问题。

这个工具检查什么

上面的示例是一家 40 人物流公司发来的入站消息。他们想对收到的货运邮件做分类,每月大约 2 万封,需要在 Q1 之前上线,并询问团队套餐的价格,希望这周约个电话。Jev 在一次调用里回答三个问题:

问题类型返回什么
fitScore在 Poor fit → Weak → Possible → Good → Ideal 五级上的位置,以及置信度
buying_stageChoiceresearching、evaluating、ready_to_buy 各自的概率,以及置信度
has_timelineNoul线索提到明确时间表的概率,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 能回答的问题。

从一条线索到流水线里的一步

  1. 用已经有结果的线索回测。 50 到 200 条标好"成交""丢单""未转化"的历史线索,就足以看出 Jev 的回答在哪里把它们分开。批量页面可以对 CSV 里的每一行跑同一组问题,这一步不用写代码。
  2. 定几个区间,而不是一个阈值。 fit 分高且 ready_to_buy 有把握的,立刻交给销售;evaluating 有把握的,放进跟进序列;中间区间人工复核。
  3. 在一条规则里组合答案。 处于 ready_to_buy、同时 has_timeline 概率高的线索,就是今天该打电话的那一条。三个答案来自同一次调用,这条规则在 CRM 集成里就是一行代码。
  4. 记录答案。 保存各项概率,以及每次响应都会返回的 model 字段。模型变化时重新校验阈值,销售的修正就是你下一批标注数据。
  5. 从表单处理程序里调用。 同样的评估可以用 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 调用同样的评估。