LTD 销售的是一项长期合同

Lifetime Deal 常用于早期冷启动：产品一次获得现金、首批付费用户、集中反馈、评论和分发。它同时把未来多年服务承诺压缩进今天的一笔价格。^[1][2]

持续服务型产品的 LTD 风险主要来自：

• 模型、服务器、存储和第三方 API 持续产生费用；
• 支持和更新没有对应续费收入；
• 用户可能共享账号或包装成转售服务；
• 早期低价可能蚕食本来愿意订阅的客户；
• 收购、改名、拆分版本后，原权益仍需要处理；
• 高成本新能力是否包含，容易产生争议；
• 产品存续时间越长，履约责任越大。

「用户通常只用一两年」「技术成本以后会下降」「未来可以被收购」都不能用来替代最坏情景核算。用户可能长期活跃，成本也可能上涨；对收购方而言，没有持续收入却需要继续服务的一批账号，会影响交易价值。^[1]

LTD 更适合边际成本低、交付范围稳定的产品。持续成本较高的服务也可以设计 LTD，但需要把高成本部分限制在可履行的档位、月度额度或使用范围内。

先把 Lifetime 的含义写成权益表

「Lifetime」至少可能指：

• 产品仍在运营期间；
• 当前产品与当前档位；
• 当前主版本；
• 已列明的功能集合；
• 固定额度长期重置；
• 一次购买者账号的使用期限。

这些含义不能留给售后解释。权益表应列出：

• 包含的档位和功能；
• 每月、每年或永久总额度；
• Credits 是否重置、结转或过期；
• AI Minutes、存储、带宽和导出限制；
• 设备、席位、工作区和项目数量；
• API、自动化和商业使用权限；
• 新功能、小版本与大版本是否包含；
• 升级、叠加 Code 和降级规则；
• 支持方式和响应边界；
• 退款后怎样撤销访问；
• 产品合并、改名、收购或停止服务时怎样处理。

一项 AI 视频工具可以长期开放低边际成本的编辑和导出，同时为模型处理分钟设置每月重置额度。这种结构比「所有功能无限使用」更容易估算，也让购买者在交易前知道限制。^[2]

额度边界只能在销售前确定。已经承诺的功能不能因为成本上升而事后撤回，再要求原客户转成订阅。公开案例中，取消原有 Lifetime 权益曾引发大规模用户反弹，问题的根源正是承诺与后续解释冲突。^[2]

为 LTD 建立最坏履约模型

LTD 价格不能只用月费或年费乘一个固定倍数。可以建立三个情景：预期、压力和最坏。

每个情景至少输入：

• 售出账号数；
• 实收单价；
• 平台、支付和税费；
• 退款与拒付；
• 活跃用户比例；
• 每用户每月模型、服务器和存储成本；
• 每用户每年支持工时；
• 使用年限；
• 账号共享与异常使用；
• 未来兼容、迁移和安全维护；
• 为订阅收入造成的蚕食。

可以用一条粗略公式检查：

LTD 可用贡献 = 实收 - 渠道与支付 - 退款 - 预计履约成本 - 支持成本 - 风险准备

预计情景为正还不够。压力情景若很快转负，需要降低高成本额度、缩短包含的更新范围、提高价格、限制数量，或放弃 LTD。

内部还可以为每个 LTD 账号建立履约准备余额。每月根据实际活跃、成本和剩余承诺更新，而不是把首月现金全部看成可分配利润。

上 LTD 平台是在交换分发和定价权

LTD 平台可以带来集中购买人群、商品页、邮件、内容、评论和信任机制，也会带来分成、退款、支持和权益约束。^[1][2]

历史案例中的平台流量、分成比例、最低价和退款天数都是当时快照，不能继续沿用。当前合作要以签约合同和具体 Deal Terms 为准。

AppSumo 的官方帮助文档截至 2026 年 8 月说明：Lifetime Deal 的访问通常持续到产品停止运营；合作方在产品仍有偿付和运营能力时需要按 Deal Terms 继续提供访问，收购后的新所有者也要处理原 Lifetime 权益。若产品无法继续服务，平台条款还可能涉及追回合作方已获得的款项。^[3]

官方退款与合作方文档同时说明：具体退款窗口以商品页条款为准，退款会从销售额中扣除，合作方需要根据退款代码撤销访问；当前合作方结算还可能因为退款期采用延后付款安排。^[3]

这些规则说明，平台 GMV 和页面销量不等于可用现金。团队需要单独记录：

• 购买、兑换、退款和有效账号；
• 平台分成与结算时间；
• 退款期内不能确定使用的现金；
• 商品页承诺与版本快照；
• 平台用户的激活、使用和支持；
• 官网自然客户是否被 LTD 蚕食；
• 活动结束后新增订阅、升级和口碑。

深折扣方案长期留在官网主定价路径，可能让本来愿意月付或年付的用户改买 LTD。更清楚的做法是把它限定在具体阶段、渠道和人群，使用独立页面与来源标识，复盘真正新增的客户和现金。^[2]

用量计费先建设计量系统

用量计费让账单随 API 请求、处理分钟、文档、存储、任务或交易增长。它可以让低使用客户以较低成本进入，也可以让收入随客户价值和履约成本增长。

客户愿意接受的前提，是计费单位容易理解、使用可以预测、账单能够核对。产品方还要确保使用事件准确、重复请求不会重复收费、失败任务和退款有一致规则。

截至 2026 年 8 月，Stripe 将用量计费生命周期分成使用数据接收、产品与价格配置、出账和监控四部分。Meter Event 至少关联事件名、客户、数值、时间和用于幂等处理的唯一标识，Meter 再按账期汇总。^[4]

内部计量账本至少保留：

• 客户与产品权益标识；
• 使用事件类型；
• 原始数量与计费数量；
• 发生时间、接收时间和账期；
• 价格版本和币种；
• 成功、失败、重试与撤销状态；
• 幂等标识；
• 来源系统与审计证据；
• 已出账、待出账或已调整；
• 成本和客户收费。

支付服务商的 Meter 不应是唯一原始记录。产品仍需保留可审计的内部事件，才能处理迟到、丢失、重复、价格变更和客户申诉。