前言
有不少 SaaS 产品会提供免费试用功能，通常是15天或30天。通过免费试用，一方面可以让客户自己熟悉 SaaS产品，评估是否符合他们的业务；另一方面由于不需要付费，缩短了客户的购买决策链路。如果产品本身做得优秀，又能满足客户的业务需求，价格也合适的话，那么客户在试用结束后大概率是会转为付费订阅的。所以，免费试用的根本目的还是促成客户购买，通过免费试用既降低了 SaaS 企业的销售成本，也降低了客户直接购买缺不适用的风险，可以说是一举两得的事情。
最近正好在写 SaaS 架构专栏部分的销售版本内容，然后就想到了如果某个销售版本支持免费试用的话，产品该如何设计的问题。本篇就来讲讲这块的设计。
“简单”的设计
最直接的想法就是在销售版本管理中，给免费试用的版本配置两个属性，一个是否支持免费试用的属性、一个试用期限的属性。然后对于新客户，注册后可以选择该版本进行试用，业务逻辑上处理如下：
标记该客户为试用客户，并且根据试用期限设置试用截止日期；
若试用截止日期到达之后，客户未付费，则停止客户的使用权限，并且提醒客户付费；
若在截止日期到达之前，客户选择了付费，则按照付费的订单，更新客户使用的版本和到期期限，并去除试用标记。
从满足试用这项业务来说，这样的设计足够了，而且看起来也很“简单”。但是这样做合理吗？未必，比如运营同学问下面几个问题：
累计（或某段时间内）有多少试用的客户？
我想知道有多少客户是从试用转为付费的？
试用客户的转化率怎么样？
付费用户到期后，还能免费试用吗？
这个时候上面的设计就满足不了了。当然，解决上面的问题也可以给每个试用的客户增加一条试用记录 —— 事实上我们经常这样为了满足某个需求，然后就增加一些临时解决问题的功能。结果就是，我们的产品有很多僵化的设计（技术上叫做硬编码，或者叫做“写死代码”），导致产品的可扩展性非常不好。
合理的设计
我们来看看更合理的设计应该是什么样。实际上，我们分析一下，不管是免费试用订阅还是付费订阅，除了价格上不一样，其他属性都是相同的。因此，我们可以把免费试用订阅和付费订阅合并一起管理，对应的都是订阅订单。这样，很多处理是相同的。
客户订阅：统一创建订阅订单，区别只是价格不同，但是订单的属性都是一样的。
到期时间：根据订阅的方式设定到期时间，只是免费版本的到期时间是预设的。
到期处理：到期处理也是相同的，都是提示用户当前订阅已经到期，当然，提醒文案上面对于免费试用客户做特殊处理。这种文案也可以统一在 SaaS 平台侧管理，方便根据运营需要调整文案，这样也可以做到提醒文案的逻辑统一。
试用标识：对于 SaaS 产品，通常一个客户只会有一个有效的订阅订单，因此我们可以按照有效订单来做标识，如果订单金额为0的话就标记为试用。
基于上面的设计，我们的硬编码基本上没有了，这样扩展性更强，而且产品的可维护性也会更好。同时，如果做数据统计，我们也能够基于统一的订单管理做到如下统计：
累计（或某段时间内）的试用客户数量：只需要筛选出订阅订单金额为0的客户数量即可。甚至，我们还可以区分不同的试用版本（如果支持的话）。
试用客户转付费客户的数量及转化率：基于试用客户，再筛选这些客户在试用之后有付费订阅订单即可。用试用转付费的客户数量除以总的试用客户数量就得的试用转付费的转化率了。
付费用户到期后，一般是不再支持继续免费试用的。这种约束可以通过看某个用户是否有过试用订阅订单完成。
可以看到，基于这样的设计，我们的业务更加统一，而且也能简化开发工作。合理有时候不一定要以复杂作为代价的。
总结
我们在做产品设计的时候，有时候面临新的需求变更，为了追求速度，就会使用“打补丁”的方式。然而，这种一时满足需求的做法，很可能是在给未来挖坑。等到后续越来越多的需求调整的时候，就会发现我们的产品变成了“丑八怪”。
对于需求分析，个人的建议是“多想一步”，考虑可能的扩展。尤其是产品已经过了 PMF阶段后，任何产品的变更都隐藏着隐患。对于 B 端产品，更稳妥的方式是减少变更，这样产品的稳定性会更有保障。这就需要产品经理从多样的需求中抽象出共性的东西，基于共性的抽象进行产品设计，会让产品的可扩展性和可维护性得到提升。而且，相比不断打补丁，这样的方式设计出来的产品的稳定性也会有更好的保障。
文中配图由 Midjourney 生成
