一、项目背景

客户是一家区域健身连锁，三十四家门店分布在两个省，会员总数十一万左右，其中活跃会员四万出头。找到我们的时候，他们刚经历了一场不小的会员纠纷。

事情起因是一张"全城通"年卡。宣传上写的是所有门店通用，实际执行时有三家新店因为器械还没配齐，店长自行规定"通卡会员每月只能来四次"。会员不知道这个规定，去了被拦，闹到消协。查下来才发现，这种店长自定的土规则在系统外遍地都是，有的店限制高峰时段，有的店对通卡会员的团操课收费，全凭店长自己在门口贴张纸。

私教这块更乱。三十四家店有两百六十多名教练，私教课的耗课记录靠教练在纸质台账上手写，会员签个字。台账每月交到总部录入系统，中间隔着二十多天。这期间会员说自己上了八节，教练记的是十节，谁也拿不出证据。财务那边更头疼，预售课的负债规模摸不清楚，年底审计时被问到"未消课余额"，给出的数字和实际能差出百分之十五。

他们运营总监跟我说过一句挺实在的话：不是不想管，是管不了，规则太多太碎，没有工具的时候只能靠人，靠人就一定会各行其是。

二、落地场景

我们基于 XpShop 的会员与订单体系做了改造，核心是把散在纸上和人脑里的规则搬进系统。

卡种权益建模是第一块。原来的卡种有四十七种，梳理之后发现真正有业务差异的只有九类，剩下的都是同类换了个名字或者调了个价。我们把权益拆成可组合的原子项：可用门店范围、可用时段、单日进场次数、团操课权益、器械区权益、淋浴与储物柜、私教折扣、体测次数、访客带入次数。每种卡就是这些原子项的一个组合，配置完直接生效，不用改代码。

跨店通用与限次规则跟着权益走。通卡会员进店闸机刷卡，系统实时判权益，能进就开闸，不能进就在闸机屏上显示原因，比如"该门店本月剩余进场次数 0"。规则是总部统一配的，店长没有修改权限，只能提申请。

私教约课与耗课核销改成了双向确认。会员在小程序上约课，教练接单，上课开始时教练发起签到，会员在自己手机上确认，或者用会员的会员码扫一下。课程结束教练提交课时，会员再确认一次。两次确认都有时间戳和位置信息。

教练业绩结算按核销记录自动跑。原来每月要三个人核对一周，现在系统直接出结算单，教练在小程序上能看到自己的实时业绩。

三、关键技术挑战与解决思路

权益规则引擎的设计上，我们最初想得太复杂了。第一版做的是通用规则引擎，支持表达式配置，运营可以写任意条件组合。做出来之后运营根本不会用，培训了两次还是不敢配，怕配错影响线上。

后来推翻重做，改成模板化。把常见的权益模式抽成十二个模板，运营选模板填参数就行，比如"限时段模板"只需要填开始时间和结束时间，"限次数模板"只需要填周期和次数。确实牺牲了灵活性，遇到模板覆盖不了的需求得开发介入，但上线九个月只遇到过三次这种情况。这个取舍我现在觉得是对的，工具的门槛必须匹配使用者的能力，不然做得再强也是摆设。

跨店结算分账的规则谈了很久。会员在 A 店办的卡去 B 店消费，收入算谁的，成本算谁的。财务、运营、店长三方意见不一致。最后定的规则是：卡的销售收入归办卡店，但按次分摊一部分给实际服务门店，分摊标准按该卡种的单次成本核算，月底统一清算。这套规则在系统里跑了三个月才稳定，前两个月每月都有店长提异议，逐条查下来，有一半是规则理解偏差，另一半确实是我们算错了，主要错在跨月和退卡的边界处理上。

耗课防作弊是个技术加管理的混合问题。双向确认上线后，还是出现了教练和会员串通刷课的情况，某些教练为了冲业绩，让熟客集中确认一批课时。我们加了几层校验：同一会员两次课时确认间隔不能小于四十分钟；确认时的定位必须在门店地理围栏内；单个教练单日核销超过八节触发预警；单个会员单月核销数超过合同约定节奏的一点五倍触发预警。这些规则拦住了明显的异常，但完全杜绝是不可能的，我们跟客户说清楚了这一点，系统只能提高作弊成本，不能替代管理。

预售课负债核算这块，会计和技术的口径花了两周才对齐。原来财务按"已售课时数乘以单价"算负债，但实际存在打包课、赠课、折扣课，单价不唯一。改成按每笔订单的实收金额分摊到课时，每核销一节冲减一节的分摊金额。这样算出来的负债和实际能对上，误差从百分之十五降到百分之一以内。

案例片段（已脱敏）：卡种权益的一段模板化配置。

json {  "card_type": "CITY_PASS_ANNUAL",  "name": "全城通年卡",  "valid_days": 365,  "benefits": [    {"tpl": "store_scope", "mode": "ALL", "exclude": ["ST0031","ST0032"]},    {"tpl": "time_window", "weekday": "06:00-22:30", "weekend": "08:00-21:00"},    {"tpl": "entry_limit", "period": "DAY", "times": 1},    {"tpl": "group_class", "included": true, "quota_per_month": 12},    {"tpl": "pt_discount", "rate": 0.92},    {"tpl": "guest_pass", "times_per_month": 2}  ],  "settlement": {"revenue_owner": "SELLING_STORE",                 "share_to_serving_store": true,                 "share_basis": "PER_VISIT_COST"} }

案例片段（已脱敏）：一次耗课异常预警的处理记录。

alert_id=PT-ANOMALY-0417  level=WARN coach=C0186  store=ST0009  date=2026-XX-XX rule_hit: daily_verify_count=11 (threshold=8) detail:  09:20 M07731 confirm  gps_ok  09:55 M07731 confirm  gps_ok   <- 间隔35min，低于40min阈值  10:12 M08842 confirm  gps_ok  ... disposal: 冻结该日3笔核销，转门店经理线下核实 result: 2笔为连堂课属实予以恢复，1笔为提前确认已撤销

四、效果数据

上线到现在九个多月，几组关键数字如下。

核销准确率从原来的百分之八十八点四提到百分之九十九点二。这个口径是抽样核对系统记录与会员实际到店记录的一致性。会员因课时争议发起的投诉从月均二十三起降到两起。

跨店通用率是个新指标，原来根本统计不了。现在通卡会员的跨店消费占比达到百分之三十一，比客户预期的高不少。这个数据反过来影响了他们的选址策略，原来担心开新店会分流老店，现在发现通卡会员的活跃度反而提升了。

耗课争议数月均从四十七起降到三起，剩下的三起基本是会员对课程质量不满意引发的，不是记录本身的问题。

结算周期从原来的次月十五号出结果，缩短到次月三号。财务那边省下的人力大概是每月两个人一周。

预售课负债的账实差异从百分之十五降到百分之零点八。这个数字客户的 CFO 最在意，审计那关过得比往年轻松。

另外有个意外收获。权益规则统一之后，店长自定规则的现象消失了，会员对"规则不透明"的投诉从月均十九起降到零。运营总监说这块的价值比效率提升更大。

五、可复用经验总结

会员权益这类项目，梳理的价值大于开发的价值。四十七种卡合并成九类的过程，本身就解决了一大半问题。我们花在梳理上的时间是开发时间的一点三倍，客户一开始觉得我们在拖，做完之后他们自己也承认，如果照着原来那四十七种卡直接开发，系统会复杂到没法维护。

规则引擎不要一上来就追求通用。第一版通用引擎那次返工，损失了三周工期，教训是产品设计要看使用者是谁。健身房的运营专员不是工程师，给他一个表达式编辑器等于什么也没给。模板化虽然土，但能用起来。

涉及钱的规则一定要让财务参与到设计阶段，不能等做完让财务验收。跨店分账和预售负债这两块，我们都是先做了技术方案再找财务对，结果两次都推翻重来。后来的项目里我们把财务拉进第一次需求评审，效率高很多。

防作弊的定位要摆正。系统能做的是提高作弊成本和留下证据链，管理动作还是得人来做。我们把这个话在项目启动会上说清楚了，避免了后期客户拿"还有人作弊"来质疑系统价值。

线下场景的双向确认要考虑现场体验。最初设计的确认流程有四步，教练反馈说上课前折腾这么久很影响节奏，后来简化成两步，会员扫一下教练的动态码就完成签到。功能设计得再严密，如果现场用起来别扭，最后一定会被绕过去。

这套东西目前还在补一块，就是团操课的排期和上座率优化，客户希望能预测每节课的到课人数来调整排期。这块数据积累还不够，暂时没动。