最小用户支持系统

用一个稳定入口、清晰优先级和可追踪记录接住真实用户问题。

一个人做产品，支持系统的目标不是"服务到位"，而是用户遇到问题时知道去哪，而你不会漏掉、不会重复劳动、也不会被拖垮。

早期不需要工单平台、不需要在线客服窗口、不需要知识库系统。

需要的是三件事：能联系上你、能得到回应、问题被记下来。

支持不只是成本

用户遇到问题找不到人，就直接走了，而且不会告诉你原因。

反过来，支持消息是你最便宜的用户研究渠道。真实卡点、真实场景、真实的替代方案，都藏在这些消息里。早期不要把它只当负担，它比问卷有用得多。

可以是业务邮箱、站内表单或固定客服账号。选一到两个你最方便长期看的，不要同时开五个渠道。

推荐组合：一个异步入口做主渠道，紧急问题再走即时通讯。

首页、支付结果页、错误页和付费内容都指向同一个入口。设置自动回复，说明已收到、通常多久回、需要补哪些信息。

不要承诺你做不到的响应速度。 "工作日 24 小时内回复"比"随时在线"更可信，也更可持续。

产品日志应该能通过订单号、任务号或请求编号定位，而不是让用户描述全部技术细节。这件事在写代码时就要留出来，见埋点与数据看板。

最容易被排错优先级的是**"只有一个人提但涉及钱"**的问题。

它看起来是个例，但支付和数据类问题一旦出错，用户不会再给第二次机会。涉及钱和数据的问题，一律按紧急处理。

一个表格或一个文档就够，不要建系统：

日期 | 用户/订单号 | 问题 | 是否产品问题 | 处理结果

"是否产品问题"这一栏最有价值。它把支持记录变成了改进清单。

同一问题出现三次，优先修界面、错误提示或流程。

只写一篇 FAQ，可能是在让用户适应产品缺陷。 帮助文档该写，但它是兜底，不是修复。

修复后主动回复最早报告问题的人，说明发生了什么、如何确认恢复。这一步的回报被严重低估——主动回访会把一个抱怨过的用户变成愿意推荐你的人。

四种办法，按效果排序：

第四条要注意：AI 起草可以，直接自动回复不行。 一条答错的自动回复会让用户觉得没人看他的问题。

边界要在回复里说清楚，不要含糊过去。"这个我们暂时不做"比"我们看看"更让人尊重你。

想承接超出范围的需求，可以走外包与外部协作或单独报价，不要塞进支持里免费做。