这是
content/posts/indie/indie-self-serve-support的目录页，收录 10 篇文章。前面十七组分别讲「要不要做」「在哪上架」「丢了怎么找回」「怎么合法立住」「多条线怎么加减」「怎么用接单换现金」「前 100 天怎么走」「怎么让人知道你」「人来了怎么留住」「收多少钱」「用户不在你的语言里怎么办」「怎么判断做的东西是对的」「怎么让产品看起来像样」「怎么把软件送到用户手里」「怎么把能力做成 API」「怎么给产品加 AI」「做不完时怎么借力」。这一组处理最后一件事：当同一个问题被问第一百遍时，怎么把答案变成可搜索、可执行、可维护的资产。
这个系列解决什么问题
一个人做产品，支持成本是最容易被低估的一项。它不占整块时间，而是散在每一天：回一封邮件、改一条模板、补一张截图，一天就过去了。等到想收拾的时候，帮助中心里已经堆了三十篇没人看的文章。
常见的四种情形：
- 工单稳定在每月两百张，帮助中心有几十篇文章，量却降不下来。
- 文章写了，用户搜不到，因为标题用的是功能名，用户搜的是现象。
- 每个问题都要本人回答，模板、排查树、升级路径都没有。
- 内容做了一批，半年后界面改版，截图与步骤全部过期。
这一组不讨论支持理念，也不重复客服分级与 SLA 承诺，只做一件事：把「自助支持」拆成一个人能算账、能写、能维护、能验收的动作。
核心主张：五条口径
第一，先算账再写内容。 可自助比例、四笔成本与回本周期算不过，就不做；继续人工更划算也是一种正确结论。
第二，按任务组织，不按功能组织。 用户找的是「怎么完成一件事」，不是「某个按钮在哪个模块」。
第三，每个答案必须有出口。 自助失败之后去哪里，比答案本身更重要；没有出口的自助等于死路。
第四，自助不是放任。 退款、账号安全、数据恢复与个案争议不设纯自助，必须留一条回人工的路。
第五，所有数字都是教学假设。 换成自己的工单表、单张处理时间与真实时薪重算，才有意义。
10 篇速览
| 文章 | 核心内容 | 阶段 |
|---|---|---|
| 自助支持是一本账：工单分类、可自助比例与四笔成本 | 五类工单、四条判据、四笔成本、回本周期与误自助四型 | 算账 |
| 帮助中心的结构：按任务组织，不按功能组织 | 四层 IA、一页一任务、五个入口、提交前分流、覆盖率 | 结构 |
| FAQ 的写法：从工单原话到可执行答案 | 原话提取、三段式、标题即搜索句、四条可执行检查 | 写作 |
| 故障排查树：症状、检查与出口 | 按症状建树、三型节点、错误码与日志、四条出口、死路率 | 排查 |
| 教程与截图：让用户在 60 秒内完成一件事 | 五块模板、截图规范与打码、录屏边界、版本同步 | 教程 |
| 站内搜索与空结果：让答案真的被找到 | 三类失败、别名表、错误码索引、排序、空结果闭环 | 搜索 |
| 更新日志与破坏性变更：让老用户知道发生了什么 | 四类变更、三档受众、迁移指南、告知成本与内容同步 | 变更 |
| 模板答复与社区答案：把重复回复变成可复用资产 | 八类模板、四段式、变量与禁用承诺、社区转正、复审 | 复用 |
| 人工升级路径：自助失败之后怎么交给人 | 三级路径、五类触发、六个交接字段、升级率与误升级 | 交接 |
| 自助支持验收：拦截率、首次解决率、成本与风险四张表 | 四张表、评分锚点、综合分、scale/fix/stop、季度审计 | 验收 |
三条阅读路径
路径 A：工单多，还没建帮助中心
01 算账 → 02 搭结构 → 03 写 FAQ → 10 验收。先做最便宜的一层，20 条 FAQ，跑四周再决定要不要建树或录教程。
路径 B：已有帮助中心，但用户搜不到或不看
06 查搜索与空结果 → 02 改 IA → 03 改答案 → 05 补教程 → 10 验收。顺序反了，先建树只会加深「找不到」的问题。
路径 C：刚发过一次破坏性变更，或正准备发
07 管变更告知与内容同步 → 08 建模板库 → 09 补升级路径 → 10 复盘。读 08/09 时并行看借力组，但不要在本组重复外包权限与抽检。
与其它专题的边界
| 专题 | 它讲什么 | 本组的边界 |
|---|---|---|
| 客服不是成本：工单是免费的需求样本 | 工单分级、文档→提示→产品三级消化、FAQ 回本 | 最接近的一篇；它决定「先改文档还是先改产品」，本组假设已决定做自助，讲内容系统本身与验收 |
| SaaS 自助和人工边界：哪些事让客户自己做，哪些事你必须介入 | 自助与人工的边界模型、成熟度阶段与迁移路线 | 最接近的边界文章；它给「什么时候该自助」，本组给「决定做之后十篇怎么落地」 |
| SaaS 帮助文档：早期文档不是附属品，而是可复制交付 | 三类文档、按任务写、成功标志、文档入口 | 它讲原则与早期交付；本组把原则落成四层 IA、页面模板、入口与覆盖率算法 |
| SaaS 支持问题分类：别把所有客户消息都当成同一种客服 | 六大类、记录字段、每周复盘、团队分工 | 它做客服分类学；本组只分「可自助/不可自助」两池，并算拦截与成本 |
| SaaS 客服和反馈闭环：把问题变成产品改进 | 分类、重复问题产品化、反馈闭环表 | 它讲支持到产品的回流；本组只处理「重复问题怎么变成自助内容」 |
| 自动化、虚拟助理与一线客服：把按规则执行的事交出去 | 一线外包的人员、权限、话术与抽检 | 它讲把支持交给别人；本组讲不用人值守的内容、模板资产与交接包 |
| 开发者支持：工单分级、状态页与事故沟通 | 开发者五类工单、P0–P3、状态页、事故公告 | 它面向 API 开发者与事故；本组面向终端用户的任务答案与三级升级 |
| 文档站：五分钟跑通第一个请求与错误自查 | API quickstart、端点页六块、错误码索引 | 它讲接口参考文档；本组讲任务型帮助中心、排查树与教程 |
| 版本与弃用：兼容窗口、弃用公告与迁移指南 | 兼容窗口、弃用公告、Sunset 头、双版本并行 | 它管对外接口弃用；本组只算产品内变更带来的工单与内容同步 |
| 微文案：按钮、报错与空状态怎么说 | 应用内按钮、报错与空状态文案 | 它讲界面内一句话；本组讲应用外的答案页、教程与排查路径 |
| SaaS 支持知识库：从 0 开始把客户问题沉淀成产品改进和销售素材 | 单篇知识库、记录模板与轻量指标 | 它是一篇经验；本组是十篇系统，覆盖 IA、搜索、排查、模板与升级 |
| SaaS 创始人客服手册：把每次支持都变成产品和销售线索 | 创始人分诊、上下文、产品闭环与交接 | 它讲人怎么回；本组讲怎么让重复问题不再需要人回 |
| SaaS 轻量 SLA：早期支持承诺要清楚，但别承诺做不到的赔付 | SLA 分级、响应时限、赔付边界、自助工具清单 | 它给承诺与工具清单；本组深入每类内容的写法、维护与验收 |
| SaaS 发布说明：小团队也要告诉客户产品变化了什么 | 四类变更、受众分层、渠道、模板、SemVer | 它教怎么写发布说明；本组只算「变更→工单」的账与内容同步 |
| SaaS 客户培训：第一次培训不要变成功能朗读 | 一对一培训、角色拆分、任务组织与验收 | 它讲有人带的培训；本组讲无人值守的教程、截图与录屏 |
| SaaS 事故沟通：小团队也要提前准备停机、错误和数据问题 | 事故分级、三类通知模板、事后复盘 | 它讲事故当下怎么说；本组只处理日常问题的自助与升级 |
| 游戏客服运营体系：从工单到补偿，怎么把玩家问题处理清楚 | 游戏工单、补偿、封禁申诉、玩家沟通 | 它含补偿与虚拟物品；本组面向软件与工具产品，不含补偿体系 |
| 游戏平台客服协同：商店差评、退款工单和封禁申诉怎么联动 | 商店差评、退款与封禁申诉的平台协同 | 它讲平台侧申诉；本组讲自有产品内部的自助与升级 |
| Steam 首发客服与崩溃反馈入口：个人开发者如何把问题收集完整 | 游戏首发反馈入口与崩溃信息收集 | 它讲首发收集；本组讲把信息结构写进排查树与工单表单 |
| 开源文档体系 | 文档四象限、教程与参考、docs-as-code | 它面向开源贡献者；本组面向付费用户的支持与工单拦截 |
| API文档自动化：OpenAPI规范与Swagger实战指南 | 从 OpenAPI 生成参考文档 | 它生成接口文档；本组手写任务答案与排查路径 |
| Markdown 与文档工程：写作规范、静态生成与 LaTeX 排版 | 文档写作规范、静态生成与排版 | 它讲文档工程；本组讲内容选题、结构与支持效果验收 |
| 第 61–70 天：上线前的十五件事 | 上线清单把额外帮助文章列为可后置体验 | 它只给「先上线再补」的排序；本组讲上线后怎么把内容做成系统 |
| 第 81–90 天：反馈分诊与第一次收费 | 反馈分诊、人工开通与自助开通的取舍 | 它讲怎么分诊与何时转自助；本组讲分诊后怎么把重复问题做成内容 |
| 事故响应：被盗、被封、被停机、域名劫持的 72 小时 | 账号、停机与域名事故的应急 | 它讲事故处置；本组只处理日常使用问题的自助与升级 |
| 崩溃上报与版本遥测：发布后 72 小时的止损阈值 | 崩溃遥测与发布后止损 | 它讲遥测；本组讲如何把崩溃码与日志位置写进排查树 |
| 合同与条款：服务条款、隐私政策、DPA、退款政策与试点协议 | 退款政策等对客户条款 | 它给条款文本；本组给退款类工单的答案结构与升级条件，不构成法律意见 |
| 定价复盘：价格、转化、留存与退款的一张表 | 退款率与定价复盘 | 它看退款率；本组看退款工单的自助路径与人工兜底 |
| 一个人把产品做出海：多语言、时区与本地化 | 产品文案、排版与本地化 | 本组：自助内容、排查树与人工升级；该专题：多语言文案、时间模型与本地化运营。 |
| 一个人把用户留住：激活、留存与复购 | 激活、留存、召回与续费 | 它讲留存指标；本组讲支持体验对留存的影响，不重复留存口径 |
| 一个人的借力：外包、自动化与协作边界 | 借力总账与一线客服外包 | 本组：自助内容、排查树与人工升级；该专题：发包、协作交接与净回收工时。 |
| 一个人的社区：冷启动、版规、版主与社群健康 | 社群该不该建、载体选型、前 100 人、版规与三档处置、版主与志愿者、内容节奏、答疑沉淀、活动与线下、商业化边界、四张验收表 | 那组讲社群里的答疑怎么分流与沉淀；本组讲帮助中心、排查树与人工升级路径 |
| 一个人的财务：现金流、runway 与月度结账 | 四张表与四个收入、分账、收入确认、成本清点、13 周滚动、runway 与薪酬、15 分钟月结、税预提、现金预警与收缩、四维验收 | 那组讲现金与成本；本组讲帮助中心、排查树与工单减少 |
| 一个人的运维：可用性、告警、事故与值班 | 可用性预算、五条探针、告警降噪、日志串联、状态页、容量水位、依赖降级、发布观察、事故复盘、四维验收 | 那组讲故障发现与对外沟通；本组讲帮助中心、排查树与工单减少 |
| 一个人的多租户：组织、邀请、角色与数据隔离 | 组织引入判据、三层模型与迁移、邀请与成员生命周期、角色矩阵、三层校验、数据隔离、审计日志、席位一致、交接与四维验收 | 那组讲成员与权限；本组讲帮助中心、排查树与工单减少 |
| 一个人的产品度量：事件字典、指标口径与决策看板 | 六个决策与十二个指标、二十四事件字典、埋点三处校验、口径五要素、五步漏斗、一屏四区看板、四条校验与三方对账、采样与保留、样本量与灰度、九项验收 | 那组讲行为数据怎么用；本组讲帮助中心、排查树与工单减少 |
| 一个人的架构：技术选型、模块边界与演进（10 篇） | 技术选型排除法、九个模块与依赖方向、数据迁移三步、四个升级窗口、技术债预算、三次规则、重构判据、可替换性、幂等与补偿、四维验收 | 那组讲代码结构；本组讲帮助中心、排查树与工单减少 |
| 一个人的计费系统：订阅状态机、按比例计费与失败重试（10 篇） | 订阅状态机、五个时点、按比例计费、按量计量、催收、退款拒付、发票税务、对账漏损、自建决策、十二项验收 | 那组讲账单与退款；本组讲帮助中心、排查树与工单减少 |
| 一个人的隐私工程：数据地图、最小化与删除权（10 篇） | 数据地图、最小化、合法性依据与同意、政策一致性、数据主体请求、删除、保留期、跨境与供应商、泄露响应、十二项验收 | 那组讲工单里贴进来的用户数据；本组讲帮助中心、排查树与工单减少 |
| 一个人的数据搬家：导入、去重、迁移与退出（10 篇） | 迁移漏斗、导入契约、字段映射、去重合并、幂等重跑、人工代导入、窗口与回滚、附件限额、导出退出、十项验收 | 那组讲导入失败的自助排查；本组讲帮助中心、排查树与工单减少 |
| 一个人的质量守门：验证预算、回归清单与发布门禁（10 篇） | 47 缺陷与三条红线、12 条关键路径、三层配比、38→26 回归、六项门禁、四级缺陷、测试数据、不可逆保护、测试债、十项验收 | 那组讲发布前验证与回归；本组讲帮助中心、排查树与工单减少 |
| 一个人的安全基线：十四个入口、十七个密钥与一次 72 小时响应 | 14 个攻击面、认证与枚举、会话撤销、17 个密钥三档、四条边界、41 个依赖与 186 条告警、四类限流、9 类审计日志、72 小时三段响应、20 项验收 | 那组讲入口与防滥用；本组讲帮助中心、排查树与工单减少 |
| 一个人的性能与账单：4.2 秒的首屏、一千二百次查询与每月 210 美元 | 4 项预算与 20 格、RUM 与慢查询、412→168 KB、1,200→3 次查询、0→86% 缓存、34 秒导出、7→4 个第三方、210→118 美元、3 次回归告警、10 项验收 | 那组讲性能问题怎么在用户报障前发现；本组讲帮助中心、排查树与工单减少 |
| 一个人的企业客户：九家询价、一百四十八道问卷与 134 天的第一单 | 9 家询价与 130 h、96 天采购、148 题问卷、7 个子处理者、SLA 43.2/216 分钟、26 h SSO、4 周试点、38 天到账、8 h 实施、10 项验收 | 那组讲企业支持档位；本组讲帮助中心、排查树与工单减少 |
| 一个人的开源产品：4,200 个 star、一百八十个付费与一年 612 小时的维护 | 4,200 star 与 1,949 美元、612 h 维护、214 依赖、48,600 行 78/22、1,180 个 issue、214 条告警、23 个赞助者、9 家双许可、17 位贡献者、10 项验收 | 那组讲 issue 分类与首响；本组讲帮助中心、排查树与工单减少 |
另有一篇商业计划书语境的《Birdor 商业计划书第四十一章：用户支持体系》给出四层支持体系与指标表；本组是独立开发者可执行版，不重复其体系总览。
本组统一口径
全组共用一组教学基线：月工单 200 张、单张 12 分钟、时薪 60 美元。自助上线后的稳态漏斗如下，各篇引用时不换分母：
总工单 200
自助解决 80（40%）
进入人工 120（60%）
直接要求人工 30（占总单 15%）
一线处理 90 → 解决 81（90%），升级 9
到本人 39（占总单 19.5%）→ 解决 35，未解决 4（2%）
总解决 196（98%）
人工成本 120 × 12 分钟 = 24 小时 = 1440 美元
内容维护 360 + 工具 20 + 误自助 180 = 560 美元
总成本 2000 美元 ÷ 200 = 10 美元/单
事件口径：ticket_created / selfserve_session / selfserve_resolved
escalated / search / search_zero_result / article_click
成本口径：单位人工成本 1440 ÷ 120 = 12 美元/人工单；单位总成本 2000 ÷ 200 = 10 美元/单。拦截口径：80 ÷ 200 = 40%，不要和 80 ÷ 120 混用。
使用说明
每篇都可以单独读，但建议按「先算账、再建结构、最后验收」的顺序。每篇末尾有行动清单与验收标准，验收标准写成一句可判断真假的话——做不到就是没做完。
文中出现的人物、产品与数字均为教学假设，用于演示算法，不代表经核实的真实案例。涉及退款、隐私、消费者权益与劳动关系的部分只说明取向，不构成法律意见，具体口径请以条款与所在地法规为准。
本组的证据与使用方法
这十篇不引用任何客服系统、搜索服务或文档平台的实时价格，也不承诺自助一定降低工单。可复算的部分全部用四则运算给出算式（可自助比例、四笔成本、回本周期、覆盖率、死路率、空结果率、告知覆盖、模板复用率、升级率与综合分），读者可以替换成自己的工单表与工时重跑；不可复算的部分（例如具体工具的报价、法规要求、用户真实行为）明确标注为需要自行核验。
建议的使用方式：先用 01 决定做不做、做到哪一层，02 搭最小结构；03–05 生产 FAQ、排查树与教程；06 让内容被搜到；07 管变更带来的工单；08–09 把重复回复与交接做成资产；10 用四张表做季度验收。自助支持不是一次性项目，是一条随产品、界面与用户结构持续复核的线。