一、项目背景 我们接手某宠物连锁的数字化改造，这家连锁在一个城市开了二十多家社区门店，主营业务就两块：一块是猫狗主粮和零食的定期订阅，另一块是门店笼位的宠物寄养。订阅最早完全靠店员在私域群里手动提醒客户该续了，漏提醒就断购，客户体验非常碎，总部也完全看不到真实的续费节奏。寄养更乱，笼位排期全靠门店电话和一本手写本，旺季一来就撞单，谁家的狗该住哪间笼经常对不上，寄养前的疫苗和健康告知全凭口头说一句，真出了事双方都拿不出证据。我们最早觉得这种小连锁用电话加本子也能跑，是被一次春节寄养高峰教乖的：那天三家店同时撞单，两只猫被临时挪笼，主人来接发现不对，当场闹到要投诉。那次之后我们确定，这门生意必须先解决计划性和笼位唯一性两个根问题，否则往上叠任何会员运营动作都会打偏。

这家连锁早先试过一套通用会员软件，结果寄养和零售逻辑混在一起，店员用不明白就弃了，这次我们把它拆成两条独立业务线才推得动。

顺带说，宠物连锁的会员体系我们没单独重做，直接复用他们已有的微信社群标签，把订阅和寄养的动作挂到标签上，运营不用换阵地就能发提醒，推广成本也低。

二、落地场景 落地的第一块是订阅管理。客户在门店或小程序买主粮订阅套餐，系统按周或按月自动生成续订单，到期前分层次推提醒，支持一键续订也支持临时暂停。第二块是寄养预约。门店把每个笼位录入系统，标清尺寸、适用宠物类型和可租用时段，客户线上选时间段和具体笼位，系统实时做冲突检测，同一笼位同一时间段只能被一个订单锁定。第三块是健康档案。寄养前强制走结构化表单勾选疫苗情况和健康告知，异常宠物单独打标，店员接宠时拍照留档。第四块是到店核验和离店结算，寄养期间每天定时打卡拍照，客户在手机上能看见自家宠物今天的状态。最后总部有一块汇总看板，二十多家店的订阅续费率和各店笼位利用率实时可查，月底对账从翻聊天记录变成导一张表。

笼位还有个细节，门店白天和夜间的可用笼位不一样，我们让笼位带时段属性，夜寄只开放部分区域，避免半夜来寄养没笼位的尴尬。

三、关键技术挑战与解决思路 第一个难点是笼位冲突。我们一开始想用先到先得的乐观锁，结果两个店员在同一秒点同一个笼位，还是能同时下单成功。后来改成下单即占位的悲观锁，把笼位做成状态机：空闲、已锁、已入住、已离店，任何状态变更都必须校验前置状态，撞单基本消失。第二个难点是订阅续订的触发时机，推太早客户嫌烦，推太晚又断购，我们按历史消费节奏做了分层提醒，高活跃客户提前五天轻提醒，普通客户提前三天强提醒，暂停过又恢复的客户单独标黄。第三个难点是健康告知留痕，这块我们用结构化必填表单替代自由文本，疫苗项和健康声明不全就不让提交寄养单，事后扯皮时有据可查。还有一块是门店库存和订阅的联动，主粮临期前系统会优先推给订阅客户做促销，减少损耗。

费用侧也有收获，订阅自动续订后，门店现金流从月初集中收款变成每周都有进账，店长做排班和进货计划更从容，不用再为月底冲量发愁。

四、效果数据 上线约四个月，订阅续费率从原先估算的约五成提升到约七成，断购类投诉降了一半多。笼位利用率从不到四成提到约六成，旺季撞单导致的纠纷从每月十几起降到个位数，其中笼位对不上这一类基本归零。寄养客诉平均处理时长从两天缩短到半天，主要是证据链齐了不用扯。总部第一次能实时看到全部门店的续费和笼位数据，月底对账时间从两个人一天压到一个人一小时。文中数据为项目复盘口径。

从系统上线到现在，这家连锁的店员流动没影响业务连续性，因为所有笼位和订阅状态都在系统里，新人接手看一眼就明白，不像以前全在老店员的脑子里。

五、可复用经验总结 宠物寄养这门生意，锁笼位比锁订单更根本，状态机不理顺，运营动作再花哨也救不了撞单。订阅提醒别一套模板打天下，按客户活跃度分层才有人真的去点。健康告知一定要结构化强制勾选，自由文本事后根本扯不清，我们早期就是靠口头确认，出事时谁都说不清。说到底这种连锁门店的数字化，最难的不是技术，是把店员脑子里那套本子加电话的流程逼着搬到系统里，搬顺了效率才出得来。

还有一点，门店数字化落地阻力不在开发在习惯，店员觉得拍照登记是多的事，我们前期靠店长盯才推下去，后来把登记和计费绑死，不登记不能入流程，大家才习惯。

结语 现在这家连锁把寄养打卡拍照做成了标配动作，客户黏性比纯卖货高不少，下一步我们在看寄养和门店洗护的联动排班，把一次到店的多个需求合并掉。

案例片段（已脱敏）： 寄养笼位状态机核心片段（伪码）：type CageState int const (Idle CageState = iota; Locked; Occupied; Left) func Book(cageID string, t0, t1 time.Time) error {    s := repo.GetState(cageID)    if s != Idle { return ErrConflict }    if repo.Overlap(cageID, t0, t1) { return ErrOverlap }    return repo.Transition(cageID, Locked) // 下单即占位 }上线前我们手动回放了一百二十多笔历史寄养单，发现约一成存在时间段隐性重叠，状态机上线后这类问题在提交阶段就被拦下，没有流到门店现场。