我是做PHP开发接外包的前前后后做了不少管理系统但家政公司订单管理系统算是比较有代表性的一类。上半年一个开家政公司的朋友找上我说想搞一套系统要求不高能录订单、能派单、月底能把阿姨工资算明白。我一开始觉得这种小系统一星期就能搞定真上手才发现业务逻辑比代码复杂得多。今天把这套“家政公司订单管理系统”的源码和设计思路完整分享出来适合三类人看一是中小家政公司的老板或运营负责人想低成本搭建自己的业务系统二是刚入行的PHP开发者想找一个业务完整、能二次开发的练手项目三是接外包的自由职业者可以拿这套系统的架构当模板快速改造成其他“预约派单结算”类项目。整套源码基于PHPMySQL原生开发部署到宝塔面板就能直接跑核心功能包括订单全流程管理、客户沉淀、阿姨排班派单、工资自动结算和数据看板完全覆盖中小家政公司日常运营的刚需。1. 项目概述与核心痛点1.1 为什么中小家政公司最需要一套订单管理系统做这套系统之前我专门陪朋友跑了两天一线业务。他在一个二线城市开了家政公司也就是俗称的“中介自营”模式旗下不到20个阿姨每天订单量在30到60单之间。当时他用的工具是Excel加微信群客服把订单抄在表格里群里喊一嗓子让阿姨认领临时改时间就靠着打电话反复沟通月底算工资要熬两个通宵。这种模式在订单量50单以内还能勉强撑住一旦过了这个数字问题就集中爆发。我梳理了一下他遇到的痛点其实非常有代表性订单状态完全靠脑袋记。客户约了明天下午三点擦玻璃阿姨到底接没接、有没有迟到、做完没有客服要挨个打电话问问完再手动改Excel。客户资料散落在各人微信里。哪个客户做过几次保洁、家里有没有宠物、门禁密码是多少、对哪个阿姨不满意全部凭客服个人记忆人一离职客户也跟着流失。排单没有章法。阿姨的技能不一样有的专做深度保洁有的只会擦玻璃但派单基本靠“谁离得近谁去”经常出现阿姨跑大半个城市服务一单、另一单在隔壁小区却没人接的情况。工资结算靠手工。保洁按单算提成月嫂按月薪算临时工按时薪算三种计薪方式混在一起月底算错一次就要跟阿姨解释半天。这些痛点单独看都不大但叠在一起几乎每天都要消耗管理者的精力。市面上的SaaS家政软件功能确实全但一年授权费少则几千、多则上万很多中小老板接受不了。免费的开源方案又普遍年久失修界面老旧字段跟实际业务对不上。我当时的判断是与其买一套“大而全”的软件回来还要员工适应它的流程不如做一套贴合自己业务的小系统。1.2 技术选型为什么是PHPMySQL而不是Java或Python技术选型是所有做系统的人最纠结的一步。我给这个项目定方案时几乎没有犹豫就选了PHPMySQL理由也很实在部署门槛必须低。家政公司老板绝大多数不是技术出身最多能按教程在宝塔面板上点几下。PHP的LNMP环境一键就能搭起来虚拟主机也能跑几乎不存在环境障碍。如果选Java或Python光是装JDK、配环境变量、装依赖就能劝退一半用户。开发效率足够快。这套系统从立项到能用的版本我写了大概十天。PHP不需要编译改完代码刷新就能生效配合原生SQL写业务逻辑非常直接。对于一个日订单量几十上百的项目完全不需要引入复杂的微服务架构。持有成本几乎为零。全套技术栈都是开源的PHP、MySQL、前端LayUI框架没有授权费用部署在自己服务器上除了服务器租金没有任何额外支出。后续维护不挑人。PHP程序员在市场上多得像米一样将来公司想加功能随便找一个PHP开发就能接手。要是用了冷门技术栈源码烂在自己手里没人看得懂才是最尴尬的。有朋友可能会问用Java做是不是更“正规”如果公司规模很大需要多端实时同步、复杂权限体系、上万级并发那确实应该上Java或Go。但中小家政公司一天就几十上百个订单MySQL单表在千万级数据量以下性能完全没问题。技术选型最忌讳的就是“盲目追重”杀鸡用牛刀只会给自己增加运维负担。1.3 这套系统具体能解决什么从使用端来看这套系统落地之后朋友的业务发生了几个立竿见影的变化订单状态全流程可视化。从客户打电话进来创建订单到派单、接单、服务中、完成、回访每一步都在系统里有明确状态。客服再也不用靠微信聊天记录回忆订单进度。派单效率大幅提升。系统根据阿姨的服务技能标签和当天已接单量自动推荐合适的人选坐席一键派单阿姨在系统里就能看到属于自己的新订单不用在群里翻聊天记录。工资从半天缩短到一分钟。月底点击“生成工资单”系统自动汇总当月已完成的订单提成、底薪和罚款生成工资表。朋友说这是他最满意的一个功能省下的时间够他多跑两趟业务。客户资产沉淀下来。每个客户的服务记录、偏好、地址、备注全部存在系统里即使客服换人新客服打开客户列表就能完整了解历史不会因为人员流动丢掉客户。2. 系统架构与数据库设计2.1 整体架构和目录结构系统采用经典的B/S架构浏览器直接访问服务端渲染为主。前端用的是LayUI框架加jQuery图表部分接了Echarts后端是PHP原生代码按简单的MVC分层写的没有引入重量级框架这样做的目的是方便二次开发——懂一点PHP的人都能看懂不用先学一套框架规范。接口层面我预留了JSON格式的REST风格API地址在api/目录下以后想接微信小程序或者APP直接复用这一层接口就行不需要把后台的HTML页面逻辑硬塞给移动端。目录结构是这样的├── admin/ # 后台管理模块 │ ├── controller/ # 控制器层接收请求、调用模型 │ ├── model/ # 数据模型层封装SQL操作 │ ├── view/ # 视图模板层HTML页面 │ └── common/ # 公共函数、配置文件 ├── api/ # API接口模块输出JSON ├── static/ # 静态资源 CSS/JS/图片 ├── upload/ # 用户上传文件目录 ├── install/ # 安装向导自动建表 └── index.php # 入口文件我特意把install/目录做成一个可视化安装向导用户上传源码后访问一次系统自动创建数据库表并写入初始配置。这样即使不懂技术的使用者也能独立完成部署不需要手动去执行SQL文件。2.2 核心数据表逐张拆解数据库我一共设计了9张表基本覆盖了家政公司日常经营的所有核心数据。下面一张一张说这些表的结构直接决定了业务逻辑怎么写。用户表user存系统登录账号字段包括用户名、密码、姓名、手机号、角色、状态。角色分为三类管理员、坐席、服务人员。密码用加密方式存储我开发时用的是MD5加盐生产环境建议换成PHP的password_hash()函数更安全。客户表customer客户是家政公司最重要的资产所以这张表字段比较细。除了姓名、电话、地址我还加了小区名称、经纬度、来源渠道、备注四个字段。小区名称配合经纬度是为了将来做“就近派单”来源渠道用来统计获客效果备注则记录“家有两猫”“门禁密码后六位”这样的特殊信息。这些细节看起来不起眼实际用起来非常方便。服务项目表service_item家政公司卖的其实是具体的服务产品而不是笼统的“家政服务”。这张表定义SKU服务名称、标准单价、标准时长、计价单位、提成方式、提成比例。比如“日常保洁”单价120元按次计价提成方式为按单提成40%“月嫂”按月计价提成可能是固定的。把提成规则挂在服务项目上而不是统一用一个比例这样才能灵活应对不同业务的利润空间。服务人员表staff管理阿姨和师傅的基本信息姓名、电话、身份证号、服务技能标签、工作状态、入职日期、底薪、客户评分。技能标签我用JSON格式存储比如[日常保洁,擦玻璃]这样在派单页面就能用标签快速筛选出能接对应服务的人。工作状态分为在线、休假、离职排单时自动过滤掉不可用人员。订单表orders这是系统的核心表。订单编号、客户ID、服务项目ID、服务人员ID、订单状态、预约服务时间、服务地址、实际金额、提成金额、备注、创建时间、完成时间。订单状态我定义了一个流转状态机待接单、待服务、服务中、已完成、已取消、待售后。每一步的流转在代码里都做了校验不允许从“已完成”直接跳回“待接单”这种非法操作避免数据错乱。工资结算表salary月底结算就靠这张表服务人员ID、结算周期、底薪、提成总额、奖金、罚款、实发工资、是否已结算。系统按月份汇总订单表中的提成金额加底薪、扣罚款生成一条工资记录。这里要特别注意结算过的记录要锁定不能因为后续改单导致历史工资被篡改。售后回访表after_sale订单完成后自动生成一条待回访记录客服跟进后填写满意度、回访内容、回访时间、回访人。家政行业的复购率很大程度上取决于售后体验有了这张表管理者可以直观看到每个客户的满意度趋势也能找出评分低的阿姨进行针对性培训。操作日志表operate_log记录谁在什么时间做了什么操作包括操作人、动作类型、关联订单ID、操作内容、IP地址、创建时间。当初第一版系统没有这张表朋友跑了几天后说“系统没问题”结果一个客户投诉阿姨放鸽子两边各执一词谁改的订单都查不到。加上操作日志后所有关键操作都有据可查管理纠纷时底气足很多。系统配置表config键值对结构存放公司名称、客服电话、佣金默认比例、收款码图片路径等全局配置。把这类数据从代码里抽出来放到数据库以后改配置不用动代码直接在系统设置页面操作就行。2.3 数据库设计踩过的坑数据库设计是整个系统里我最想分享经验的部分因为真的踩了不止一个坑。第一个坑是差点用FLOAT存金额。开始时图省事金额字段全部用FLOAT跑了一段时间发现工资对不上——FLOAT在累加时会丢失精度一毛钱可能变成九分钱阿姨的眼睛可是雪亮的。后来全部改成DECIMAL(10,2)问题彻底解决。记住一句话凡是涉及钱的字段一律用定点数不要用浮点数。第二个坑是订单号用了自增ID。第一版订单表主键直接当订单号显示后来发现两个问题一是客户能根据订单号推断出公司的业务量二是多表联查时自增ID语义不清晰。我改成JD年月日三位随机数的格式比如JD20250101001既有辨识度也避免订单号暴露内部数据。第三个坑是忘了设计软删除。一开始删除客户直接DELETE后来发现删除操作会把历史订单的关联关系一起搞丢。现在所有关键表都加了status字段删除只是标记状态数据仍然保留报表统计和追溯都是完整的。3. 核心功能模块的实现细节3.1 登录与三层权限控制系统的登录模块没有做什么花哨的东西就是最经典的Session会话控制。登录成功之后把用户ID和角色写进SESSION然后写一个权限校验的中间件函数在每个控制器开头调用。// 权限校验中间件 function checkAuth($allowedRoles) { session_start(); if (!isset($_SESSION[user_id])) { header(Location: /login.php); exit; } if (!in_array($_SESSION[role], $allowedRoles)) { die(无权访问该页面); } }调用方式很直接在订单管理控制器里写checkAuth([1,2])就表示只有管理员和坐席能访问这个页面在工资结算控制器里写checkAuth([1])就只有管理员能进去。阿姨登录后只能看到自己的订单列表和工资明细连客户电话都看不了避免阿姨绕过公司直接跟客户私单。3.2 订单全生命周期管理订单是这套系统的心脏。我在设计订单状态流转时专门画了一张状态图代码里用常量定义1 待接单客服刚录入还没有派给阿姨2 待服务已经派单阿姨确认接单3 服务中阿姨到达客户家点击开始服务4 已完成服务结束系统自动算提成5 已取消客户或公司主动取消6 待售后服务完成后自动进入回访流程每次状态变更都统一走orderStatusChange()函数这个函数会做三件事校验当前状态是否可以过渡到目标状态更新订单表状态字段把操作记录写入操作日志。以“派单”为例// 派单动作 public function assignOrder($orderId, $staffId) { $order $this-find($orderId); if ($order[order_status] ! 1) { throw new Exception(当前状态不能派单); } // 绑定阿姨状态改为待服务 $this-update($orderId, [ staff_id $staffId, order_status 2 ]); // 写操作日志 $this-log($orderId, 派单, 指派给 {$staffId}); }这里的状态校验非常关键。我一开始没有做严格校验结果测试阶段自己手滑把一条“已完成”的订单误改成“待接单”搞得统计数字乱了半天。后来把所有非法状态跳转全堵死代码里还加了提示“当前状态不支持该操作”。3.3 派单与排班推荐逻辑派单是家政公司管理者每天最头疼的事。我的设计思路不是做全自动派单而是“人工决策为主系统推荐为辅”。坐席在派单页点击“推荐阿姨”后系统按四步过滤按订单的服务项目匹配阿姨的skill_tags技能标签过滤掉工作状态不是“在线”的阿姨按当天已完成和待服务的订单数量升序排列避免某些阿姨被过度派单如果客户地址录入了经纬度再按距离由近到远排序这四步过滤完页面上会展示一个推荐列表每行显示阿姨名字、技能标签、当天单量、距离坐席可以一键指派。同时我保留了一个“手动指定”入口因为真实业务里客户经常会点名要某个阿姨这种需求系统不应当阻止。推荐算法不复杂但胜在实用。朋友用了之后跟我说以前一早上要花两个小时打电话协调阿姨现在十分钟就排完了因为系统把“谁有空、谁能干、谁最近”一次性算清楚了。3.4 工资自动结算模块工资模块算是这套系统里技术含量不高但业务价值最大的功能。家政行业工资结构复杂保洁是按单提成保姆是固定月薪临时开荒是按时薪算还有各种罚款和奖金。如果纯靠Excel月底真的能算到怀疑人生。我的解决方案是给每个服务项目设置独立的提成规则工资计算时按订单逐条汇总SELECT staff_id, SUM(commission_amount) AS total_commission FROM orders WHERE order_status 4 AND finish_time BETWEEN 2025-01-01 AND 2025-01-31 23:59:59 GROUP BY staff_id;这条SQL语音把当月所有已完成订单的提成按阿姨汇总。后台再把底薪、奖金、罚款加加减减生成工资记录。这里有一个细节提成金额不是订单生成时就算死的而是在订单状态变成“已完成”的那一刻计算并写入订单表。这样做的好处是如果客户临时增加服务时长导致实际金额变化提成也能跟着变。工资生成之后我加了一个“锁定”按钮一旦确认结算工资单就不能再被修改。这样既防止人为篡改也给财务审计留了底。3.5 数据看板与统计系统首页是一个数据看板用Echarts画了四张图订单趋势折线图、阿姨产值柱状图、客户来源分布饼图、订单状态漏斗图。顶部还有四个核心指标卡今日订单数、今日营收、待派单数量、本周回访完成率。这个看板花的时间不多但朋友反馈说以前他都是凭感觉判断公司经营状况现在每天早上看一眼就知道昨天接了多少单、哪个阿姨工作量最饱和、哪个获客渠道带来的客户最多。有一段时间他发现某个渠道的客户转化率特别低一查发现是客服录入渠道时选错了调整之后数据才准确。4. 安装部署实战4.1 环境要求部署这套系统最简单的方案是宝塔面板。环境要求如下PHP 7.0推荐7.4或8.0版本MySQL 5.7推荐MySQL 8.0Nginx或Apache均可宝塔默认Nginx服务器内存1G以上足够日订单几百单完全没问题4.2 宝塔面板部署完整步骤第一步把源码压缩包上传到服务器网站根目录解压。我用的是/www/wwwroot/jiazheng这个路径名称可以自己定。第二步在宝塔面板创建一个MySQL数据库记住数据库名、用户名、密码。然后用phpMyAdmin导入源码install/目录下的database.sql文件这个文件会自动创建全部9张表并插入初始数据。第三步修改admin/common/config.php里的数据库连接信息把数据库名、端口、用户名、密码换成你自己的。return [ db_host 127.0.0.1, db_port 3306, db_name jiazheng_db, db_user jiazheng_admin, db_pass 你的密码, db_charset utf8mb4 ];第四步配置伪静态。如果用的Nginx在站点设置里加上ThinkPHP风格的伪静态规则保证URL能正常跳转。Apache一般不用额外配置。第五步访问http://你的域名/index.php进入安装向导按提示完成安装。安装完成后系统会引导你删除install/目录防止脚本被恶意重放。默认后台登录地址是http://你的域名/admin/初始账号admin密码123456。登录后第一件事就是修改密码并把管理员手机号绑定上。4.3 部署后的检查清单部署完成后不要急着录数据先把这几项检查一遍数据库字符集是不是utf8mb4。如果建库时不小心选了utf8录入客户备注里的emoji表情会变成乱码。upload/目录权限是否可写。如果上传图片提示失败多半是目录权限不对chmod 755 upload/即可。后台所有菜单能否正常点击。重点测试订单状态从“待接单”流转到“已完成”整条链路看操作日志有没有记录。修改config.php里的默认密钥改成一段随机的字符串提高Session安全性。5. 常见问题排查与避坑指南5.1 典型问题速查表我整理了一份部署和使用过程中最常遇到的几个问题方便大家对照排查问题原因解决方案安装时数据库连接失败数据库密码错误或账号没有授权检查config.php配置在宝塔里给数据库用户授权所有权限页面乱码字符集不是utf8mb4统一改数据库、数据表、PHP连接三个层面的字符集登录后跳回登录页SESSION没有正常开启检查PHP的session配置确认站点根目录可写订单状态无法流转状态机校验拦截了非法操作看操作日志确认当前状态走正确的流转路径工资计算结果不对服务项目的提成比例没有配置对检查service_item表的commission_rate和commission_type字段图片上传失败upload目录没有写权限给upload目录设置755权限PHP用户组要可写页面报500错误PHP版本不兼容或扩展缺失切换PHP版本到7.4/8.0打开PHP错误日志定位5.2 几个容易忽略的细节有几个细节是常规文档不会写的但实际运营中非常重要第一一定要把操作日志表的数据定期备份。家政公司的“客诉纠纷”很多时候靠日志还原事实日志丢失等于没有证据。我建议宝塔面板里设置每天自动备份数据库保存最近30天。第二客户备注功能要规范使用。有的坐席会把“客户脾气差”“客户喜欢砍价”这种主观评价写进去容易引发矛盾。我在系统里加了一个提示“备注请填写客观信息如门禁密码、宠物情况、服务偏好”。主观评价应该走回访表而不是写给全员看。第三阿姨状态要及时维护。如果阿姨请假了但系统里还显示“在线”派单系统会把她推荐出去导致客户下单后没人接。最好指定一个坐席每天早晚各检查一次阿姨的工作状态。6. 二次开发与扩展方向6.1 从家政系统改造成其他预约型业务这套系统最有价值的不是那几张表而是“预约派单结算”的业务模型。把服务项目表、服务人员表、订单表改一改字段就能快速改造成维修预约系统、宠物寄养系统、车辆保养预约系统、上门安装服务系统。我接外包的时候经常用这套架构当底座改个皮肤和字段就能交付一个新项目开发成本能省一半。更换行业的改造重点不在代码而在业务规则维修行业要加“故障描述”“配件成本”字段宠物寄养要加“宠物类型”“体重”“疫苗接种信息”车辆保养要加“车辆型号”“保养里程”“配件清单”这些都是在订单表、客户表上扩展字段的事表结构不变核心逻辑不动。6.2 推荐的功能增强路径如果你打算拿这套源码继续扩展我建议按以下顺序来性价比最高接入消息通知。在订单状态变化时调用阿里云短信接口或企业微信机器人通知相关角色让阿姨不用一直盯着系统。这一步是现代家政服务体验的关键。对接微信小程序。系统api/目录的接口已经就绪小程序端只需实现登录、查看订单、接单、开始/完成服务四个页面就能让阿姨完全脱离PC端。增加地图调度。派单页接入高德地图JS API在地图上直接显示客户点和正在服务中的阿姨位置实现“就近派单”。配合客户表的经纬度字段这步改造基本是顺水推舟。上线数据导出。增加“导出Excel”按钮把订单表、工资表一键导出方便财务对账和老板做汇报。加一层缓存。当订单量增长到日单量几百以后看板查询会变慢可以用Redis缓存热门统计接口或者给订单表按月分区。还有一点源码里的安装向导是通用的如果别人拿这套源码来部署建议把安装后的默认管理员账号改成随机生成的密码并发到对方手机上避免默认密码被人利用。这是个很小的动作但能省掉很多安全上的麻烦。我实际开发完这套系统之后最大的感受是小系统的难点从来不在技术而在于把业务逻辑想透。你花三天梳理业务流程代码可能一天就写完了反过来业务没想清楚就急着写代码写完也要推翻重来。这套源码我打包好了需要的朋友在文章下留言我看到后会发给你。源码是免费的但希望你在使用的过程中能把踩到的坑和改出来的经验也分享出来让这套系统越来越完善。