海外开到50家，开源收银软件为何还按店收费

吉隆坡一家茶饮店，晚上十点半打烊。店员把当天的现金和小票对完，老板在手机上翻了一眼报表，关灯走人。这套动作，和他三年前在厦门开的头一家店几乎一样。不一样的是，他现在有五十多家店，分布在三个国家，收银系统还在按月、按店付费。

他跟我聊过一次，说这笔钱花得有点别扭。软件是开源的，代码摆在那边谁都能看，可账单上的数字跟着门店数一起涨。多开一家，就多一份。他问过服务商，对方说这是行业惯例。

惯例归惯例，账要算清楚。

开源不等于免费，收银软件的账本分两栏

很多人对开源有个误会，以为源码公开就等于零成本。实际不是。公开资料显示，开源协议约束的是代码的使用、修改和分发权利，不约束服务。系统跑在门店里，要有人部署、有人维护、有人处理支付通道对接、有人管数据备份。这些活儿不会因为代码开源就自动消失。

所以按店收费，收的往往不是软件本身，是服务半径。一家店一套配置，五十家店五十套配置，出了问题要能定位到具体哪家店、哪台机器、哪个班次。这种颗粒度的支持，成本确实跟着门店数走。

麻烦的地方在于，连锁门店的需求并不是线性叠加的。开到第五家店和开到第五十家店，管理复杂度差着量级。前者老板自己盯得过来，后者得靠总部统一管价格、管库存、管会员。这时候按店计费的模式，就开始和实际价值脱节。

出海连锁的收费痛点，卡在“店”这个单位上

我接触过的出海餐饮老板，抱怨集中在几个地方。

一是汇率和结算。按店收费，账单通常以服务商所在地货币计价，门店开在几个国家，财务每个月要处理多笔不同币种的支出，对账麻烦。

二是门店生命周期不匹配。餐饮开店有试错，有的店开半年就调整，有的店旺季临时加档口。按店收费的合同往往按年签，店关了费用不一定跟着停。多数情况下没这么理想，老板得自己去谈。

三是总部和门店的权限切分。连锁要的是总部能看全局、门店只能看自己。按店收费的系统，权限模型有时是按单店设计的，开到几十家之后，总部账号反而成了瓶颈。

这些痛点不是某一家服务商的问题，是计费单位和组织形态之间的错位。店是物理单位，连锁是管理单位，两者不总是一一对应。

私有化部署的钱，到底花在哪

出海连锁讨论收银方案，绕不开私有化部署。据公开的行业讨论，私有化的一次性投入通常高于SaaS的年费，但边际成本随门店数增加而摊薄。这笔钱主要花在三处。

服务器和运维。系统部署在自己可控的环境里，硬件、带宽、备份策略都要自己规划。门店越多，数据量越大，这块投入越实在。

合规和数据归属。不同国家对交易数据的存储位置有不同要求，公开资料显示，部分市场对支付数据的本地化存储有明确规定。私有化在这一点上给了企业更多主动权，代价是要自己承担合规责任。

实施和迁移。老系统里的商品、会员、历史订单要搬过去，五十家店的迁移不是一天能完成的。这块的人力成本，往往被低估。

说白了，私有化不是省钱方案，是把按店递增的变动成本，换成一次性的固定投入。划不划算，取决于门店数和开店节奏。稳定在几十家、短期不再大幅扩张的连锁，账算得过来；还在快速试错的品牌，未必。

计费模式怎么选：先看门店的扩张曲线

选SaaS还是私有化，我一般建议老板先画一条线：未来两年门店数的走势。

曲线陡的，SaaS的按店付费反而灵活，开一家付一家，关了就停，现金流压力小。曲线平的，门店数稳定在一个区间，私有化的摊薄效应就出来了。

还有一层是数据主权。连锁做大了，交易数据、会员数据是核心资产。这部分放在谁的环境里，长期看是个战略问题，不只是成本问题。

第三方横评里常提到，餐饮SaaS的优势在开箱即用和持续迭代，私有化的优势在数据可控和深度定制。两边都有道理，关键看企业现阶段更缺哪一样。

银枣 Inza 看到的实践：计费单位跟着管理单位走

银枣 Inza 在服务出海连锁的过程中，接触到的情况和上面说的吻合。门店数过了三十家之后，客户问得多的不是功能，是“总部能不能一套配置管所有店”“新开一家店的系统上线要多久”。这类问题指向的，其实是计费和管理单位要不要从“店”上移到“品牌”。

行业里做餐饮SaaS的服务商，近两年也在调整计费口径，有的按门店档位阶梯定价，有的把总部账号和门店账号分开计。方向是让费用结构更贴近连锁的实际管理形态。这套逻辑能不能跑通，还要看落地时的实施能力。

回到吉隆坡那家茶饮店。老板后来没换系统，只是把合同重新谈了一轮，把总部账号的权限和几家新店的计费方式理清楚了。他说，钱不是不能花，得知道花在哪。