概览
客服团队随客户数线性膨胀，因为没有人去做那项能打断这种关联的分析。那个工单量不是一千个不同的问题——它是二十个问题各来了一千次，而每一个都有一个解法，而那个解法不是「答得更快」。
工单系统的类目揭示不了它们。类目是由关闭工单的那个人在时间压力下、从一个两年前设计的下拉菜单里选的。「账单」里装着四个互不相干的问题。「其他」里装着那些有意思的。
而那个解法很少是一篇帮助文档。这个假设被烤进了市面上每一个工单转移工具里，而它在大多数时候是错的。一个反复出现的工单，通常意味着产品做了一件让人意外的事、一条报错信息没有告诉用户该做什么，或者上手引导里的某一步被跳过了。为一个让人困惑的按钮写一篇文档，治的是症状，而工单量从来不会真的下降。
这个智能体按底下那个问题把工单分组，算出每一簇在工单数和处理时长上的代价，并说明哪一类修补能终结它——点名那个产品改动、那句措辞、那个上手步骤或那份文档。它不回答任何工单，也不写任何文档：它告诉你该把一名工程师的一周花在哪里，好让一千张工单变成五十张。
价值
真的会下降的工单量
因为成因被修掉了，而不是被写成了文档。
一份有排序的工程投入理由
每一条诉求都附着它的工单成本。
客服不再随客户数膨胀
而那是这门生意的经济账唯一会改变的方式。
功能说明
按问题分组，而不是按类目
那个下拉菜单是两年前设计的，而且是在时间压力下选的。「其他」里才是那些有意思的工单。
点名那一类修补
产品改动、报错措辞、上手引导缺口，还是文档。假定它永远是一篇帮助文档，正是工单量从不下降的原因。
给每一簇算成本
工单数、处理时长和重复联系。那才是能为这处修补出钱的那个数字。
找出那些又回来的工单
一张被解决又重开的工单，是一个比「处理得很久」更糟的信号。
把困惑和故障分开
两者都产生工单。只有一个是缺陷，而它们由不同的团队来修。
不回答任何东西
它从不回复客户，也从不发布文档。它告诉你一名工程师的一周花在哪里能回本。
这会改变什么
这会如何改变你的一周
- 它接手的工作
- 找出工单量背后那些反复出现的成因。
- 目前由谁完成
- 没有人，因为工单类目让它看起来已经被回答过了。
- 多久一次
- 从不，而这正是客服随客户数膨胀的原因。
- 通常的人工投入
- 把成千上万张工单按底下那个问题、而不是按某人随手选的下拉项重新分组。
为什么偏偏是客户支持。每一个工单转移工具都假定那个解法是一篇帮助文档。而它通常是一个产品改动、一条报错信息或者一个被跳过的上手步骤——所以工单量从来不会真的下降。
无人值守运行
由你或某个事件启动，然后自行完成。没有什么需要等人坐到工位前。
每一次都是同一标准
第两百件与第一件用同一把尺子衡量。一致性正是人做不到长期保持的部分。
它无法自行采取行动
支持工单减负分析代理 没有任何发送、支出或承诺的途径。正是这个限制，让依据它的输出行动是安全的。
运行方式
该智能体通过 PROMIVO 运行时在服务器端运行。每次运行都会逐步记录，每次工具调用在执行前都会进行权限检查。
- 1输入按智能体的输入结构进行校验
- 2模型claude-opus-5，并自动回退
- 3工具search_knowledge, extract_structured_data
- 4权限自动执行 READ 级操作；更高的等待你批准
- 5输出符合输出结构的结构化结果
- 6日志记录 token、耗时和每一个步骤
演示
演示数据Illustrative sample output, abridged.
输入
{
"period": "Q3 2026",
"tickets": []
}输出
{
"clusters": [
{
"trend": "growing",
"theFix": "The export screen shows the same state for 'running' and 'failed'. A distinct failed state with the reason would end this cluster. It is not a documentation problem — an article cannot tell someone what their own export did.",
"fixType": "error-wording",
"problem": "Customers cannot tell whether an export finished or failed.",
"tickets": 214,
"examples": [
"\"Has my export worked? It has said the same thing for an hour.\""
],
"reopenRate": 18,
"handlingHours": 61,
"documentedAlready": true,
"shareOfHandlingTime": 22.4,
"cutsAcrossCategories": [
"Billing",
"Technical",
"Other"
]
},
{
"trend": "growing",
"theFix": "Apparent breakage rather than confusion — a third of these reopen, which means the workaround does not hold. Reproduce before writing anything.",
"fixType": "product-change",
"problem": "Second and third users at an account never receive their invitation.",
"tickets": 88,
"examples": [
"\"I have invited my colleague three times and nothing arrives.\""
],
"reopenRate": 31,
"handlingHours": 25,
"documentedAlready": false,
"shareOfHandlingTime": 9.1,
"cutsAcrossCategories": [
"Account",
"Other"
]
}
],
"escalate": true,
"disclaimer": "An analysis of your own ticket history. No ticket has been answered or changed, nothing has been published, no customer has been contacted, and no identifying customer detail appears in this output.",
"genuineTail": "41% of tickets are genuinely one-off and do not cluster. Any tool that tells you otherwise is manufacturing groups.",
"escalationReason": "The largest cluster is 22.4% of handling time and growing, and one cluster shows apparent breakage affecting multiple accounts with a 31% reopen rate."
}使用条件
集成
无需集成。
开始之前
- 工单历史：标题、正文、解决方式、耗时、重开次数
- 现有帮助文档，如果你想核对覆盖情况的话
- 需要 全量访问 套餐或更高
使用场景
季度客服复盘
那些簇、它们的成本，以及什么能终结每一个。
在增招客服之前
这个工单量是真实的，还是自找的。
一次发版之后
新版本让人们开始问什么。
为工程排优先级
带着工单成本的产品问题。
价格
常见问题
它会回复工单或撰写文档吗？
不会。它是一个分析师，不是一个跟客户对话的智能体。发布一个答案是一项关于你的口吻和你的准确性的决定，它属于你的团队。
为什么不直接用我们的工单类目？
因为它们是错的。它们是在时间压力下、从一个陈旧的下拉菜单里选的，而真正重要的那些簇是横切它们的。重新分组，正是这项工作本身。
它会读到客户个人数据吗？
它读工单内容，而那里面可能含有个人信息。它报告的是簇，绝不在输出里复述客户的可识别信息。
评价
客户运行过该智能体后，评价功能将开放。
需要这个智能体换一种做法？
告诉我们要改什么，我们的团队会为您的业务规划一个定制版本。
定制此智能体