宠物寄养小程序完整功能设计方案：从订单状态机到视频监控接入

宠物寄养这门生意，做线下的人一抓一大把，但能把线上预约、监控反馈、订单管理跑通的小程序，真没几个做得像样。我这两年帮朋友门店搭过一套寄养系统，也拆解过市面上几款热门产品，最大的感受是：宠物寄养小程序难的不是下单支付，而是“寄养中”那几天怎么让主人不焦虑、让店员不手忙脚乱、让应急事件不背锅。

这篇就把完整的功能设计方案摊开来讲，从用户端、商家端到平台端，从下单状态机到视频监控接入，再到审核避坑、运营打法，尽量让拿到方案的人可以直接照着设计，甚至排期开发。

1. 项目背景与需求拆解：先想清楚再做功能

1.1 宠物寄养行业的三类痛点

先别急着画页面，搞清宠物寄养这门生意的本质，比功能清单重要得多。我接触过的寄养场景，几乎绕不开三类痛点。

第一类是主人的焦虑。宠物送去陌生环境，主人看不到、摸不着，脑子里全是“它吃没吃”“有没有被欺负”“会不会逃跑”，尤其春节、国庆这种高峰期的寄养，主人和门店之间全靠微信聊天，店员忙着喂粮还要抽空回消息，回慢了就是差评，回快了手上活儿又出错。信息不透明是行业最大的隐形杀手。

第二类是门店的管理混乱。寄养不是卖货，是一次持续三五天甚至半个月的服务过程。每个宠物吃什么粮、几点遛、有没有皮肤病、脾气好不好，全凭店员脑子记或者本子记，一旦换班或者高峰期十几只宠物一起住，漏喂一顿、错吃一餐、遛狗绳子拿错，都是真实发生过的翻车事故。没有系统化记录，出了问题还说不清责任。

第三类是责任纠纷难以定责。宠物寄养期间抓伤、生病、不吃不喝、应激甚至死亡，责任到底在门店还是主人？没有入住前的健康确认、没有日常记录、没有异常上报，出了事全靠扯皮，严重的甚至闹到投诉平台。这个风险不提前用流程和功能规避，上线后迟早要出大事。

这三点串起来，就决定了小程序的核心价值不是“下单工具”，而是“信任媒介+服务记录仪+责任凭证”。所有功能设计，都必须围绕降低主人焦虑、提升门店效率、明确责任边界三条主线展开。

1.2 为什么一定选小程序而不是App或公众号

方案里第一个被反复问的问题就是：为什么不做App？不做H5？不做公众号？

我的判断很简单，宠物寄养是典型的低频但高客单服务，一个主人一年也就寄养三五次，让他为了寄养下载一个App，获客成本直接把他劝退。小程序天然免安装、微信里随手打开，匹配这种偶发需求。更关键的是，寄养场景里有一堆高频动作需要触达用户——每日喂养反馈、异常提醒、接宠提醒，这些用微信订阅消息就能实现，App推送反而要先解决一堆权限问题。

相比公众号H5，小程序在硬件调用上完胜。寄养中要给主人开放实时监控，小程序能直接播放摄像头流，甚至对接微信的live-player组件；要定位门店导航，微信地图SDK顺手就接了。H5在视频播放体验、蓝牙连接（后期接智能项圈）、缓存能力上都明显吃力。小程序还有一个隐性优势：微信支付的交易担保心智，用户付款时天然多一分信任感，这对寄养这种“先交钱后服务”的模式很重要。

如果你是在微信生态里起盘，别犹豫，原生微信小程序起步，后期真要扩到支付宝再做多端。技术选型上一开始就别给自己挖坑，后面我会专门讲uni-app和原生的选择问题。

2. 功能模块全景设计：把用户端和商家端拆开看

2.1 用户端核心功能清单与逻辑

从用户体验角度，我把用户端功能按“下单前、寄养中、接回后”三个阶段拆。这个拆法，功能设计评审时非常好讲，开发也容易排期。

下单前的核心模块是宠物档案和门店选择。宠物档案不只是填名字和品种，要覆盖品种、年龄、性别、是否绝育、疫苗记录、驱虫记录、体重、过敏史、饮食习惯、性格标签（是否怕生、是否护食、能否与其他狗相处）、常用药清单。这套档案的价值在于：寄养申请时自动匹配门店是否具备接纳条件，避免到了店里发现“你这狗不能跟别的狗放一起”的尴尬；同时入住时免去重复填写，主人体验会顺很多。

门店列表页要有几个硬指标筛选：距离、可接宠物类型（猫/狗/小宠）、剩余房位、评分、监控是否开放。宠物主人对“能不能看到我的猫”这个诉求，比想象中强烈，开放监控的门店在小程序里要有明显标识，这是差异化卖点。预约下单流程要支持选择入店和离店日期、选择房型（标准间/豪华间/独立猫别墅）、选择服务包（基础喂养、遛狗次数、洗澡、视频通话专享）。

寄养中的核心是每日反馈和实时互动。每天固定时间推送图文日报：吃了多少、便便情况、精神状态、遛弯视频、店员留言。别小看这条日报，它是整个小程序打开率最高的模块，也是续费、复购、转介绍的核心钩子。实时互动包括监控直播、限时视频通话（按次计费或VIP权益）、消息在线沟通。其中视频通话要注意隐私，主人发起后店员端要确认接听，防止店员换衣间这类场景被误开。

接回后的核心是结算评价和凭证归档。离店时生成费用明细（加购项目、超时费用单独列），支持在线支付尾款。评价维度不要只给星级，要细化成环境整洁、服务态度、宠物状态、实时反馈及时性几个维度，这些数据反过来能成为门店优化服务的依据。历史订单里要有完整的入住报告归档，主人可以随时回看，这也是老客复购的信任依据。

2.2 商家端与平台端的功能补位

商家端不能简单理解成“后台管理系统”，它是门店日常运营的作业台，设计不好店员根本不会用。核心分三大块：房态日历、订单工作台、喂养任务流。

房态日历是寄养门店的命根子，每天哪个房间空着、哪个被预订、哪只宠物住到几号，必须一览无余。这里有个容易踩的坑：寄养订单跨天，房态冲突的校验逻辑不能只看单日，要按“预订开始日到结束日之间的每一天”去查空房，否则就会出现一房两卖的严重事故。我见过有团队上线第一天就出这个问题，客人带着狗到店发现房间被占了，场面极其尴尬。

订单工作台要按状态分组：待确认、待入住、寄养中、待接回、已完成、已取消。每个寄养中订单点进去就是该宠物的完整档案、每日记录、监控入口、异常上报按钮。节点要留痕，谁确认的、谁办理入住的、谁上传的喂养记录，都要有时间戳和操作人，这是责任追溯的底牌。

喂养任务流是整个商家端最提效的部分。店员手机端每天早上自动生成今日任务：9点喂A笼狗狗粮50g加鱼油、9点半遛B区柯基15分钟、10点给C猫换猫砂。完成一个勾一个，系统自动生成日报推给主人。这个设计把“服务过程”从店员脑子里搬到了系统里，换班、请假、新店员上手都不断档。

平台端如果是多门店连锁或者做SaaS输出，还需要增加门店审核、服务类目管理、抽佣结算、数据看板（入住率、复购率、差评预警）。这块第一期可以砍掉，但数据埋点务必从第一天就做，否则后面想分析连基础数据都没有。

2.3 用一张功能优先级表控制MVP范围

做小程序最怕什么？怕需求方什么都想要，第一期就做成全家桶。我建议用一张功能优先级表来对齐预期，把功能分成三期落地。

P0和P1的分界线，就是“能不能用、能不能闭环、会不会出事”。P0没做全，业务跑不起来；P1不做，只是体验差点；P2这时候碰，纯属给自己找麻烦。

3. 关键业务场景流程设计：把状态机和异常链路画清楚

3.1 从下单到入住的完整状态机

寄养订单的状态流转，是后端设计的核心，前端页面只是表象。状态机设计得不严谨，会出现订单卡死、重复操作、退款对不上的问题。我习惯把订单状态拆成八个节点，每个节点的触发条件和操作人都要明确：

待支付 → 待确认 → 待入住 → 寄养中 → 待接回 → 已完成

这两个分支：待支付超时自动取消；寄养中异常中止（宠物生病提前接走）。

关键点有两个。第一，“待确认”是商家侧的人工审核节点，不是自动接单。门店需要确认可接纳这个宠物（看档案、看房态、看店员排班），再决定接不接单。别做自动接单，寄养不是外卖，没有拒单风险控制会出事。第二，“寄养中”到“待接回”的触发时机，要明确是主人发起还是店员发起。我的建议是店员操作“确认离店日期”，因为只有门店最清楚实际寄养天数，同时要兜底超时自动补差价逻辑，防止主人实际晚接了两天但系统没感知。

入住登记环节要增加“入住检查表”：外观检查（皮肤、眼睛、耳朵、脚垫）、物品交接（主人自带的粮、玩具、窝）、健康确认（当前精神状态）。这份表单要主人和店员共同签字确认，拍照留底。它的实质是责任转移的文件，宠物进店前就有的皮肤问题，如果系统里没记录，离店时被说“你们把我狗养出皮肤病”，门店完全没法自证。

3.2 寄养中的日常反馈与应急流程

日常反馈流程的底层逻辑是：店员完成任务后系统自动生成消息，而不是让店员每天手动编辑。具体跑法是这样：店员完成喂食，在任务流里勾选“已喂”，选食量档位（全部吃完/剩一点/完全不吃），拍照上传；系统汇总一天的任务记录，到晚上固定时间（比如20点）用订阅消息推送当日简报给主人。

这条链路里隐藏着一个数据设计细节：日报里每一条数据都应该有结构化的字段，而不是一张图片一行文字。吃没吃、拉没拉、精神状态好不好，要做成可筛选的标签和档位，这样后端才能积累数据，后续才可能做“宠物寄养健康趋势分析”这种增值功能。纯图片的日报，主人看着热闹，但商家自己沉淀不了任何数据资产。

应急流程是我在所有评审会上都会重点强调的部分，这里给出一个基于常见实践的补全方案。系统要有独立于日常反馈的“异常上报”入口，店员发现宠物精神萎靡、呕吐、拒食、受伤时，一键上报，系统立即执行三个动作：推送异常通知给主人（带当前状态描述和照片）；在商家工作台生成“应急任务”并提醒店长处理；如果是合作医院覆盖范围内，自动展示最近的合作宠物医院地址和电话。

更稳妥的做法是：异常上报后，门店要在系统里记录“已处理措施”和“与主人沟通结果”，形成闭环。这个场景不要追求全自动，核心是留痕和快速通知。真出事了，小程序不是用来救命的，是用来让双方都不至于空口无凭的。

3.3 接回验收与评价闭环

接回是服务流程的最后一公里，最容易在这里翻车。我的设计方案里，离店要做三件事：宠物状态确认（当前精神、体重变化、外观对比）、增项费用结算（超出天数的房费、额外洗澡、购买用品）、档案归档（本次寄养的完整记录生成PDF或长图，主人可保存）。

这个环节建议加一个“离店疫苗检查”的引导：寄养超过一定天数的宠物，离店时提醒主人确认是否接触过其他宠物、是否需要补打疫苗。这不是功能刚需，但对体现专业度、提升口碑非常加分。

接回流程结束后，系统自动触发评价邀请，但注意不要当天弹，可以延后到第二天。原因很现实：宠物刚回家可能因为应激又拉又吐，主人一着急容易把情绪发泄到评价里；等第二天宠物状态稳定了，好评率会明显提高。这个小细节，踩过坑的人自然会懂。

评价闭环的价值不只是点评，它是下一笔订单的信任起点。用户写完评价后顺手弹一个次卡优惠，把一次性用户转化成回头客，是成本最低的增长手段之一。

4. 技术方案与数据设计要点：选型、表结构、难点

4.1 技术栈选型：原生、uni-app还是云开发

技术栈的选择没有绝对答案，但要结合团队情况、预算和业务复杂度来判断。这里我把三条路线讲透。

如果你只有一个后端加一个前端开发，目标是尽快上线验证，建议原生微信小程序 + 微信云开发。云开发自带云数据库、云函数、云存储，用户登录、图片上传、订阅消息发送都能直接调，省去自己买服务器、配域名、备案、搞HTTPS的繁琐流程。对宠物寄养这种中小体量业务，云开发的性能完全够用，而且按量付费，初期成本很低。

如果后续确定要铺支付宝小程序和抖音小程序，或者团队里前端是Vue技术栈，uni-app确实能一套代码多端编译。但我的忠告是：不要高估多端复用的收益，低估UI适配和平台差异带来的工作量。微信小程序的live-player、订阅消息、支付，在支付宝里各有各的接口和审核逻辑，所谓的“一套代码”到后面往往要写一堆条件编译。前期如果是单微信端，原生比uni-app稳。

还要说一句容易被忽略的：不管你选哪条路，云函数/后端接口的权限校验都要认真做。宠物寄养涉及用户手机号、家庭住址、宠物健康信息，权限设计不能只靠前端隐藏按钮。后端每个接口都要校验登录态和资源归属权，防止横向越权——用户A通过改参数看到用户B的宠物档案，这种漏洞一旦被曝光，对产品的信任打击是毁灭性的。

4.2 核心数据表设计与关键字段

数据库设计直接决定后续功能能不能撑住。这里给出核心表的设计思路，不需要完整SQL，但表结构和关键字段必须提前约定。

宠物档案表：主键id、主人openid、宠物名、品种、年龄、性别、绝育状态、体重、疫苗截止日期、性格标签、忌口信息、常用药、备注。疫苗截止日期这个字段非常重要，它是入住审核时判断“能不能接单”的依据之一。

寄养订单表：主键id、订单号、门店id、宠物档案id、主人openid、房型、入店日期、离店日期、每日价格、附加服务项（JSON格式）、订单状态、实付金额、支付单号、创建时间、更新时间。订单号生成建议用“日期+随机数”，别用数据库自增id直接暴露给用户，否则竞对能通过订单号看出你的单量。

喂养任务表：主键id、订单id、宠物档案id、日期、时段、任务类型（喂食/遛狗/猫砂/洗澡）、完成状态、操作人、备注、图片数组。这张表是每日日报的数据源，也是店员工作台的今日任务数据源。查询时按“日期+门店id（或店员id）”过滤。

每日日报表（可以设计为按天聚合的汇总表，也可以直接由任务表聚合生成）：订单id、日期、进食档位、便便状态、精神状态、遛狗次数、照片组、店员留言。汇报时前端拿到聚合数据直接渲染。

入住检查表（也是责任留痕的关键）：订单id、宠物外观情况（多选+图片）、物品交接清单、健康状况、主人电子签名、店员签名、时间戳。

有了这五张基础表，用户端、商家端的主要页面和流程基本都能支撑起来。后续加监控、加会员、加多门店，都是在这些表的基础上外扩领域表，不要上来就把表设计得太细太散，迭代会非常痛苦。

4.3 消息推送、支付与视频监控的技术细节

这三个点都是“看起来简单、做起来一堆坑”的部分。

消息推送必须用微信订阅消息。寄养场景里要申请这几个模板：入住确认通知、喂养日报通知、异常提醒通知、离店提醒通知。特别注意，订阅消息的“一次性订阅”逻辑意味着用户每同意一次，你只能推送一条，所以要在用户完成下单或授权动作时，把未来几天会推送的模板一次性全部勾选请求。比如下单成功页弹窗让用户同时订阅“日报通知”和“离店提醒”，否则用到第二次的时候发现没有推送配额，日报就发不出去了。这个坑几乎每个做订阅消息的团队都会踩。

支付建议用微信支付Native或JSAPI，也就是业内常说的“JSAPI支付”。宠物寄养的支付不是单纯的先付全款，我见过两种主流模式：下单时先付定金或全款，离店结算时算增项。建议第一期做“全款预付+离店补差价”，补差价通过订单详情页再发起一笔收款，或者生成一个待支付账单，避免退款流程的复杂度。切忌做“先服务后付款”，寄养完成后跑单率会高到让你怀疑人生。

视频监控是技术门槛最高的模块，因为优化的是延迟、成本和用户体验的平衡。方案上建议门店端使用支持RTSP或GB28181协议的摄像头，通过流媒体服务转成HLS或HTTP-FLV拉流，小程序端用live-player组件播放。如果单店摄像头少于8路，直接用云厂商的物联网视频服务，甚至可以考虑通过WebRTC网关转流；如果门店已装海康、大华这类传统摄像头，其SDK自带云平台也能提供直播链接，直接对接即可。

这里要提醒三个注意事项：直播流的Token要有时效设计和访问鉴权，不能让任何人拿到URL就能看，这是隐私红线；直播要有一键关闭的开关（这个开关由店员端控制），遇到需要隐私的场景能随时掐断；多路直播时要做码率自适应和清晰度切换，移动网络下主人才能流畅看。

5. 平台规则、审核与体验避坑

5.1 类目资质与隐私合规

宠物寄养小程序上线前，最容易卡住的就是类目审核。这里建议去微信公众平台查询最新类目要求，通常寄养服务涉及“生活服务 > 宠物”类目，部分情况还可能需要提供营业执照和特定行业资质。小程序名称也要和营业执照主体对应，主体不匹配会导致名称审核驳回，这是所谓“小程序名称审核与主体不匹配”这类问题的根源，务必提前对好主体信息再提审。

隐私合规方面，小程序会采集用户手机号、宠物信息、位置信息，必须在小程序后台配置“用户隐私保护指引”并明示收集目的。最近的平台规则对隐私弹窗审核越来越严格，没有配置或被投诉，轻则功能受限、重则下架。有一个容易忽略的点：如果后续接入了摄像头直播，要让门店在寄养服务协议里明确告知主人“门店公共区域及部分房位设有监控”，并在小程序里提供查看直播的授权确认。这一步既是合规要求，也是责任边界。

5.2 缓存、上传限制与列表性能

你以为这些是小事，其实都是用户体感最明显的地方，也是业内人士常讨论的技术细节。

图片上传是第一道坎，微信小程序对上传图片的大小限制比较严格，而现在的手机照片动不动就3MB以上。解决方案是前端先用canvas或压缩组件把图片压到200KB以内再上传，一是能节省云存储流量，二是上传速度快，店员在繁忙时段不会因为等上传而烦躁。视频上传也一样，日常反馈里如果要传短视频，建议限制在15秒以内，并且压缩到1MB左右，超过大小就提示用户重新录制。经验值是：日报以图片为主、短视频为辅，可以把用户体感和服务器成本同时兼顾。

缓存设计上，宠物档案、门店列表这类低频变化数据要本地缓存，设置合理的过期时间；订单详情则每次实时请求，避免用户看到过期状态。经常出现的一个问题是“缓存时间设太长，用户改了宠物档案，门店端看到还是老照片”，我的建议是：宠物档案缓存2小时以内，订单状态缓存30秒以内，宁可多请求几次也不能用脏数据。

列表性能上，寄养订单列表会随着用户使用慢慢变长，接口要分页，前端要触底加载；门店列表要有距离缓存和筛选条件的本地记忆。这些细节不高级，但没有它们，小程序用起来就会卡、慢、乱，用户不会觉得是你技术不行，只会觉得“你们平台不行”。

5.3 常见问题排查实录

根据过往项目经验，整理几个高频问题供参考。

这些问题的共性是一个字：预。上线前把这些链路都过一遍模拟一遍，省下的都是半夜救火的命。

6. 从设计到上线的运营打法：别让功能白做

6.1 MVP上线策略：先用人工补齐系统短板

功能设计得再全，如果门店实际执行跟不上，也是白搭。我的建议是第一版上线时，把P1的功能先用人工流程模拟。比如实时监控二期才开放，那第一期就规定店员每天至少发三条视频到用户沟通群，用企业微信或微信群充当半自动的“日报推送”；异常上报功能还没开发，那就固定一个手机号作为应急热线，店员直接打电话报备。

这样做的好处是，业务跑通的同时还能积累最真实的用户反馈。你会在第一批用户身上发现很多纸上谈兵看不到的需求，比如“主人半夜想看猫”“主人要求指定某位店员遛狗”“主人担心寄养期间宠物被别的狗欺负，要求每天拍同笼视频”。这些需求收集起来，再排二期功能优先级，比几个人闭门造车靠谱得多。

6.2 增长与留存的具体打法

最后说几个验证过有效的小功能设计，它们不属于核心交易链路，但对增长帮助很大。

第一个是寄养日历提醒。用户从第一次下单开始，小程序就在“我的”页面展示本年寄养记录，并推算“下次可能寄养的时间”提前推提醒。养宠物的出行需求往往有周期（节假日、出差、旅游季），在用户可能下单的时间点出现，转化率非常高。

第二个是转介绍激励。寄养订单完成后，生成一张“寄养体验卡”，主人可以转发给同城养宠群，朋友通过卡片下单并完成寄养后，双方各得一张服务折扣券。宠物主之间天然有社群，这个裂变路径比投放广告划算。

第三个是离店后的关怀回访，建议放在接回后的第3天触发。询问“宝贝回家后状态怎么样”，并配一篇宠物应激小科普，提醒主人可预约日常洗护服务。看似是关怀，实际上是在给下一次消费埋钩子。这套逻辑跑顺后，寄养小程序的用户生命周期价值会比单次寄养费用高好几倍。

我个人在实际操作中的体会是：宠物寄养小程序最大的挑战不在技术，而在“把服务过程数字化”这件事上，能不能让门店店员真的愿意用、坚持用。功能设计再完美，店员嫌麻烦不录数据，主人端体验立刻塌方。所以设计时一定要把自己代入到那个又忙又累还要抱狗拍照的店员身上，所有录入动线都要足够短、足够无脑。

另外一个值得反复提醒的建议是：第一版做减法，只保留下单、档案、日报、订单管理这四件事，跑通三个月再谈监控、会员、多门店。先把“主人安心”这个核心价值打透，比堆功能重要得多。毕竟寄养这行，口碑才是命根子。