1. 先说实话家政公司缺的不是订单而是把订单管明白的工具我在帮家政公司做系统选型和落地这件事上接触过不下几十位老板和店长。聊到最后几乎都会落到同一个问题上客户不缺咨询订单也不缺缺的是一套能把“客户从哪来、服务干得怎么样、下次怎么再来”串起来的工具。很多门店一天的接单量在几十单上下但派单还在靠微信群吼阿姨的档期靠记忆结算靠Excel客户再次消费全凭缘分。这种状态撑到三五个人还勉强凑合一旦超过十个阿姨、两个门店立刻开始出错。所以家政行业数字化的关键从来不是上一套高大上的系统而是先打通“获客-服务-复购”这一整条链路。获客解决的是客户怎么找到你、怎么留得住线索服务解决的是派单、上门、验收、结算这些环节怎么不扯皮复购解决的是干完一单之后怎么让客户想起来还有你。我这次整理的这套系统完整覆盖了这三段附带全功能源码和部署文档适合两类人一是想低成本自建系统的家政公司负责人二是想找一套真实业务案例做二次开发的程序员。下面我把需求拆解、功能设计、技术选型、部署过程和踩坑记录全部摊开讲。2. 家政公司的真实痛点拆解获客、服务、复购各烂在哪里2.1 获客环节客户来了但没被接住家政公司的获客渠道其实不少大众点评、本地生活平台、老客转介绍、小区微信群、甚至楼下的传单。问题不出在渠道而出在响应和登记。客户从平台打电话过来咨询前台手忙脚乱记一个手机号然后靠微信语音确认需求整个过程没有任何结构化记录。客户问“明天下午有没有阿姨”前台只能挨个问阿姨回复周期长客户感觉你不专业扭头就去别家。在系统里获客段要解决的事就三件客户留资要自动沉淀、需求要标准化记录、跟进状态要可视化。比如客户在小程序里选择“日常保洁”“擦窗”“钟点工”等服务类目勾选面积、时间、地址提交后直接生成一条线索记录销售或前台在后台看到新线索后可以在线报价、在线预约每一个动作都有时间戳。谁跟进的、跟到哪一步了、为什么没成交全链路可追溯。2.2 服务环节排单靠吼、结算靠算、验收靠问服务环节是家政行业最混乱的地方我见过最典型的场景是早上一开门店长拿着手机一边看微信群一边打电话两个阿姨临时请假订单堆在那儿没人去客户抱怨电话响个不停。阿姨上门后干了几个小时客户觉得没干干净双方各说各话。这里系统要解决的核心是四个闭环排单闭环哪个阿姨、哪个时段、去哪个地址、履约闭环上门签到、服务完成确认、质量闭环客户验收评价、拍照留底、结算闭环工时、单价、材料费、佣金自动算清楚。尤其是结算很多家政公司的阿姨工资是按订单类型和工时抽成的手算极容易吵架。系统里把服务单和结算单分开订单完成后自动生成结算数据月底一键汇总导出老板和阿姨都省心。2.3 复购环节干完一单就断了线这是整个链路里最可惜的一段。家政服务是典型的高频刚需一次保洁做得好客户下个月大概率还要找你。但大部分门店干完一单就结束了客户联系方式躺在手机通讯录里没有回访、没有会员体系、没有二次触达。等到客户想起来要保洁可能已经在别家买了套餐。复购在系统里需要三个抓手回访任务、优惠券/套餐、老带新。回访任务在订单完成后自动生成提示客服三天内电话或微信回访一次了解服务质量回访结果记录在客户档案里下次派单时可以特别标注偏好。优惠券则是在客户完成首次服务后自动发放比如“下次立减20元”把客户再次下单的概率拉高。套餐卡更是家政行业复购的法宝卖的是“10次保洁卡”“季卡8次”客户先付钱后面自然会持续消耗。3. 从业务链路到功能落地这张订单生命周期表是核心3.1 一张订单串起所有角色我在设计这套系统时没有按“客户管理”“订单管理”“员工管理”这种传统模块去堆功能而是以订单生命周期为主线。一个订单从头到尾经历的状态是待报价 → 已预约 → 已派单 → 服务中 → 已完成 → 已回访 → 可能复购。每个状态都牵涉到不同角色的动作整个系统的逻辑都围绕这张流转表展开。订单核心表的设计建议这样拆主订单表(order)记录客户、服务类型、地址、金额、状态、预约时间。工单表(order_task)一个订单可能包含多项服务比如“日常保洁擦窗”每项服务对应一张工单。派单记录(order_dispatch)派给哪个阿姨、谁派的、几点派的、阿姨是否接单。验收记录(order_acceptance)客户确认完成时间、评价等级、问题描述。回访记录(revisit_record)回访人、回访方式、客户反馈、是否产生复购意向。这样设计的最大好处是任何一笔订单出了问题你都能回答“客户是谁、谁接的、谁干的、干得怎么样、有没有回访”。而在后续开发中每个模块只是在这张主线上挂不同的操作按钮而已。3.2 获客端的落地形态小程序线索池获客端我选择做微信小程序后台线索池的组合。小程序承担的事很简单服务展示、在线预约、优惠券领取、我的订单。用户不需要下载App扫个码或者搜一下就能用转化路径很短。小程序端我特别建议做这几个功能首页服务分类日常保洁、深度保洁、擦窗、家电清洗、保姆月嫂等每类服务有定价参考和预计时长。立即预约表单填地址、选时间、补充备注比如“家里有猫”“需要自带工具”提交后直接进线索池。优惠券中心新客礼包、分享得券把社交裂变放进产品里。后台的线索池则给门店使用新线索自动带出客户手机号、预约需求、来源渠道销售可以在线报价、标记跟进状态超过24小时未跟进的线索自动变红提醒。这一套下来获客不再是“前台靠脑子记”而是从第一条线索开始就进入可管理的流程。3.3 服务端落地阿姨端App/小程序 日历排班服务端我拆成两个视角店长端和阿姨端。店长端看到的是日历视图每一天每一时段哪些阿姨有空、哪些订单已派单、哪些还在待派单一目了然。派单方式支持手动指派和抢单两种手动指派适合老客户指定阿姨抢单适合新客户临时需求。阿姨端则是一套独立的操作界面主要功能包括查看今日任务按时间排列当天所有服务订单显示地址、客户电话、服务要求。上门打卡到客户楼下时点击“开始服务”离开时点击“完成服务”记录服务时长防止工时扯皮。服务结果登记完成情况、客户是否有额外要求、是否需要下次回访阿姨可以直接填写。我的收入每笔订单的抽成、实时累计、按月结算单。这里有一个细节值得说明为什么不直接给阿姨开后台账号因为阿姨群体普遍不习惯操作复杂系统界面必须足够简单操作步骤越少越好。我甚至建议把阿姨端做成一个专门的轻量小程序入口固定在聊天窗口顶部打开就直接是“今天的活儿”不需要登录跳转。4. 系统技术选型为什么是 Spring Boot Vue3 MySQL 这套组合4.1 面向交付型项目的选型逻辑源码交付型项目最怕的是什么是别人拿到源码后部署不起来、找不到人维护。所以我在这套系统里选了最稳妥的路线后端Spring Boot前端Vue3数据库MySQL小程序端uni-app。这个组合不酷但胜在生态成熟、资料多、招人容易。做个简单对比你就明白我为什么这么选技术栈优点缺点适用场景Spring Boot Vue生态成熟、部署简单、Java程序员多资源占用略高、启动稍慢中小型SaaS、企业内部系统PHPLaravel/ThinkPHP上手快、虚拟主机可跑、成本低高并发能力弱、规范参差极小型门店单机部署Go Vue性能强、部署产物单一招聘难度大、不适合纯业务快速迭代高并发平台型产品PythonDjango/Flask开发快、AI集成方便部署环境较麻烦、性能中规中矩原型验证、算法类系统家政系统属于典型的“业务逻辑重、并发压力不极端”的场景Spring Boot 的模块化开发方式非常适合而且用它做权限体系、定时任务、微信支付对接都特别方便。4.2 源码目录结构导航拿到源码后别急着跑先看目录结构。整个工程我分成三大块home-service-system/ ├── backend/ # 后端 Spring Boot 工程 │ ├── src/main/java/com/homeservice/ │ │ ├── controller/ # 接口层订单、客户、阿姨、优惠券、回访 │ │ ├── service/ # 业务逻辑层 │ │ ├── mapper/ # MyBatis-Plus 数据访问层 │ │ ├── entity/ # 数据库实体 │ │ ├── config/ # 拦截器、跨域、定时任务配置 │ │ └── utils/ # 工具类日期、金额、微信请求 │ ├── src/main/resources/ │ │ ├── mapper/ # SQL 映射文件 │ │ └── application.yml # 数据库、Redis、支付等配置 │ └── sql/ # 初始化脚本建库建表 ├── web-admin/ # 管理后台前端 Vue3 工程 │ ├── src/views/ │ │ ├── order/ # 订单管理页面 │ │ ├── customer/ # 客户管理页面 │ │ ├── worker/ # 阿姨管理页面 │ │ ├── marketing/ # 优惠券、套餐、回访页面 │ │ └── finance/ # 结算与财务报表页面 │ └── .env.production # 生产环境 API 地址配置 └── miniapp/ # 客户小程序/阿姨小程序 uni-app 工程后台管理端是整个系统的操作中枢所有业务配置都在这里完成包括服务项定价、阿姨入职信息、订单调度、优惠券发放、财务结算。小程序端只做客户端操作逻辑尽量薄把复杂判断都放后端这样后续换客户端框架也不伤筋动骨。4.3 数据库表的几个关键关联整个库我拆了三十多张表但核心关系就几条线理解了这几条线二次开发就不会迷路客户线user(客户表) → customer_address(地址表) → order(订单表)一个客户可以有多个地址一个地址可产生多笔订单。员工线worker(阿姨表) → worker_skill(技能表) → order_dispatch(派单记录)阿姨和技能是多对多订单通过派单记录关联阿姨。营销线coupon_template(券模板) → user_coupon(用户券) → order(使用记录)优惠券的发放、领取、核销都在这一条线上。资金线order → settlement_detail(结算明细) → withdraw_record(提现记录)订单完成后自动生成阿姨结算单。这几个核心表和关联关系是系统的骨架建议二次开发之前先把这几张表画清楚再去动代码能少走很多弯路。5. 部署之路从一台空服务器到正式接单要跨过哪些坎5.1 部署前必须准备的东西我先把话放前面不要一上来就买高配服务器这套系统在业务初期一台2核4G的云服务器就已经够跑。真正要提前确认的是下面几项一台Linux服务器CentOS 7/Ubuntu 20.04以上均可一个已完成备案和解析的域名SSL证书HTTPS必须否则小程序和微信支付都会出问题MySQL 8.0、Redis 6.x、JDK 11、Nginx 1.20微信小程序AppID与AppSecret客户端和阿姨端各一个微信支付商户号如果要做在线支付环境版本一定要对齐不要图省事装个MySQL 5.7就跑初始化脚本编码和行为差异会带来很多奇怪的坑。我建议用Docker Compose把MySQL、Redis、Java应用一起编排起来升级回滚都方便。部署文档里我默认提供的是传统安装方式更通用但你自己用的时候Docker会是更省心的选择。5.2 后端启动和配置里的关键点后端拿到手后第一步是导入初始化SQL第二步是改配置文件application.yml。这里要改的东西看似多实际就三类数据源、Redis地址、微信支付参数。一个最常见的坑是数据库连接参数里的useUnicodetruecharacterEncodingutf8mb4不写全导致中文写入变乱码。初始化脚本里所有表的字符集我都统一指定为了utf8mb4部署时数据库连接串必须配套否则客户姓名和备注会直接变成“???”这种问题排查起来最浪费时间。另一个容易忽略的是定时任务默认开关。系统里有两个定时任务一个是每天凌晨自动结算阿姨工资抽成另一个是订单完成三天后自动生成回访任务。这两个任务在application.yml里分别有开关默认是开启状态。如果关了月底发现阿姨工资没算出来业务就崩了。部署完一定要检查这两项是enable: true。5.3 前端打包与Nginx反向代理配置管理后台Vue3项目打包前要改.env.production里的API地址指向你的后端域名比如https://api.yourdomain.com。打包命令就一条npm install npm run build构建产物在dist/目录把里面的文件放到Nginx的html目录下再配一个反向代理把/api开头的请求转发给后端的8080端口。Nginx配置大致长这样server { listen 443 ssl; server_name admin.yourdomain.com; ssl_certificate /etc/nginx/cert/yourdomain.pem; ssl_certificate_key /etc/nginx/cert/yourdomain.key; root /usr/share/nginx/html/dist; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }小程序端则需要在manifest.json里填上小程序的AppID然后在工具里导入项目修改utils/request.js中的baseURL为后端域名。这里要特别注意小程序请求的域名必须在小程序管理后台配置到白名单里而且要下载校验文件放到Nginx目录下不然开发工具里调不通接口。5.4 全链路验证清单部署完成后绝对不能只看看登录页就完事。我建议按下面的清单跑一遍确认所有状态流转正常在小程序端注册一个新用户提交一个保洁预约订单。在管理后台看到新线索标记跟进并报价。为订单指派一个阿姨在阿姨端小程序看到任务。模拟阿姨点击“开始服务”再点击“完成服务”。在管理后台将订单标记为完成验证优惠券是否自动发放。三天后在回访列表看到自动生成的回访任务点击完成并记录反馈。在结算页面确认该订单对应的阿姨佣金已生成。用另一个手机号走一遍“分享得券”的链路验证老带新逻辑。这套流程走通了系统就算真正能接业务了再往后的工作重心就该放到运营和使用习惯培养上。6. 上线后那些部署文档没写、但一定会踩的坑6.1 图片上传以后显示不出来的域名坑系统里客户头像、服务完成照片都走的是文件上传接口本地联调时存本地路径没问题一旦部署到服务器前端访问图片的域名如果和后端存储域名不一致图片就会裂掉。我的处理方式是把上传文件统一存到服务器/data/upload目录然后Nginx单独配一个/upload/静态资源路径前后端域名分开反而更清晰但需要在代码里把资源地址拼成绝对路径。6.2 微信支付回调的本地联调难题微信支付部署到测试环境时回调地址必须是公网能访问的HTTPS地址。很多人在本地开发时直接用内网穿透工具把回调地址映射到本机这在安全上是很不推荐的而且微信支付官方对频繁变更回调域名有风控。我的建议是微信支付相关功能直接在正式的测试服务器上联调本地只做业务逻辑的单元测试不要图快在本地接支付。6.3 回访定时任务的时间差订单完成后“三天回访”这个功能实现时用了一个简单的cron表达式每天跑一次扫描所有“已完成且回访时间未生成”的订单。理论上没问题但如果你在下午部署并导入了历史订单数据回访任务会在当晚或者第二天才批量生成客户等不到回访电话体验就差。部署后第一次上线建议手动执行一次回访生成接口把存量订单的回访任务一次性补齐。6.4 多店共享阿姨池的并发冲突如果后续业务扩张到两个门店你会遇到同一个阿姨被两家店同时派单的问题。这套系统在派单功能里做了简单的冲突校验同一天同一个时段阿姨只能有一个已接单任务。但校验的粒度是“天时段”如果客户下单时有跨天服务或临时加钟还是可能出现碰撞。所以我建议派单冲突校验不能只靠代码还要靠门店的排班纪律至少在系统里把阿姨的可接单状态显眼地展示出来让店长肉眼可见。6.5 定期备份要纳入日常运维家政系统的数据是极其敏感且不能丢的客户电话、家庭住址、服务记录丢了不是钱的问题是信任崩塌的问题。部署完成后第一件事就是配MySQL自动备份每天凌晨导出一次SQL文件异地保存到对象存储至少保留三十天。不要觉得前期单量少就不备份等到要恢复数据那天你会后悔为什么没早点配。7. 写在最后这套源码之外我的一点经验之谈家政行业的数字化不是一个工程问题而是一个管理习惯问题。系统做出来了源码交付了部署跑通了真正的挑战才刚刚开始——阿姨是不是真愿意打卡店长是不是真会在系统里标记跟进老板是不是真愿意每天花五分钟看报表。我见过不少项目功能做得非常全最后死在没人用上。所以如果你准备在自己门店推进这套系统我的建议很直接先挑一个店、一条业务线跑起来用制度强制要求订单必须走系统其他环节哪怕先用纸质辅助都行等大家用顺手了再逐步把财务、回访这些模块彻底切进去。工具的价值是在使用中长出来的不是在购买时生效的。我在这套系统里把“获客-服务-复购”三条链路全都做了实例化实现从源码结构到部署文档再到上线后可能遇到的实际问题都尽可能写清楚了。后续你动手改造的时候有任何卡住的地方欢迎来交流。毕竟家政数字化这条路一个人走得慢一群人走得远。