小程序 / 本地生活小程序 / 本地生活小程序后台系统Web 网站已交付
宠物上门服务与零食铺双业务小程序
在既有上门服务系统上扩出零食商城，会员体系统一、两种履约方式分开建模。
成果与数据
183 个
业务接口
32 张（去重后）
业务数据表
上门服务 + 零食商城双线
业务形态
小程序 + Taro + 管理后台
技术栈
业务范围仅上门服务上门服务 + 宠物零食铺双业务
模块复用—按模块评估复用，既有优惠券等能力保留
业务接口—183 个接口 / 32 张去重业务表
订单模型单一订单结构服务单与商品单分开，共享会员体系
以上为上线后的实测对比。数据来自客户现有业务的日常记录（订单系统、排班表、财务流水等）， 由客户方业务负责人确认。没有可靠量化口径的项目，这里只写周期、迭代次数这类过程指标。
客户当时的处境
上门服务做起来了，想顺带卖宠物零食，但两套业务怎么共用会员和优惠券，拆不清楚
服务和商品是两种完全不同的履约方式，混在一张订单表里，管理端就乱了
不想推倒重来，已有的优惠券、会员模块能不能复用，得先摸清现状
怎么做的，为什么这么做
先盘现状再决定复用还是新建
逐个模块评估（优惠券、会员、订单等）哪些直接复用、哪些需要扩展、哪些必须新建，而不是一股脑推倒重做。
两种履约分开建模，会员体系统一
上门服务按次与时段排期，零食按商品与物流发货，订单结构分开；但会员、积分与优惠券统一，用户只感知一个账户。
界面与演示
该项目界面受客户保密要求约束，对外只展示结构示意。如果你需要看实际界面，可以在沟通时申请一次在线演示。
客户怎么说
「以前预约全靠微信私聊，撞单是常事，我一个人得一直盯着手机。现在客户自己在小程序选时段下单，单子直接落给对应的人，我不用再当传话筒。回头客也不用我记了，多久没来的到点就提醒，直接推给客户。」
某宠物服务连锁 · 店长
某宠物洗护与服务连锁门店
该证言已取得客户书面授权后展示。客户不授权公开的证言，本页一律不出现 —— 你用「客户证言」搜不到任何一条未经同意的内容。
JavaSpring BootMySQL微信小程序TaroVue
在既有系统上做扩展而非重建。后端按「服务履约」与「商品履约」两条线拆开建模，共用一个会员与权益中心；小程序侧用 Taro 保持多端可移植。扩展前先出模块复用评估表，避免改一处崩一片。
同类项目
全部项目其他小程序 / 本地生活案例
同类需求的做法可以直接复用，沟通成本也低。
有类似需求？
先聊清楚你要解决的那件事
不用把需求想得很完整。说清楚现在是怎么运转的、最卡的是哪一步， 剩下的功能清单和报价我来整理，你确认就行。
这类项目通常落在「标准版」这一档。 金额我不在页面上写 —— 同样的系统，多一个端、多一项对接， 成本就差一截，写出来一定不准。
说说我的需求