何时开始扩张：验证产品与经营的稳定性

假设你准备把ClearCopy每周招募人数从20人增加到100人。先别开更多渠道，本篇把这个决定算到纸上：同样的服务流程能否承受五倍尝试，以及本周到底扩不扩。 你将完成一份可以直接修改的扩张申请，不需要先买更大的机器。

全部数字是教学情形。你实际使用时替换成最近完整观察周期的数据，不把下表当成作者已经获得的客户数量。

先读这份已经作出决定的申请

拟改变：每周招募20位合适试用者，增加到100位
保持不变：英文App描述检查、9美元10次包、现有目标用户
本周决定：暂不扩大到100，先做两项修复
原因1：人工支持约8.33小时/周，超过可投入的4小时
原因2：200次有效任务中199次按时完成，刚好用完教学错误预算
修复：给事实输入加完成例；将处理中任务做成可恢复页面
重新检查：修复后的完整观察周期，支持耗时与报告完成重新统计

申请有了具体数字，扩张就不再只是“感觉用户多了，可以试试”。接下来把两项理由算出来。

把增长换算成你的一周

设现有流程平均每位新试用者需要你答疑5分钟，这个耗时包含解释两个输入框和处理任务等待问题。先按新用户数线性估算：

每周新试用者	每人人工答疑	一周总答疑	你可投入的支持时间
20人	5分钟	100分钟，约1.67小时	4小时
100人	5分钟	500分钟，约8.33小时	4小时
100人，输入与等待流程改善后假设	2分钟	200分钟，约3.33小时	4小时

第三行是一个要验证的改进目标，不是只加FAQ就保证降到2分钟。你可以先把本周反复回答的两道问题写进页面，用后续真实时间记录看平均耗时是否下降。

如果5分钟是凭感觉估计，先对接下来几次支持分别记录开始、结束和问题类型。只记录耗时与类型即可，不必把私人聊天全文放入产品统计。没有这份观察时，扩张申请就写“支持容量未知，先测”，比填一个好看的平均值更有用。

用报告任务定义服务是否跟得上

Google SRE的服务目标章节建议从用户能感受到的可靠程度建立目标。对ClearCopy，可以先用“有效提交的报告任务在60秒内保存成功”作为一项教学目标；60秒与99.5%都是本例选择，不是平台承诺或行业强制标准。

本例完整观察200次有效任务，其中199次在60秒内成功，1次超时。完成比例是199 ÷ 200 = 99.5%。若目标也是99.5%，这一窗口最多允许200 × 0.5% = 1次未达标，已经用完这一份教学错误预算。

再增加一倍或五倍流量不会自动修好那个超时路径。先定位那一笔的请求ID、排队时间和外部模型耗时，确认用户没有被重复扣次、刷新后能找到原任务，再考虑扩大招募。

有效任务的范围也写清：基础输入格式已通过、用户有足够额度、服务端接受处理。恶意请求与空白表单另计；不能为了达标临时把所有失败都从分母删除。60秒后成功仍算未达本项及时性目标，但可另计最终成功率。

用已有用户的返回验证任务会不会再发生

打开PostHog留存说明，为已经观察满周期的用户检查“首次完成报告→后续完成报告”。配图展示按浏览器拆分的方法，用它发现某类使用者体验是否明显较差；不要把不同浏览器的样本人数变化误认成需求变化。

沿用一组教学成熟用户：20人首次完成，6人下一完整周再生成，返回30%。进一步询问任务情境：其中有人在改第二个App，有人在改同一个App的更新描述。若多数客户只在一年一次发布时使用，扩张时应找更多同类任务用户，而不是把低频需求硬改成每天打卡。

同时查看Stripe订阅分析时，将真正的月订阅与9美元一次性包分开。收款多了一次不等于重复收入稳定，尚未结束的周期也不能提前计作续费。

做一个能承受的中间版本

不扩大到100，不等于停止产品。把申请改成一次较小的下一步：

本次工作	明确完成形态
输入困惑	事实栏有行李清单完成例，试读者不用作者解释就能填写
等待问题	用户关闭再打开仍找到原任务，成功后只扣一次
支持耗时	新一批20人按同样方法记录实际答疑分钟
招募规模	暂保留20人；观察后决定是否先到40人

如果修复后每人仍需5分钟，40人约需3.33小时，至少比直接100人更接近4小时容量。这个计算只是规划工具，仍需留出处理异常的时间；不是把全部可用时间都预先排满。

最后保存开头那份申请，并把假设数字替换为你下一次实际观察。你得到的是一个有工作量、有产品动作、有重新检查时机的决定：先让现有用户顺利拿到报告，再让更多人走相同流程。