看到 n8n 時，我以為找到做預約系統的方法了

前面幾篇一路寫的是，這套預約管理工具的功能怎麼長出來、哪些工作可以交給系統，以及我後來怎麼注意到：

功能做得出來，不代表產品就真的完成了。

從這一篇開始，我想把時間往前拉一點。

重新從工程的角度，看一次這套東西最早是怎麼被我做出來的。

因為我後來才看懂：

我一開始怎麼理解問題，會直接影響我去找什麼解法。

我一開始把整套需求理解成「自動化」

最早我看到的問題很直接。

櫃檯有很多事情需要一直重複做。

有人傳訊息來，要回覆。

預約成立之後，要通知、更新行事曆。

文件產生之後，要備份。

一件事情做完，後面常常還有下一件固定工作要接著做。

所以我當時很自然地把整套需求理解成：

自動化。

既然很多工作都是：

這件事情發生之後，接著做另一件事情。

那如果把這些步驟全部串起來，是不是就能做成一套預約系統？

就在那時候，我看到 n8n。

n8n 和我當時理解的問題非常對得上

n8n 可以把一個個動作，用圖像化方式接成流程。

收到訊息之後要做什麼。

符合某個條件往哪裡走。

接下來要回覆、寄信、存檔，還是把資料送到其他地方。

對當時的我來說，這個方式很直觀，也和我腦中正在想的事情完全吻合。

我要解的是自動化問題，而我剛好找到了一個可以把工作流程自動接起來的工具。

所以我就開始照著做。

而且一開始真的很順。

最早的需求，本來就很適合這樣做

例如使用者想知道：

服務怎麼使用。

心理師有哪些。

交通方式是什麼。

怎麼聯絡。

這些對 n8n 來說都很直接。

收到一種訊息。

判斷使用者想看什麼。

再回覆對應內容。

很接近：

收到 A，就回 B。

後來像寄信、Google Drive 備份，也很符合原本的理解。

前面一件事完成。

後面就接著做另一件固定工作。

對我來說，這些都是同一類問題。

所以新的需求出現時，我也很自然地繼續往 n8n 裡加。

真正開始變質的是正式預約流程

系統裡有不同角色。

個案、心理師、櫃檯透過自己的 LINE 帳號跟系統互動時，會看到不同功能，也能做不同事情。

一開始帳號綁定還算好處理。

例如：

使用者輸入 /綁定。

系統問姓名。

再問電話。

確認資料之後，把這個 LINE 帳號和系統裡的人連起來。

這段仍然很像一條清楚的流程。

但正式進入預約之後，事情開始不一樣。

使用者可能輸入：

「我要預約。」

也可能直接點選 LINE 選單裡的預約功能。

對使用者來說，這只是在開始做一件事。

但系統收到訊息之後，開始要知道：

現在是誰？

他是不是已經在某一段流程裡？

這次輸入是在開始新的事情，還是在回答前面問過的問題？

如果正在預約，目前做到哪一步？

接下來要往哪裡走？

新增預約是一條。

修改預約又是一條。

取消又是另一條。

不同角色還有不同功能。

共同入口後面的判斷越來越多。

n8n 畫布也開始快速膨脹。

Day 2 時，我第一次知道這個問題有名字

Day 2 已經寫過，我就是在這個階段第一次從 AI 那裡知道：

系統要記住一個人現在做到哪一步，本身就是一個需要處理的問題。

我那時候第一次知道「狀態機」這個詞。

也第一次知道，自己已經跟一個工程問題纏鬥很久，只是以前沒有語言可以描述。

但知道這個問題有名字之後，我並沒有立刻換一個角度看整套系統。

這才是我後來覺得更重要的地方。

我知道有狀態問題，卻還是繼續問「n8n 要怎麼改」

即使已經知道：

這不只是畫布太亂。

我當時第一個想到的還是：

節點要怎麼重排？

流程要怎麼拆？

這一段應該怎麼接？

n8n 還可以怎麼改？

因為前面的東西都已經做出來了。

而且它們真的可以運作。

所以我很容易覺得：

可能只是自己還不夠會用。

可能只是流程還沒整理好。

可能再找到一種更好的畫法就行。

也就是說，我雖然已經多知道了一個工程概念，卻仍然留在同一個前提裡：

這套東西還是應該用 n8n 做。

我一直在原本的問題框架裡找答案。

真正需要改的，是我原本問的問題

我原本一直問：

「怎麼用 n8n 把預約流程做出來？」

這個問題本身已經先假設：

n8n 就是解法。

所以後面的討論自然會變成：

怎麼整理 workflow？

怎麼拆節點？

怎麼管理更多分支？

直到原本的方法真的改不下去，我才開始重新問：

「要讓這套預約流程真的運作，系統到底需要處理哪些問題？」

這一問之後，原本混在一起的事情才開始分開。

固定回覆。

寄信。

檔案備份。

這些很接近：

某個明確事件發生之後，接著做固定工作。

但正式預約流程還需要：

記得使用者前面做過什麼。

知道目前在哪一步。

理解這次輸入在目前流程裡代表什麼。

根據前面的狀況決定下一步。

這些東西雖然都可以被我叫做：

「自動把工作接起來。」

但實際需要系統處理的問題已經不一樣。

問題重新被理解，工具也就需要重新評估

做到這裡，我才知道：

原本的問題不是：

「n8n 還能不能多做一點？」

而是：

「現在這些責任，還適合繼續放在這裡嗎？」

最後，我捨棄了讓 n8n 承擔主要預約流程的做法。

改成自己寫一套後端程式來處理預約流程，資料也另外放進正式資料庫。

這不是因為我先研究完所有架構方法，再比較之後選出一個最佳答案。

實際順序更像是：

原本的方法真的改不下去 → 開始找另一種做法 → 在新的做法裡重新理解自己原本到底在處理什麼問題。

我還短暫想過：那 n8n 留一部分可以嗎？

改成後端之後，我一度也想過：

原本已經在 n8n 裡跑得很順的寄信和 Google Drive 備份，是不是可以留下來？

這樣看起來很合理。

預約核心由後端處理。

自動化工作繼續交給 n8n。

但真的往下做，又多出另一批事情要維護。

後端和 n8n 要交換資料。

n8n 要另外長期運作。

多一套部署和伺服器資源。

Google 服務的授權也要分開管理。

所以問題又不只是：

「這件事情哪個工具比較會做？」

還包括：

「為了讓兩套東西一起工作，我又多出了多少新的關係需要維護？」

最後我還是把寄信和檔案備份一起寫回後端，讓 n8n 完全退出這套系統。

我後來學到的不是「n8n 不適合做產品」

現在回頭看，我不會把這段經驗整理成：

我一開始選錯工具。

n8n 會成為我的選擇，本來就和我當時怎麼理解問題有關。

當我看到的是：

怎麼把人工工作自動接起來？

去找一個自動化工具，本來就很合理。

後來需要換方法，也不是因為前面的判斷突然變成錯誤。

而是我開始知道：

自己正在處理的問題，比原本理解的更大。

所以這段經驗最後留給我的問題，不只是：

什麼工具比較適合？

更重要的是：

我現在真正要解決的，到底是什麼問題？

而如果連問題本身都重新被理解了，原本的方法和工具，也就需要一起重新評估。