帮客户设计WiFi计费方案时，最常被问到的是：按时间计费还是按流量计费？我每次都不直接给答案，因为选错了比不做计费更麻烦——不做计费顶多收不到钱，选错了计费方式会在收钱的同时引来投诉。

按时包的逻辑和适用场景

按时包给用户一段时间内的网络使用权，不限制这段时间里用了多少流量（或者设置一个很宽松的流量上限）。1小时包、日包、周包、月包都是这个逻辑。

按时包适合的场景有几个特点：用户对使用时长有直觉（知道自己大概用多久），对流量消耗没有感知（不知道看一小时视频用了多少G），网络主要用于轻量用途（查信息、聊天、轻度视频）。酒店过夜客人、咖啡馆短暂停留的客户、展会访客，都适合按时包。他们的网络需求是"在这里的时候能用"，时间是他们能直观感受的维度。

按时包的问题在于带宽公平性：如果不做任何限速，一个用户下载大文件能把其他所有人的网速压到很低。所以按时包通常需要配合单用户带宽上限策略，不是真正的无限速。

按流量包的逻辑和适用场景

按流量包给用户一定额度的数据量，用完为止，不限时。100MB包、1GB包、日租包（含流量上限）都是这个逻辑。

按流量包适合的场景：用户对流量有感知（知道自己大概用多少G），使用场景对流量消耗差异大（有的人只查邮件，有的人看视频），需要对大流量用户做成本分摊。网吧、短租公寓、部分快捷酒店，按流量包有市场。

按流量包的问题在于流量消耗不直观。1GB能用多久？看YouTube高清视频大约2GB/小时，刷微博图文大约100MB/小时，差了20倍。用户购买时很难准确预估，买少了不够用，买多了用不完，两种情况都会产生投诉。另一个问题是"流量用完了但时间还没到"的心理落差——不管实际原因是什么（后台应用更新、系统同步），用户都会觉得被坑了，这个体验比按时包超时要差。

组合方案及其代价

很多实际项目里，单一计费方式不能完全满足需求，组合方案更常见：按时包加流量上限（比如日包内最多10GB），或者按流量包加时间上限（比如1GB包48小时有效）。

这种组合的目的是在两个方向设置保护：时间上限避免一个时间包被长期占用，流量上限避免极端用户影响其他人。

但组合方案的代价是复杂度增加，用户需要同时关注时间和流量两个维度，认知负担更重。WiFi计费系统的Portal页面需要清晰展示"还剩多少时间/多少流量"，而且这个信息必须实时准确。显示不准确的余量信息比不显示更糟糕——用户以为还有剩余，突然断网，投诉就来了。

计费周期和自然日的对齐问题

按时包里有个容易忽略的细节：计费周期从购买时刻起算，还是从自然日起算？两种方式各有问题。

从购买时刻起算（买了24小时包从这一刻算24小时）：用户感受直观，不会凌晨12点包突然失效。但多次购买的用户有效期会错开，管理麻烦，也不容易做包月。

从自然日起算（日包从当天0点到23:59）：适合连续多天的用户，每天早上统一激活，便于结算。问题是下午才入住的用户，日包只剩半天，觉得不划算，容易引发退款纠纷。

WiFi计费系统需要在后台支持这两种方式的灵活配置，购买页面要对有效期做清晰说明。

套餐定价和带宽档次的对应设计

有些WiFi计费系统会提供多档套餐——基础包（低价、限速）、标准包（中价、正常速度）、高速包（高价、高带宽优先级）。这种分层定价看起来合理，但实际运营中有个陷阱：基础包速度太低会引来投诉；基础包速度和标准包差不多，没有人买标准包，分层定价失去意义。

带宽档次的设计要基于实际网络资源来算。出口带宽100Mbps、同时在线100人，平均每人1Mbps，设计"高速包5Mbps"是可以的（因为不是所有人都买高速包），但如果高速包卖出去太多，实际带宽不够，高速包用户的速度也高不起来，被投诉是必然的。带宽策略要结合出口带宽、峰值在线用户数、使用习惯来算合理的限速参数，再定价。

免费时段设置的细节

很多场所设置15到30分钟的免费WiFi，让用户体验后再决定是否付费。实现方式通常是：认证成功后进入免费时段状态，计时器到了自动切断，要求用户付费后继续。

这个设置需要考虑几个细节：免费时段到期时的中断是否友好（最好是弹出续费页面而不是直接断网）、免费时段内是否限速（不限速的话有人会反复重认证只用免费时段）、同一设备的免费时段是否有每日限制。

不考虑这些细节直接开放免费时段，很可能增加的是羊毛党的比例，而不是付费转化率。免费时段是一个设计决策，不是简单开关。