SMS 自動發送系統：把週末加班，變成每天自動完成

公司過去有一項例行工作：針對超商未取貨的訂單發送提醒簡訊。根據經驗，客人在第 4 天、第 7 天收到提醒，回來取貨的機率最高——所以這兩個時間點一定要發。問題是，第 4 天或第 7 天剛好落在假日，就需要有人特地加班完成這件事。

加班紀錄裡的固定模式

有一次查看加班紀錄，我發現同事幾乎每個週末都固定需要加班。

我想知道的不是「誰在加班」，而是「為什麼這件事情，一定要在假日由人完成？」

不急著談系統，先理解流程

於是我先找第一線同事聊。不討論系統怎麼做，先把整個工作流程弄懂：

• 為什麼一定是第 4 天、第 7 天？
• 哪些訂單需要發？
• 哪些情況不能發？
• 發送前還需要確認哪些資訊？

很多時候，我們看到的只是工作的表象。真正重要的，是理解背後的原因。

第一版只做最核心的事

確認流程後，我沒有一次把所有需求做完，先完成最核心的功能：

第一版的目標很單純：先確認我們真正要解決的問題，有沒有被解決。

上線後，需求自己浮現

系統正式上線後，新的需求開始慢慢出現：

• 門市希望增加滿意度調查簡訊。
• 行銷希望在購買後 30 天、90 天，自動發送回購提醒。
• 不同情境需要不同的簡訊內容與發送規則。

因為第一版已經建立了發送架構，後續新增的需求，都能在既有模型上持續擴充——而不是重新開發一套系統。

這套系統從原本只解決第 4 天、第 7 天的提醒，逐步發展成公司的簡訊發送平台：

原本需要人工安排時間完成的工作，現在都由系統每天自動執行。週末加班，變成每天自動完成。

我的設計思維

我很少因為「有人提出需求」就開始做系統。我通常先確認三件事：

• 這件事情是不是很重複？
• 它是不是其實不複雜？
• 解決之後，是不是真的能帶來效益？

三個條件都成立，我才會思考能不能把它設計成一套系統。

另外，我也很少一開始就把功能做滿。我習慣先完成最小可行版本，確認方向正確，再透過實際使用持續迭代——因為真正的需求，通常不是會議裡討論出來的，而是在每天使用的過程中慢慢浮現。

能拆解的，就能做到。你手上如果也有想拆解的問題，歡迎來找我。