账号是一套流程，不是一张表：五段漏斗、七个节点与每月 26.9 小时工单

账号是产品里唯一「每个人都必须经过、但从来没人负责」的一段路。

一、一次复盘与一张没人算过的表

2026 年 9 月，林澈做月度复盘时发现一个怪现象：注册页一个月有 4,200 次访问，付费用户只新增 96 个，但他说不清中间到底漏在哪。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

他能拿到的只有两份数据：一份是分析工具里的注册漏斗，一份是客服系统里的工单分类。把两份放在一起看，问题才显形：从访问到付费，中间有五个可以单独计量的段落；从登录到注销，中间有七个会持续产生成本的节点。

账号不是一张用户表，是一套流程。 表只回答「谁在这里」，流程回答「他怎么进来、怎么回来、怎么走」。前者是数据库设计，后者才是产品设计。

这条区分很重要。用户表写错了可以迁移，流程设计错了会持续漏人、持续产生工单，而且每次漏人都不会报警。

他后来把这张表贴在显示器旁边。不是为了记住数字，是为了在每次想改登录页时先看一眼：这次改动影响的是哪一段，哪一段的下游会跟着变。

表本身不解决问题，但它把「感觉注册流程有点长」变成「第二段漏 60 人、第四段漏 69 人」。前者没法排期，后者可以。

二、五段漏斗：从访问到回来

把一个月的数据按「谁在什么时候离开」拆开，得到五段。每一段都有自己的分母，混着看就会得出错误结论。

第一段的 29.5% 最大，但它不是账号问题：4,200 次访问里大部分只是来看定价页的。真正属于账号设计的是后四段——从表单到付费，一共漏掉 60 + 49 + 69 + 320 = 498 人，占表单开始人数的 40.2%。

分母不同，结论就不同。 96 除以 1,062 是 9.0%，代表「进来的人里有多少付费」；96 除以 742 是 12.9%，代表「激活的人里有多少付费」。汇报时用哪个分母，决定了你以为该修获客还是该修产品。

第二段到第四段加起来只漏 178 人，看起来不多；但它们对应的是账号设计里最密集的工单来源。漏人只是表象，留下来的人要花多少支持时间才是持续成本。

支持时间的账要在另一张表里算。它不随访问量变化，随「流程里有多少个需要人判断的岔路」变化：一个岔路一个月被走 100 次，每次 5 分钟，就是 8.3 小时。

这也是为什么账号类改动很难评估：你改的是第二段，收益却出现在第四段；如果不分段记账，你会以为改动没用。

三、七个节点各漏多少人

七个节点是：注册表单、邮箱验证、首次登录、激活、找回密码、会话过期、注销与合并。前四个漏人，后三个漏时间。

这张表的读法是「先看损耗是不是设计造成的」。表单放弃 4.8% 可以是设计问题，激活流失 30.1% 通常是产品问题——把它记在账号头上会让优先级排错。

七个节点里，只有前四个属于账号设计。后三个是「已经进来的用户」在使用过程中撞上的墙，它们不改漏斗，只改支持成本。

后三个节点的共同点是「本来可以自助」：找回有标准流程，会话过期可以提前提示，注销可以做成自助表单。它们之所以变成工单，往往不是因为难，而是因为没人把流程写下来。

这也解释了为什么账号功能的开发排期总是排在最后：它不产生新功能，只减少摩擦，而摩擦的成本分散在每天的工单里，很难被看见。

一个节点只能改一件事。 表单只改字段，验证只改邮件与时效，首登只改引导，激活交给留存那一组。混着改，你永远不知道是哪一个动作起了作用。

节点之间还有依赖：验证邮件如果延迟 12 分钟，首登率一定下降；首登引导如果要求重新输入邮箱，找回工单一定上升。改一个节点前，先看它下游的那个数字。

四、214 张工单与 26.9 小时

账号类工单一个月 214 张，占全部 612 张的 35.0%。按类型拆开，一半以上集中在找回密码。

合并只占 3.7% 的数量，却吃掉 336 分钟，是全部工单里最贵的单项。这也是账号支持最反直觉的地方：数量最多的不是最贵的，最贵的是那些一年只发生几十次、每次都要人工判断的事。

26.9 小时/月意味着每年 323 小时。按每月 21 个工作日折算，相当于每月 1.3 个工作日全部花在账号上，而这些工作没有任何一项会写进产品路线图。

先修数量最多的，再修单价最贵的。 找回与验证合计 149 张、占 69.6%，把它们做成自助，比优化合并流程的收益大得多；合并的 42 分钟虽然贵，但一个月只有 8 次。

工单分类要能落到节点上。如果一张工单既像找回又像验证，说明分类标准没写清楚；标准不清，趋势就不可比。

平均 7.5 分钟是回复时间，不含等待。用户发出工单到收到回复之间的时间没有算进成本，但它对留存的影响比回复本身更大。

还有一类工单不会出现在分类里：用户放弃后直接离开。他们不发消息，也不填表；沉默的流失只能从漏斗里看出来，不能从工单里看出来。

复算：
访问 4,200 → 表单 1,240：1,240 ÷ 4,200 = 29.5%，流失 2,960
表单 1,240 → 提交 1,180：1,180 ÷ 1,240 = 95.2%，流失 60
提交 1,180 → 验证 1,131：1,131 ÷ 1,180 = 95.8%，流失 49
验证 1,131 → 首登 1,062：1,062 ÷ 1,131 = 93.9%，流失 69
首登 1,062 → 激活 742：742 ÷ 1,062 = 69.9%，流失 320
激活 742 → 付费 96：96 ÷ 742 = 12.9%，流失 646
账号段合计流失：60 + 49 + 69 + 320 = 498；498 ÷ 1,240 = 40.2%
工单分钟：108×6 + 41×5 + 27×8 + 8×42 + 12×10 + 18×5
        = 648 + 205 + 216 + 336 + 120 + 90 = 1,615
1,615 ÷ 60 = 26.9 小时/月；26.9 × 12 = 323 小时/年
工单占比：214 ÷ 612 = 35.0%

五、行动清单与复算验收

• 把注册到付费拆成五段，每段写下起点、终点与分母。
• 给七个节点各写一行「每月发生多少、损耗多少」。
• 统计账号类工单占全部工单的比例，超过 25% 就单独立项。
• 按类型拆工单，算出数量占比与时间占比，找出最贵的单项。
• 确认激活流失没有被记在账号头上。
• 找出验证、首登、找回三个节点之间的依赖关系。
• 给每个节点定一个可单独验证的改动。
• 用一个月的数据复算一次，确认漏斗各段相加等于起点。

验收标准：任取一个节点，都能说出它每月漏多少人、花多少分钟、下游是哪一个节点。

前四条是「把账建起来」，后四条是「把账变成优先级」。如果只有一小时，先做第四条：时间占比和数量占比不一样的地方，通常就是最该改的地方。

使用边界与实操验收

4,200 次访问是样本，不是基准。 不同产品的漏斗形状差别很大，重要的是五段各自的分母，不是某一格的百分比。

账号工单占比会随产品阶段变化。 早期可能只有 10%，有企业客户后会升到 40% 以上；比例本身不重要，趋势才重要。

26.9 小时是人工时间，不含开发。 它只统计回复工单的时间；把账号功能本身的开发与维护算进来，成本还要再加一档。

漏斗不能跨月混算。 这个月注册的人可能下个月才付费；跨月看时要用同队列，口径与留存那一组一致。

先修流程，再修界面。 把找回做成自助，比把登录页做得更漂亮更能减少工单。

五个分母要分开记。 访问、表单开始、提交、验证、首登各是一个分母；混用会让同一份数据支持两个相反的结论。

工单成本不含机会成本。 处理工单的那 26.9 小时本可以用来做功能；把它折成钱时，要用你自己的时薪，而不是客服的时薪。

关键参考与核验范围

• web.dev：登录表单最佳实践 ：用于核对注册与登录表单的字段、错误提示与自动填充要求。
• OWASP 认证速查表 ：用于核对账号流程中不可省略的安全约束。
• NIST SP 800-63B ：用于核对认证与账号恢复的分级思路。

以上链接于 2026-10-27 实测可公开访问；未核验版本、功能范围与政策更新。核验日期：2026-10-27。

范围上只讨论一个人维护的产品如何把账号流程算成一本账，不讨论认证协议实现、密码学与法律合规判定。

系列导航

• 下一篇：注册表单：六个字段砍到三个，与 2.8 个百分点的提交率
• 回到目录：一个人的账号体系：一百零八张找回工单、三十天冷静期与 4.2% 的验证流失
• 相关阅读：一个人把用户留住：激活、留存与复购