2021 年，PostHog 在一篇官方文章里介绍了一项排班：每次由一位工程师拿出完整一周，暂停原来的开发任务，负责接住用户的问题。
这里最有分量的，是“完整一周”。团队没有把支持工作当作写代码间隙顺便处理的事，而是明确给它留出时间。那位当值工程师要查看不同渠道的求助，能解决的自己处理，需要其他知识的就找同事帮忙。
这项安排之前，支持工作主要由两位创始人 James 和 Tim 承担。Mo Shehu 在 2021 年 6 月 15 日的文章中回顾，早期人手有限，需要大家一起做。后来有了轮值，其他工程师也没有因此免除帮助用户的责任。
这是一份当年的工作记录。页面如今也提示，团队后来改变了优先联系渠道，旧文保留供回看。我们能从中讨论一种安排，不能把里面的人员配置、渠道和工具当作今天仍完整沿用的制度。
这段故事让我注意到，创业团队说“重视反馈”时，往往还缺少一个具体决定：谁的哪段时间，可以因为用户的问题而改变？
如果一位工程师既要完成排满的迭代，又要随时处理支持，用户的每次求助都像插队。即使团队口头上认为支持重要，日程仍在告诉他，真正需要交付的是原来的功能。PostHog 当年的安排，至少明确承认了这两类工作会争用同一份时间。
不过，留出时间还不是终点。把这次问题处理好，与让下一位用户少遇到同样的问题，需要不同的动作。
假设我们在做一个日志查看工具。用户看到“连接成功”，却一直查不到日志，于是发来求助。这是为了讨论而设的例子，不是 PostHog 的真实工单，也不是一次已完成的产品测试。
当值工程师先核对，发现账户连接已经建立，但首批数据还没有到达。解释状态、帮助用户找到阻塞环节，可以解决眼前的困惑。如果下次还有人问，他可能写出一段更完整的说明；再有人问，就把说明放进常见问题。
这些工作都有用，但也可能留下一个没被处理的地方：界面把“已经连接”和“已经可以查询”显示成了同一件事。
此时，支持记录可以直接成为一项产品改动的依据。比如把流程显示成“连接已建立、等待首批数据、已有可查询内容”，在等待阶段提供检查入口。是否真的该这样改，要看真实问题，而不是先认定所有求助都能靠界面解决。
我会为这种反复出现的问题留下一张很短的记录：用户本来想完成什么；当时看到了什么；这次怎样恢复；下次准备改变哪里；由谁在什么情况下检查改动是否有效。这里是我的工作建议，不是原文披露的内部模板。
“检查有效”也不必一上来就追求漂亮的数字。可以先请一位没有听过解释的人，面对没有数据的状态，说明系统已经做了什么、还没做什么，随后尝试找到下一步。若他仍把连接成功理解成数据已可查，改文案就还没有完成任务。若做得到，再在正常支持中观察同类困惑是否继续出现，并保留当时的用户规模和使用场景，避免只拿工单总量下结论。
原文主张，让做产品的人直接接触用户，能更快发现反复发生的问题，并据此简化产品。这是作者对自身做法的解释，不是证明所有公司都应该取消专职支持的对照实验。
对只有一两个人的团队，也未必适合照搬一整周轮值。需要紧急值守的服务，不能因为当值的人下班就没人负责。真正值得借鉴的是把责任、可用时间和求助路径讲清，同时为需要产品改动的问题留下后续安排。
轮值结束时，除了知道这一周回复了谁，还应该能找到那些值得继续处理的问题，以及下一位会接着做的人。
资料：Mo Shehu，2021 年 6 月 15 日，PostHog 官方博客《How we do customer support at our open source devtool company》。2026 年 11 月 6 日阅读全文；历史事实据此整理，日志工具案例与工作建议为独立分析。
