服务器显示请求只用了三秒，客户却说“弄了一下午”。
两边可能都没有说错。服务器从收到请求开始计时，客户从找资料、申请权限、研究怎么上传时，就已经在等了。
产品里有个概念，叫“获得首次价值的时间”。通俗点说，就是从开始接触，到第一次拿到对自己有用的结果，中间到底隔了多久。页面加载快，只覆盖这段路的一小部分。
Intercom曾在一篇接入流程复盘中写到：决定采用产品的人与实际实施的人不同，后者缺少技术支持，原来的接入方式因此成了障碍。案例来源 对产品团队来说是几个配置步骤，对客户来说却可能涉及找人、协调和等待。
这个例子很适合解释“功能已经做好，为什么用户仍然用不起来”。
假设一个AI库存工具可以很快识别异常。用户真正开始之前，却需要把几个店铺的数据下载下来，统一列名，再补上缺失字段。等这些完成，模型的几秒钟反而不是最费时的部分。开头那句“一下午”，说的是整件事。
示例也不能完全代替自己的结果。看到演示，用户知道工具可能有用；用自己的表格找出一项可以核实的问题，才知道它能进入自己的工作。两种体验都有价值，只是走到的位置不同。
我在理解自动化流程时，更愿意把这些等待都放进来。一个步骤从十秒变成两秒，如果前面还要等同事一天，整体感受可能变化不大。反而是一份更容易理解的模板，可能减少许多反复确认。
不过，“更快”也不能变成跳过必要核对的理由。资料有缺口，直接给出一个完整答案，表面上结束了等待，后面可能要付出更大的纠错成本。客户需要的是可信的结果，速度只是其中一个条件。
评价这段时间时，还容易漏掉那些没有到达终点的人。只看成功用户平均花了多久，可能看不见在上传或配置阶段已经离开的用户。他们的等待，没有进入那张漂亮的平均值报表。
所以，系统响应快值得高兴，但它尚未讲完客户的经历。那位用户如果还在找负责开权限的同事，三秒钟的成绩单，暂时帮不了他结束这一下午。