1. 先說實話家政公司缺的不是訂單而是把訂單管明白的工具我在幫家政公司做系統(tǒng)選型和落地這件事上接觸過不下幾十位老板和店長。聊到最后幾乎都會落到同一個問題上客戶不缺咨詢訂單也不缺缺的是一套能把“客戶從哪來、服務干得怎么樣、下次怎么再來”串起來的工具。很多門店一天的接單量在幾十單上下但派單還在靠微信群吼阿姨的檔期靠記憶結算靠Excel客戶再次消費全憑緣分。這種狀態(tài)撐到三五個人還勉強湊合一旦超過十個阿姨、兩個門店立刻開始出錯。所以家政行業(yè)數字化的關鍵從來不是上一套高大上的系統(tǒng)而是先打通“獲客-服務-復購”這一整條鏈路。獲客解決的是客戶怎么找到你、怎么留得住線索服務解決的是派單、上門、驗收、結算這些環(huán)節(jié)怎么不扯皮復購解決的是干完一單之后怎么讓客戶想起來還有你。我這次整理的這套系統(tǒng)完整覆蓋了這三段附帶全功能源碼和部署文檔適合兩類人一是想低成本自建系統(tǒng)的家政公司負責人二是想找一套真實業(yè)務案例做二次開發(fā)的程序員。下面我把需求拆解、功能設計、技術選型、部署過程和踩坑記錄全部攤開講。2. 家政公司的真實痛點拆解獲客、服務、復購各爛在哪里2.1 獲客環(huán)節(jié)客戶來了但沒被接住家政公司的獲客渠道其實不少大眾點評、本地生活平臺、老客轉介紹、小區(qū)微信群、甚至樓下的傳單。問題不出在渠道而出在響應和登記?？蛻魪钠脚_打電話過來咨詢前臺手忙腳亂記一個手機號然后靠微信語音確認需求整個過程沒有任何結構化記錄?？蛻魡枴懊魈煜挛缬袥]有阿姨”前臺只能挨個問阿姨回復周期長客戶感覺你不專業(yè)扭頭就去別家。在系統(tǒng)里獲客段要解決的事就三件客戶留資要自動沉淀、需求要標準化記錄、跟進狀態(tài)要可視化。比如客戶在小程序里選擇“日常保潔”“擦窗”“鐘點工”等服務類目勾選面積、時間、地址提交后直接生成一條線索記錄銷售或前臺在后臺看到新線索后可以在線報價、在線預約每一個動作都有時間戳。誰跟進的、跟到哪一步了、為什么沒成交全鏈路可追溯。2.2 服務環(huán)節(jié)排單靠吼、結算靠算、驗收靠問服務環(huán)節(jié)是家政行業(yè)最混亂的地方我見過最典型的場景是早上一開門店長拿著手機一邊看微信群一邊打電話兩個阿姨臨時請假訂單堆在那兒沒人去客戶抱怨電話響個不停。阿姨上門后干了幾個小時客戶覺得沒干干凈雙方各說各話。這里系統(tǒng)要解決的核心是四個閉環(huán)排單閉環(huán)哪個阿姨、哪個時段、去哪個地址、履約閉環(huán)上門簽到、服務完成確認、質量閉環(huán)客戶驗收評價、拍照留底、結算閉環(huán)工時、單價、材料費、傭金自動算清楚。尤其是結算很多家政公司的阿姨工資是按訂單類型和工時抽成的手算極容易吵架。系統(tǒng)里把服務單和結算單分開訂單完成后自動生成結算數據月底一鍵匯總導出老板和阿姨都省心。2.3 復購環(huán)節(jié)干完一單就斷了線這是整個鏈路里最可惜的一段。家政服務是典型的高頻剛需一次保潔做得好客戶下個月大概率還要找你。但大部分門店干完一單就結束了客戶聯(lián)系方式躺在手機通訊錄里沒有回訪、沒有會員體系、沒有二次觸達。等到客戶想起來要保潔可能已經在別家買了套餐。復購在系統(tǒng)里需要三個抓手回訪任務、優(yōu)惠券/套餐、老帶新?；卦L任務在訂單完成后自動生成提示客服三天內電話或微信回訪一次了解服務質量回訪結果記錄在客戶檔案里下次派單時可以特別標注偏好。優(yōu)惠券則是在客戶完成首次服務后自動發(fā)放比如“下次立減20元”把客戶再次下單的概率拉高。套餐卡更是家政行業(yè)復購的法寶賣的是“10次保潔卡”“季卡8次”客戶先付錢后面自然會持續(xù)消耗。3. 從業(yè)務鏈路到功能落地這張訂單生命周期表是核心3.1 一張訂單串起所有角色我在設計這套系統(tǒng)時沒有按“客戶管理”“訂單管理”“員工管理”這種傳統(tǒng)模塊去堆功能而是以訂單生命周期為主線。一個訂單從頭到尾經歷的狀態(tài)是待報價 → 已預約 → 已派單 → 服務中 → 已完成 → 已回訪 → 可能復購。每個狀態(tài)都牽涉到不同角色的動作整個系統(tǒng)的邏輯都圍繞這張流轉表展開。訂單核心表的設計建議這樣拆主訂單表(order)記錄客戶、服務類型、地址、金額、狀態(tài)、預約時間。工單表(order_task)一個訂單可能包含多項服務比如“日常保潔擦窗”每項服務對應一張工單。派單記錄(order_dispatch)派給哪個阿姨、誰派的、幾點派的、阿姨是否接單。驗收記錄(order_acceptance)客戶確認完成時間、評價等級、問題描述?；卦L記錄(revisit_record)回訪人、回訪方式、客戶反饋、是否產生復購意向。這樣設計的最大好處是任何一筆訂單出了問題你都能回答“客戶是誰、誰接的、誰干的、干得怎么樣、有沒有回訪”。而在后續(xù)開發(fā)中每個模塊只是在這張主線上掛不同的操作按鈕而已。3.2 獲客端的落地形態(tài)小程序線索池獲客端我選擇做微信小程序后臺線索池的組合。小程序承擔的事很簡單服務展示、在線預約、優(yōu)惠券領取、我的訂單。用戶不需要下載App掃個碼或者搜一下就能用轉化路徑很短。小程序端我特別建議做這幾個功能首頁服務分類日常保潔、深度保潔、擦窗、家電清洗、保姆月嫂等每類服務有定價參考和預計時長。立即預約表單填地址、選時間、補充備注比如“家里有貓”“需要自帶工具”提交后直接進線索池。優(yōu)惠券中心新客禮包、分享得券把社交裂變放進產品里。后臺的線索池則給門店使用新線索自動帶出客戶手機號、預約需求、來源渠道銷售可以在線報價、標記跟進狀態(tài)超過24小時未跟進的線索自動變紅提醒。這一套下來獲客不再是“前臺靠腦子記”而是從第一條線索開始就進入可管理的流程。3.3 服務端落地阿姨端App/小程序 日歷排班服務端我拆成兩個視角店長端和阿姨端。店長端看到的是日歷視圖每一天每一時段哪些阿姨有空、哪些訂單已派單、哪些還在待派單一目了然。派單方式支持手動指派和搶單兩種手動指派適合老客戶指定阿姨搶單適合新客戶臨時需求。阿姨端則是一套獨立的操作界面主要功能包括查看今日任務按時間排列當天所有服務訂單顯示地址、客戶電話、服務要求。上門打卡到客戶樓下時點擊“開始服務”離開時點擊“完成服務”記錄服務時長防止工時扯皮。服務結果登記完成情況、客戶是否有額外要求、是否需要下次回訪阿姨可以直接填寫。我的收入每筆訂單的抽成、實時累計、按月結算單。這里有一個細節(jié)值得說明為什么不直接給阿姨開后臺賬號因為阿姨群體普遍不習慣操作復雜系統(tǒng)界面必須足夠簡單操作步驟越少越好。我甚至建議把阿姨端做成一個專門的輕量小程序入口固定在聊天窗口頂部打開就直接是“今天的活兒”不需要登錄跳轉。4. 系統(tǒng)技術選型為什么是 Spring Boot Vue3 MySQL 這套組合4.1 面向交付型項目的選型邏輯源碼交付型項目最怕的是什么是別人拿到源碼后部署不起來、找不到人維護。所以我在這套系統(tǒng)里選了最穩(wěn)妥的路線后端Spring Boot前端Vue3數據庫MySQL小程序端uni-app。這個組合不酷但勝在生態(tài)成熟、資料多、招人容易。做個簡單對比你就明白我為什么這么選技術棧優(yōu)點缺點適用場景Spring Boot Vue生態(tài)成熟、部署簡單、Java程序員多資源占用略高、啟動稍慢中小型SaaS、企業(yè)內部系統(tǒng)PHPLaravel/ThinkPHP上手快、虛擬主機可跑、成本低高并發(fā)能力弱、規(guī)范參差極小型門店單機部署Go Vue性能強、部署產物單一招聘難度大、不適合純業(yè)務快速迭代高并發(fā)平臺型產品PythonDjango/Flask開發(fā)快、AI集成方便部署環(huán)境較麻煩、性能中規(guī)中矩原型驗證、算法類系統(tǒng)家政系統(tǒng)屬于典型的“業(yè)務邏輯重、并發(fā)壓力不極端”的場景Spring Boot 的模塊化開發(fā)方式非常適合而且用它做權限體系、定時任務、微信支付對接都特別方便。4.2 源碼目錄結構導航拿到源碼后別急著跑先看目錄結構。整個工程我分成三大塊home-service-system/ ├── backend/ # 后端 Spring Boot 工程 │ ├── src/main/java/com/homeservice/ │ │ ├── controller/ # 接口層訂單、客戶、阿姨、優(yōu)惠券、回訪 │ │ ├── service/ # 業(yè)務邏輯層 │ │ ├── mapper/ # MyBatis-Plus 數據訪問層 │ │ ├── entity/ # 數據庫實體 │ │ ├── config/ # 攔截器、跨域、定時任務配置 │ │ └── utils/ # 工具類日期、金額、微信請求 │ ├── src/main/resources/ │ │ ├── mapper/ # SQL 映射文件 │ │ └── application.yml # 數據庫、Redis、支付等配置 │ └── sql/ # 初始化腳本建庫建表 ├── web-admin/ # 管理后臺前端 Vue3 工程 │ ├── src/views/ │ │ ├── order/ # 訂單管理頁面 │ │ ├── customer/ # 客戶管理頁面 │ │ ├── worker/ # 阿姨管理頁面 │ │ ├── marketing/ # 優(yōu)惠券、套餐、回訪頁面 │ │ └── finance/ # 結算與財務報表頁面 │ └── .env.production # 生產環(huán)境 API 地址配置 └── miniapp/ # 客戶小程序/阿姨小程序 uni-app 工程后臺管理端是整個系統(tǒng)的操作中樞所有業(yè)務配置都在這里完成包括服務項定價、阿姨入職信息、訂單調度、優(yōu)惠券發(fā)放、財務結算。小程序端只做客戶端操作邏輯盡量薄把復雜判斷都放后端這樣后續(xù)換客戶端框架也不傷筋動骨。4.3 數據庫表的幾個關鍵關聯(lián)整個庫我拆了三十多張表但核心關系就幾條線理解了這幾條線二次開發(fā)就不會迷路客戶線user(客戶表) → customer_address(地址表) → order(訂單表)一個客戶可以有多個地址一個地址可產生多筆訂單。員工線worker(阿姨表) → worker_skill(技能表) → order_dispatch(派單記錄)阿姨和技能是多對多訂單通過派單記錄關聯(lián)阿姨。營銷線coupon_template(券模板) → user_coupon(用戶券) → order(使用記錄)優(yōu)惠券的發(fā)放、領取、核銷都在這一條線上。資金線order → settlement_detail(結算明細) → withdraw_record(提現記錄)訂單完成后自動生成阿姨結算單。這幾個核心表和關聯(lián)關系是系統(tǒng)的骨架建議二次開發(fā)之前先把這幾張表畫清楚再去動代碼能少走很多彎路。5. 部署之路從一臺空服務器到正式接單要跨過哪些坎5.1 部署前必須準備的東西我先把話放前面不要一上來就買高配服務器這套系統(tǒng)在業(yè)務初期一臺2核4G的云服務器就已經夠跑。真正要提前確認的是下面幾項一臺Linux服務器CentOS 7/Ubuntu 20.04以上均可一個已完成備案和解析的域名SSL證書HTTPS必須否則小程序和微信支付都會出問題MySQL 8.0、Redis 6.x、JDK 11、Nginx 1.20微信小程序AppID與AppSecret客戶端和阿姨端各一個微信支付商戶號如果要做在線支付環(huán)境版本一定要對齊不要圖省事裝個MySQL 5.7就跑初始化腳本編碼和行為差異會帶來很多奇怪的坑。我建議用Docker Compose把MySQL、Redis、Java應用一起編排起來升級回滾都方便。部署文檔里我默認提供的是傳統(tǒng)安裝方式更通用但你自己用的時候Docker會是更省心的選擇。5.2 后端啟動和配置里的關鍵點后端拿到手后第一步是導入初始化SQL第二步是改配置文件application.yml。這里要改的東西看似多實際就三類數據源、Redis地址、微信支付參數。一個最常見的坑是數據庫連接參數里的useUnicodetruecharacterEncodingutf8mb4不寫全導致中文寫入變亂碼。初始化腳本里所有表的字符集我都統(tǒng)一指定為了utf8mb4部署時數據庫連接串必須配套否則客戶姓名和備注會直接變成“???”這種問題排查起來最浪費時間。另一個容易忽略的是定時任務默認開關。系統(tǒng)里有兩個定時任務一個是每天凌晨自動結算阿姨工資抽成另一個是訂單完成三天后自動生成回訪任務。這兩個任務在application.yml里分別有開關默認是開啟狀態(tài)。如果關了月底發(fā)現阿姨工資沒算出來業(yè)務就崩了。部署完一定要檢查這兩項是enable: true。5.3 前端打包與Nginx反向代理配置管理后臺Vue3項目打包前要改.env.production里的API地址指向你的后端域名比如https://api.yourdomain.com。打包命令就一條npm install npm run build構建產物在dist/目錄把里面的文件放到Nginx的html目錄下再配一個反向代理把/api開頭的請求轉發(fā)給后端的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目錄下不然開發(fā)工具里調不通接口。5.4 全鏈路驗證清單部署完成后絕對不能只看看登錄頁就完事。我建議按下面的清單跑一遍確認所有狀態(tài)流轉正常在小程序端注冊一個新用戶提交一個保潔預約訂單。在管理后臺看到新線索標記跟進并報價。為訂單指派一個阿姨在阿姨端小程序看到任務。模擬阿姨點擊“開始服務”再點擊“完成服務”。在管理后臺將訂單標記為完成驗證優(yōu)惠券是否自動發(fā)放。三天后在回訪列表看到自動生成的回訪任務點擊完成并記錄反饋。在結算頁面確認該訂單對應的阿姨傭金已生成。用另一個手機號走一遍“分享得券”的鏈路驗證老帶新邏輯。這套流程走通了系統(tǒng)就算真正能接業(yè)務了再往后的工作重心就該放到運營和使用習慣培養(yǎng)上。6. 上線后那些部署文檔沒寫、但一定會踩的坑6.1 圖片上傳以后顯示不出來的域名坑系統(tǒng)里客戶頭像、服務完成照片都走的是文件上傳接口本地聯(lián)調時存本地路徑沒問題一旦部署到服務器前端訪問圖片的域名如果和后端存儲域名不一致圖片就會裂掉。我的處理方式是把上傳文件統(tǒng)一存到服務器/data/upload目錄然后Nginx單獨配一個/upload/靜態(tài)資源路徑前后端域名分開反而更清晰但需要在代碼里把資源地址拼成絕對路徑。6.2 微信支付回調的本地聯(lián)調難題微信支付部署到測試環(huán)境時回調地址必須是公網能訪問的HTTPS地址。很多人在本地開發(fā)時直接用內網穿透工具把回調地址映射到本機這在安全上是很不推薦的而且微信支付官方對頻繁變更回調域名有風控。我的建議是微信支付相關功能直接在正式的測試服務器上聯(lián)調本地只做業(yè)務邏輯的單元測試不要圖快在本地接支付。6.3 回訪定時任務的時間差訂單完成后“三天回訪”這個功能實現時用了一個簡單的cron表達式每天跑一次掃描所有“已完成且回訪時間未生成”的訂單。理論上沒問題但如果你在下午部署并導入了歷史訂單數據回訪任務會在當晚或者第二天才批量生成客戶等不到回訪電話體驗就差。部署后第一次上線建議手動執(zhí)行一次回訪生成接口把存量訂單的回訪任務一次性補齊。6.4 多店共享阿姨池的并發(fā)沖突如果后續(xù)業(yè)務擴張到兩個門店你會遇到同一個阿姨被兩家店同時派單的問題。這套系統(tǒng)在派單功能里做了簡單的沖突校驗同一天同一個時段阿姨只能有一個已接單任務。但校驗的粒度是“天時段”如果客戶下單時有跨天服務或臨時加鐘還是可能出現碰撞。所以我建議派單沖突校驗不能只靠代碼還要靠門店的排班紀律至少在系統(tǒng)里把阿姨的可接單狀態(tài)顯眼地展示出來讓店長肉眼可見。6.5 定期備份要納入日常運維家政系統(tǒng)的數據是極其敏感且不能丟的客戶電話、家庭住址、服務記錄丟了不是錢的問題是信任崩塌的問題。部署完成后第一件事就是配MySQL自動備份每天凌晨導出一次SQL文件異地保存到對象存儲至少保留三十天。不要覺得前期單量少就不備份等到要恢復數據那天你會后悔為什么沒早點配。7. 寫在最后這套源碼之外我的一點經驗之談家政行業(yè)的數字化不是一個工程問題而是一個管理習慣問題。系統(tǒng)做出來了源碼交付了部署跑通了真正的挑戰(zhàn)才剛剛開始——阿姨是不是真愿意打卡店長是不是真會在系統(tǒng)里標記跟進老板是不是真愿意每天花五分鐘看報表。我見過不少項目功能做得非常全最后死在沒人用上。所以如果你準備在自己門店推進這套系統(tǒng)我的建議很直接先挑一個店、一條業(yè)務線跑起來用制度強制要求訂單必須走系統(tǒng)其他環(huán)節(jié)哪怕先用紙質輔助都行等大家用順手了再逐步把財務、回訪這些模塊徹底切進去。工具的價值是在使用中長出來的不是在購買時生效的。我在這套系統(tǒng)里把“獲客-服務-復購”三條鏈路全都做了實例化實現從源碼結構到部署文檔再到上線后可能遇到的實際問題都盡可能寫清楚了。后續(xù)你動手改造的時候有任何卡住的地方歡迎來交流。畢竟家政數字化這條路一個人走得慢一群人走得遠。