概览
每一家公司收集到的反馈，都远多于它用掉的。评价、问卷留言、客服工单、销售通话记录、流失原因、应用商店评分——每一个来源归一个不同的团队所有，而他们只读自己那一份。
那种割裂，恰好把唯一值得知道的东西藏了起来。一条抱怨出现在一个渠道里是噪声。同一条抱怨出现在评价里、出现在流失原因里、也出现在销售异议里，那就是一项公司级优先事项，而没有哪个团队看得见它，因为没有哪个团队同时看到这三处。
那两种标准做法各自以不同的方式失败。情感评分产出一个会波动、却永远不告诉任何人该做什么的数字。人工打标签准确，而且在一个月内就会停下来，因为没有人有时间。
真正有用的做法很具体、也不体面：把一切按「被描述的那个问题」分组，数一数有多少个独立来源提到它，按背后的收入加权，并把人们说的和人们要的分开。客户描述症状、也提出解法——症状是有用的那一半，而照字面去执行他们提的解法，正是产品最后长出一百个没人想要的功能的方式。
这个智能体跨你拥有的每一个来源去做那次阅读，并报告如果每个主题被修好会带来什么变化。它不回复任何东西，也绝不引用客户的可识别信息。
价值
一份优先级清单，而不是六份
而那是一个管理团队唯一能据以行动的版本。
给路线图的证据
带来源和收入的主题，而不是轶事。
那些优点被保护住
因为你知道人们真正点名了哪些。
功能说明
数独立来源，而不是数提及次数
一个在评价、流失原因和销售异议里都被提到的主题是一项优先事项。一个渠道里的五十次提及，说明的是那个渠道。
把症状和诉求分开
客户描述一个问题，并提出一个解法。照字面去执行那个提议，正是你上线一堆没人想要的功能的方式。
按收入加权，而不是按数量
声音最大的那个分群很少是最有价值的那个，而单看数量永远指向声音最大的那个。
追踪一个主题是否在扩散
一条稳定的抱怨和一条正在蔓延的抱怨，需要非常不同的回应。
找出人们称赞什么
那是你在改版时绝不能弄坏的东西。从来没有人去汇总它，而它确实有用。
不引用任何人
它不复述任何客户姓名、账号或可识别信息。举例一律改写。
这会改变什么
这会如何改变你的一周
- 它接手的工作
- 把评价、问卷、工单、流失原因和通话记录放在一起读。
- 目前由谁完成
- 五个不同的团队，各自只读自己那一个来源。
- 多久一次
- 最好也就每季度一次，而且只按渠道来做。
- 通常的人工投入
- 成千上万段文字，必须按问题、而不是按出处来分组。
为什么偏偏是研究。一条抱怨出现在一个渠道里是噪声；同一条出现在三个渠道里就是一项公司级优先事项——而没有哪个团队看得见它。情感分数会波动，却不告诉任何人该做什么。
无人值守运行
由你或某个事件启动，然后自行完成。没有什么需要等人坐到工位前。
每一次都是同一标准
第两百件与第一件用同一把尺子衡量。一致性正是人做不到长期保持的部分。
它无法自行采取行动
客户之声代理 没有任何发送、支出或承诺的途径。正是这个限制，让依据它的输出行动是安全的。
运行方式
该智能体通过 PROMIVO 运行时在服务器端运行。每次运行都会逐步记录，每次工具调用在执行前都会进行权限检查。
- 1输入按智能体的输入结构进行校验
- 2模型claude-opus-5，并自动回退
- 3工具search_knowledge, extract_structured_data
- 4权限自动执行 READ 级操作；更高的等待你批准
- 5输出符合输出结构的结构化结果
- 6日志记录 token、耗时和每一个步骤
演示
演示数据Illustrative sample output, abridged.
输入
{
"period": "Q3 2026",
"feedback": []
}输出
{
"themes": [
{
"theme": "Setting up a second team is unclear and often done wrong",
"trend": "growing",
"examples": [
"A customer described creating three teams before understanding what a team was for."
],
"customers": 74,
"sourceList": [
"Reviews",
"NPS comments",
"Support tickets",
"Churn reasons",
"Sales call notes"
],
"revenueTouched": 1240000,
"whatTheyAskFor": "A duplicate-team button. Building that would not solve it — the request is a workaround for not understanding what a team is.",
"describedProblem": "People cannot tell whether a second team shares data with the first, so they either avoid creating one or create it wrongly and discover it weeks later.",
"independentSources": 5
}
],
"praised": [
"Speed of the reporting export is named unprompted in 41 pieces of feedback. Whatever the redesign does, it must not slow this down."
],
"escalate": true,
"disclaimer": "An analysis of feedback you already hold. Nothing has been replied to or published, no customer contacted, no identifying detail reproduced, and examples are paraphrased. Themes appearing in churn feedback are correlated with churn, not shown to have caused it.",
"channelBias": "Support tickets are 61% of the volume. Theme rankings are reported by independent sources to correct for it.",
"sourcesRead": [
"Reviews",
"NPS comments",
"Support tickets",
"Churn reasons",
"Sales call notes"
],
"thinEvidence": [
"Two themes rest on 3 customers each and are reported as thin rather than ranked."
],
"escalationReason": "One theme appears in all five sources at once, touches 1.24m of revenue, and is growing across three periods.",
"volumeVersusRevenue": "By volume, the top theme is mobile layout. By revenue it is eleventh. The teams raising it are on the smallest plans, and volume alone would have pointed the roadmap at it."
}使用条件
集成
无需集成。
开始之前
- 你手上有的任何来源的反馈：评价、问卷留言、工单、流失原因、通话记录
- 各客户的账户价值，如果你想按收入加权的话
- 需要 全量访问 套餐或更高
使用场景
季度路线图输入
客户真正提出了什么，排好序、有据可依。
一段评价很差的时期之后
它到底是一个主题，还是很多个。
流失分析
离开的人说了什么，对照现有客户正在说什么。
改版之前
该修什么，以及不该碰什么。
价格
常见问题
这是情感分析吗？
不是。一个情感分数会波动，却不告诉任何人该做什么。这个报告的是被点名的问题、有多少个独立来源提到它，以及它们背后有多少收入。
它会回复评价或客户吗？
不会。它从不发布、回复或联系任何人。它是一个分析师。
它怎么处理个人数据？
它读的反馈里可能含有个人信息，而它一条都不复述。输出里的例子一律改写，绝不带可识别信息地引用。
评价
客户运行过该智能体后，评价功能将开放。
需要这个智能体换一种做法？
告诉我们要改什么，我们的团队会为您的业务规划一个定制版本。
定制此智能体