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