用 Jev 分拣客服工单:团队、紧急程度与流失风险

粘贴一条客户消息,Jev 会告诉你该由哪个团队处理、在五级量表上有多紧急、客户即将流失的概率有多大——返回的是工单系统可以直接用来分派的数字,而不是需要人去读的一段摘要。

用你自己的文本试试

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

场景

把工单分给对应团队,评估紧急程度,并标记流失风险。

166 / 2,000

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

这个分拣检查什么

上面的示例是一张很典型的工单:客户连续三天连接 Stripe 账户失败,一直报 invalid redirect 错误,说自己每小时都在丢订单,希望尽快解决。Jev 在一次调用里回答关于它的三个问题:

问题类型返回什么
categoryChoicebilling、integrations、bug、account 各自的概率,以及置信度
urgencyScore在 Can wait → Normal → Soon → Urgent → Critical 上的位置,以及置信度
churn_riskNoul客户有流失风险的概率,0 到 1

这张工单适合拿来测试,因为它恰好卡在两个队列之间。它提到了 Stripe,听起来像 billing;但问题本身是连接第三方服务,这正是 integrations 的定义。只给一个标签会把这种拉扯藏起来,而 category 的概率分布会把它摆出来,置信度则告诉你这张工单能不能自动分派,还是该交给人。

state 很短,问题只有三个,所以这是一次标准评估:在 JevStation 上消耗 1 点。三个问题针对同一个 state 并行回答,所以在分派之外再问一句流失风险,几乎不增加延迟。

怎样写出有效的分拣问题

给每个团队写说明,而不只是写名字。 示例给每个选项都写了一行标准——integrations 是 "Connecting or syncing a third-party service",bug 是 "The product behaves incorrectly"。只写名字,Jev 就得猜你的边界在哪。说明文字就是你把客服团队实际分工方式写进去的地方。

让各团队互斥。 如果两个选项可以同时完全正确,概率会在两者之间分散,置信度会因为与工单本身无关的原因而下降。一张工单确实同时属于两个团队时,先派给主要负责方,再由对方拉另一个团队进来。

紧急程度用 Score,不要用 Choice。 紧急级别是有顺序的,Score 会保留这个顺序:答案是量表上的一个值,可以落在两个级别之间,你可以直接对它设阈值。像示例那样用五个简短的级别,比一个"是否紧急"的是非题更能把工单排出先后。

流失风险单独问。 一个语气平静但扬言要取消的客户,和一个很生气但绝不会走的客户,需要不同的处理方式。给 Noul 写上明确的标准,界线会更清楚:

{
  "type": "noul",
  "instructions": "Is the customer at risk of churning?",
  "criteria": {
    "true": "The customer mentions cancelling, switching providers, or lost revenue they blame on us.",
    "false": "The customer reports a problem but gives no sign of leaving."
  }
}

问题怎么措辞,详见设计 Jev 能回答的问题。

从一张工单到一个分拣环节

  1. 收集团队已经分派过的工单。 50 到 200 张真实工单,加上最终负责的团队,就足以看出 Jev 的置信度能不能把正确分派和错误分派区分开。
  2. 划分区间,而不是只定一个阈值。 高于你信得过的置信度就自动分派,中间一段进人工分拣队列,其余的复核。紧急程度也一样:只有 Score 高过某个值才呼叫值班人员,而不是只看排第一的级别。
  3. 按组合升级。 urgency 分数高、同时 churn_risk 概率也高的工单,应该插队处理。两者来自同一次调用,所以在工单系统集成里写成规则只需要一行。
  4. 记录答案。 保存概率,以及 API 返回的 model 字段。客服改派工单时,这次纠正就是你的下一批标注数据。
  5. 从工单系统里调用。 同样的评估可以用 API Key 通过 System One API 调用,扣点和试验台一样。示例里的每个问题都可以原样发送。

分拣一次要花多少

在 JevStation 上,一张工单只要不超过 5 个问题、不超过 8,000 字符,就消耗 1 点,这里的三个问题绰绰有余。很长的邮件往来或超过 5 个问题消耗 3 点,state 上限是 24,000 字符。新账号注册即送 200 点,30 天内有效;之后按一次性点数包购买:$9.90 购 5,000 点,或 $15.90 购 12,000 点。详见定价页。

如果想多问几个问题——语言、产品模块、是否重复工单——就加进同一次调用,而不是再发一次。5 个以内的问题仍然只消耗 1 点。

什么时候不该用 Jev 分拣

  • 你需要书面摘要或回复。 Jev 只返回类型化答案。如果客服需要在工单顶部看到摘要,就配一个生成式模型。
  • 分派规则依赖计数或日期。 "这个客户这周是不是开了三张工单?""合同是不是已经过了续约日?"这些是 TypeSafe 明确记录的短板。在代码里算好,把结果放进 state。
  • 你的队列不稳定。 如果团队列表每周都在变,调好的阈值也会跟着漂移。每次改动选项后都要重新检查。
  • 队列大部分不是英文。 先单独测一遍。

如果你在为这件事权衡 Jev、通用 LLM 和自己训练的分类器,Jev 对比 LLM 分类和 Jev 的替代方案讲清了各自什么时候更合适。

常见问题

怎样用 Jev 按团队和紧急程度给工单分类?
把工单正文作为 state,问两个类型化问题:一个列出各团队的 Choice,一个按顺序列出紧急级别的 Score。Jev 在同一次调用里回答两者,每个团队、每个级别都有概率。
分拣一张工单要多少钱?
在 JevStation 上,不超过 8,000 字符、不超过 5 个问题的工单属于标准评估,消耗 1 点。更长的邮件往来或更多问题消耗 3 点。评估失败会自动退还点数。
Jev 能替我写给客户的回复吗?
不能。Jev 不生成文本,它只决定工单去哪、多快处理;回复仍然交给人或生成式模型来写。
Jev 能处理非英文工单吗?
TypeSafe 的文档说能处理其他语言,但效果不如英文。如果你的队列里有大量其他语言的工单,请先单独在这部分工单上测准确率,再定阈值。
可以换成我自己的团队,而不是示例里的四个吗?
可以。Choice 的选项完全由你定义。把 billing、integrations、bug、account 换成你真实的队列,并给每个选项写一行说明。

相关页面

把它接进你的流程

注册即送 200 点,保存自己的问题集,并通过 API 调用同样的评估。