把你的想法，做成真正能運作的網站與 App。

客戶原本的狀況

懶人殿堂的服務很直接：會員固定在某幾天把垃圾放在門口，司機開車依序去收。麻煩的地方在於營運資訊分散在四個地方：會員的基本資料、每位會員希望哪幾天收、司機當天要跑的順序，還有客戶隨時會問的「今天收了沒」。

這四件事原本各自處理，每天出車前要先把它們對在一起；客戶一問進度，就得有人去查、再回訊息。客戶要的不是一個漂亮的網站，而是一套讓這四件事在同一個地方發生的系統。

系統裡的三種人，加上 LINE 這個入口

我把流程拆成三種角色，每一種人只看到自己需要的畫面：

• 會員：在系統上下單，選擇希望收取的星期幾，也能自己維護聯絡資料與地址。
• 管理者：在後台維護會員資料，看到每一天有哪些人要收、分別在哪裡；司機出發前把當天的名單排成一條順路的路線。
• 司機：照排好的順序收，收完一戶就標記完成，後面的順位自動往前。
• LINE：會員在 LINE 上問一句，就得到兩個數字——司機目前收到第幾順位、自己是第幾順位。這樣他不用打電話，就能確定垃圾收了沒、大概還要等多久。

幾個設計上的決定

收件日綁在訂單上，由後台彙整成每日名單。會員下單時選星期幾，管理者就能直接看到「星期三有哪些人要收」，不必另外維護一張表，也不會出現表和訂單對不起來的情況。

排單放在出發前，由管理者決定順序。真正順不順路，熟悉區域的人比演算法更清楚；系統的工作是把當天名單整理好、讓調整順序這件事夠快，不要讓他把時間花在整理名單上。

進度用「順位」表達，不用「預計時間」。路況會變，承諾幾點到很容易失信；「司機收到第 12 順位、你是第 15 順位」這個資訊已經足夠讓客戶判斷垃圾收了沒、大概還要多久。

查詢走 LINE，不另外做 App。客戶本來就在 LINE 上聯絡，一個查詢動作不值得多裝一個 App。後台的資料不變，多開一個對外的問答入口就好。

限制與沒有做的事

• 沒有做導航等級的路線最佳化。順序由人決定，系統負責讓這個決定快而少錯。
• 進度查詢的前提是司機有確實在收完後標記。這是流程上的要求，系統能提醒，但不能替他按。

上線之後

管理者每天出車前在同一個後台完成排單，不必再在幾個工具之間對資料；客戶想知道進度時自己在 LINE 上查，「今天收了沒」這類訊息不再需要人手回。

如果你的服務也長這樣

定期到府的服務——收件、配送、清潔、保養——大多有一樣的結構：固定週期的名單、出發前的排序，以及客戶想知道「什麼時候到」。如果你的營運也卡在這三件事，可以先到案例區看懶人殿堂的後台畫面，或直接到聯絡區聊聊你的流程。