生命周期不是流程图,是五个日期;日期写错,后面每一步都会错位。
一、十四个试用日里的三次提醒
王琳在第 13 天才第一次认真打开产品。前十二天她只登录过一次,点开又关掉。如果提醒只在到期当天发一封,她大概率会点「以后再说」,然后永远忘掉。
以下情境为教学假设,人物、引语和数字不代表经核实的真实案例。
现在有 18 个试用中的订阅,按 40% 的转化率,每月转成付费的是 7.2 个。这个数字决定了提醒值不值得做:18 个里多留下 1 个,按平均每订阅 15 美元算,就是每月 15 美元、每年 180 美元。
| 提醒 | 时点 | 内容 | 渠道 | 不带什么 |
|---|---|---|---|---|
| 第一封 | 第 1 天 | 一条最短的入门路径 | 邮件 | 不附价格表 |
| 第二封 | 第 7 天 | 一个真实用例与结果 | 邮件 + 站内 | 不催付款 |
| 第三封 | 第 13 天 | 到期时间、价格、取消入口 | 邮件 | 不写「最后机会」 |
三次的频率是刻意的。第 1 天讲怎么开始,第 7 天讲最常用的那条路径,第 13 天只讲到期时间与价格;再多就成骚扰,再少就有人真的没看见。
第二封最难写。它不能是「你还没用」的提醒,那种信只会让人内疚;它应该给一个具体结果,比如「同样配置的客户三天内省了几小时」,让客户自己判断值不值。
提醒不是催款,是把「还剩几天」说清楚。 三封邮件里没有一封要求付款,第三封甚至主动给出取消入口;付费是提醒的副作用,不是提醒的目的。
第 13 天必须写取消入口。 藏起来只会换来一次拒付,通道侧的争议处理成本远高于一次正常取消;愿意点取消的人,本来也不会续费。
转化率 40% 是这一组的基线假设,不是行业承诺。它真正的用途是排容量:7.2 个新付费订阅进来,意味着每月要多准备 7.2 份首张发票、7.2 次首扣失败的可能。
提醒发出去了不等于被看见。 三次里有两次被打开就算正常;要判断提醒是否有效,看的不是打开率,而是第 13 天之后有多少人主动进过结算页。
二、五个时点:漏一个就错一次扣款
五个时点不是五个功能,是五个必须落库的日期。少了任何一个,都会在某个月出现「该扣没扣」或「不该扣却扣」。
| 时点 | 谁触发 | 默认动作 | 可配置项 | 漏掉会怎样 |
|---|---|---|---|---|
| trial_end | 试用到期 | 尝试首扣 | 是否自动转付费 | 试用无限延长,永远不收款 |
| renewal | 周期到点 | 生成账单并扣款 | 提前几天开票 | 该扣没扣,事后补扣像乱收费 |
| grace_end | 宽限期结束 | 停服务并置 canceled | 宽限天数 | 失败客户一直免费用 |
| pause_end | 暂停到期 | 恢复并顺延周期 | 暂停上限 | 暂停变成永久免费 |
| period_end | 服务期结束 | 释放权益、结算 | 是否立即降级 | 取消后仍能用,收入漏损 |
五个时点都要存成绝对时间,不能存「还剩几天」。 存相对值,每次改配置都会把所有人的到期日一起挪动;一次「把试用改成 21 天」的运营动作,会顺手把老用户的到期日也推后一周。
trial_end 与 renewal 最容易混。前者是「第一次尝试扣款」,失败了没有历史包袱;后者是「重复扣款」,失败就要进 past_due 与重试队列。两者触发同一段扣款代码,但失败后的分支完全不同。
grace_end 是 past_due 的唯一出口。 宽限期设 7 天,就等于承诺在 7 天内给出结论:要么重试成功回到 active,要么到期转 canceled。没有这个日期,past_due 会一直挂着。
pause_end 的关键是顺延。客户暂停 30 天,恢复后周期整体后移 30 天,而不是从恢复当天重新起算;前者退还了他没用到的服务,后者等于白扣一个月。
period_end 与 renewal 常常只差一天,顺序不能反。正确顺序是先扣款成功、再释放旧周期权益;反过来会出现「权益已停但钱还在扣」的一小段窗口,客户截图发过来时很难解释。
时区按账单锚点日,不用 UTC 零点。 客户在本地 23:00 订阅,若系统按 UTC 切日,这笔会被记到第二天,账单日与发票日从此错开一天,每月对账都要手工搬一次。
五个时点与状态机是同一件事的两面:trial_end 对应 trialing 的出口,grace_end 对应 past_due 的出口,period_end 对应 canceled 的生效点。时点写完,迁移表基本也就写完了。
时点不需要提前通知客户,但需要提前通知系统。 本组在到期前 3 天生成一张待扣清单,只进后台不发邮件;有了这张清单,扣款任务失败时才知道是「漏跑」还是「跑了没扣成」。
三、把续费摊到三十天:2.8 笔与 6 笔
84 笔月付续费摊到 30 天,平均每天 2.8 笔。这个平均值用来估容量:一天的扣款任务、邮件、日志大概什么量级。
但真实分布不是平的。多数月付订阅在同几天开通,续费也就堆在同几天;本组的月初峰值是每天 6 笔,是平均值的两倍多。
平均值管容量,峰值管故障。 按 2.8 配的重试队列,在 6 笔的那天会排队;排到第三小时还没处理,客户就开始写信问「为什么扣了两次」。
2 个暂停订阅要设上限 90 天,恢复率按 50% 估——也就是其中一个会回来。恢复当天要做三件事:解除权益挂起、顺延周期、重算下次扣款日。
暂停不是免费的存档。 一个不设上限的暂停,等于给了一个永久免费档;有效订阅 140 里有 2 个是暂停,比例不大,但规则一旦开口子,数字会自己长。
时区还影响摊平。若一部分客户的锚点日按本地时区算,续费会分散到不同的 UTC 时刻;这反而平滑了峰值,代价是「今天该扣几笔」必须按时区分别统计。
别在续费日改价。 改价与续费撞在同一天,失败时无法判断是卡的问题还是价格的问题;把改价排到周期中间,两类故障才不会互相掩盖。
峰值那天的重试要排队。先跑完当天的首次扣款,再回头处理失败重试;两边混在一个队列里,6 笔的首扣会被重试任务挤到晚上,客户当天的服务就断了。
顺延周期还有一个副作用:恢复后的扣款日会与原来的账单锚点脱开。本组做法是「顺延但保留锚点日」,即暂停 30 天后仍回到每月同一天扣款,只把本次周期延长 30 天。
四、取消的两种生效方式差 15 美元
每月取消 4 个,除以 120 个付费订阅是 3.33%。这个比例看起来温和,但它决定了留存的斜率:一年 48 个取消,相当于把 120 的盘子换掉四成。
取消页给两个选项:立即生效,或到期末生效。选期末生效的 2 个里,平均有 1 个会在期末前反悔撤销。
120 个付费订阅的标价 MRR 是 1,800,平均每订阅 15 美元/月;半个月的价值就是 7.5 美元。期末生效多留下的 2 个,按半月价值算就是 15 美元/月。
复算:
试用 18 × 40% = 7.2 个/月转化
续费摊平 84 ÷ 30 = 2.8 笔/天;峰值 6 笔/天
取消率 4 ÷ 120 = 3.33%
期末生效保留 2 个 × 平均半月价值 7.5 = 15 美元/月
15 美元/月看着小,一年是 180 美元。 它不需要任何新功能,只需要把取消页的默认选项从「立即生效」改成「用到期末」。
反悔不是挽留弹窗。 这里没有折扣、没有弹窗、没有「再想想」;只是把「你已付的钱可以用完」这件事说清楚,让客户自己决定。
反过来,涉及退款或投诉的取消应当立即生效。为了 15 美元把一个愤怒客户留到期末,换来的是拒付与公开差评,成本是它的几十倍。
期末生效在账上要记清楚:这个客户仍然占着一个付费订阅,收入确认到 period_end 才停;如果取消当天就从 MRR 里减掉,当月报表会少算这一份,对账时又要手工加回来。
五、行动清单与复算验收
顺序很重要:先把五个时点落库,再谈提醒与取消页;时点不准,后面所有文案都在解释一个错误的时间。
- 把 trial_end、renewal、grace_end、pause_end、period_end 写成绝对时间字段。
- 给每个时点标注触发者:系统定时任务、支付回调,还是人工操作。
- 试用提醒固定三封,分别在第 1、7、13 天,第三封必须带取消入口。
- 把续费任务按时区与锚点日分组,统计每天实际笔数,找出峰值那天。
- 暂停设 90 天上限,恢复时按暂停时长顺延周期,不重新起算。
- 取消页默认「期末生效」,并写清剩余天数与可继续使用的截止日。
- 用测试时钟跑一遍 14 天试用到期、扣款失败、7 天宽限、转 canceled 的完整链路。
- 记录本月 7.2 个转化、2.8 笔/天与 3.33% 取消率,作为下月对照。
验收标准:五个时点在库里各有 1 个时间字段,且用测试时钟能把一条订阅从 trial_end 一路推到 period_end,中间不出现跳过或重复的扣款。
使用边界与实操验收
边界一:五个时点是单产品单周期的口径。 有年付、按量与多产品线时,时点会成倍增加;先把月付这条链跑对,再复制。
边界二:提醒次数不是越多越好。 三封是按 14 天试用定的;试用 7 天还发三封,等于每两天骚扰一次,退订率会先于转化率上升。
边界三:40% 转化率只用于本组排容量。 换成真实数据后,7.2 会变;所有依赖它的推算都要一起重算,不能只改一个数字。
边界四:暂停上限是业务规则,不是技术限制。 90 天可以改成 30 或 180,但必须同时改提醒、改顺延、改恢复流程,否则三处口径会打架。
边界五:期末生效不是万能的。 客户要退款、要立刻删除数据、要换账号时,立即生效才是正确选择;把「留客」当成唯一目标,会把取消流程做成投诉入口。
关键参考与核验范围
- Stripe 试用 :用于核对试用期长度、到期转付费与提醒时点的通道行为。
- 取消订阅 :用于核对立即取消与期末取消的差异及生效时间。
- 暂停订阅 :用于核对暂停上限、恢复与周期顺延的处理方式。
- 测试时钟 :用于核对如何在不等待真实日期的前提下推进试用与续费。
- RFC 3339 :用于核对带时区偏移的时间戳写法,避免锚点日算错。
以上链接于 2026-10-26 实测可公开访问;未核验版本、价格与配额。核验日期:2026-10-26。
核验的是「时点—触发—默认动作」这套结构能否落地,不是某家通道的字段名与默认值。18、84、4 与 15 均由本组基线推出,与上述文档无对应关系。
自行复核的办法:取本月一条试用订阅,把五个时点的日期手写一遍,再和库里的字段比对;对不上的那一个,就是本月最可能出错的地方。
系列导航
- 回到本组目录:一个人的计费系统:订阅状态机、按比例计费与失败重试
- 上一篇:计费是一条状态机:五个状态、九条迁移与一次多收 420 美元
- 下一篇:升降级与按比例计费:九笔变更、十七天与 4.53 美元
- 相关:一个人的定价与付费墙
继续阅读
探索更多技术文章
浏览归档,发现更多关于系统设计、工具链和工程实践的内容。