“这个问题，说明书里明明写了。”
做产品的人，看到重复咨询时很容易冒出这句话。可换到使用者的位置，情况可能完全不同：他正在赶一份报告，页面上有十几个按钮，根本不知道该去哪里找那段说明。
一次咨询是一个人的困难。同样的问题由不同的人反复问出来，就可能暴露了产品里的共同障碍。
英国 GOV.UK 的服务手册把用户咨询当作发现服务问题的线索，改进优先级还要结合影响范围和处理成本来判断。资料：GOV.UK
这也是“支持即研究”的意思。客服记录里不只有情绪和需求清单，还有用户拿着真实材料做事时，究竟在哪一步停了下来。那比一句抽象的“希望更好用”，更接近问题的形状。
举个假设例子，一款账单工具经常收到“日期不对”的反馈。开发者起初以为识别模型太弱，想换一个更贵的。仔细看才发现，有的表格把月写在前面，有的把日写在前面。系统选了一种解释，却没告诉用户。
这时，增加一个导入预览，让人看见日期被怎样理解，可能就比一大篇排错教程更有效。模型能力未必是根因，信息没有在需要的地方出现，才让同一个误会不断发生。
不过，支持对话也不是全部用户的样本。愿意来问的人往往还想把事做成；有人遇到困难，直接关掉页面，就不会留下工单。最爱提要求的人，也未必代表最常见的使用场景。
因此，咨询少了，不能自动算作进步。也许大家终于看懂了，也许大家连问都懒得问了。任务是否更容易完成，能够帮助分清两种情况。光看客服是否清闲，容易奖励错误的变化。
还有一种细节很值得看：用户说的解决办法，和他真正受阻的地方，可能不是同一回事。他要求增加十种导出格式，背后的困难也许只是现有表格打印后挤成一团。
我更愿意把这些对话看作产品在现实里留下的笔记。它们有偏差，却很具体。一次有价值的改进，可能不会带来更多好评，而是让下一位用户顺利走过去，连“这里曾经有问题”都不知道。