這次再度跟 Hend Design 合體，繼上次的海洋資料庫專案後，這次的業主 HOWSHOW Space 是經營空間租借的公司，手上有好幾間會議室和活動空間，他要的需求聽起來不難：讓客人直接在官網上挑日期、選時段、線上付款就完成預約，說白了就是一套能自己收單的 WordPress 預約系統，我一開始也是這樣想：這不就是裝個預約外掛的事嗎？
但把他的計價規則攤開來看，問題立刻浮現，這門生意的時段與價格，遠比一般預約場景複雜：
- 每間空間的開放時間都不一樣，有的早上八點開、有的十點才開。
- 價格不是一個數字，而是平日／假日乘上時段分界前／後，光一間空間就有四種費率。下午一點是分界點，一點前一種價、一點後另一種價，週末又是另一組。
- 還有長租折扣：超過幾個小時打幾折，而且能設好幾組級距。
- 假日要不要開放租借，每間空間還能各自決定。
換句話說，客人在前台選的每一個時段，背後的可選範圍和金額，都得依這間空間當下的規則即時算出來。對業主來說，真正卡住的地方不是「想不想做線上預約」，而是他試過的方案，沒有一套現成外掛能符合他們的業務邏輯。
那到底什麼時候該放棄現成外掛、改做客製化預約系統？我的判斷很簡單：當核心計價邏輯塞不進外掛的資料模型時，繼續改外掛只會比重寫更貴，這個案子就是這樣，所以我們決定不繞路，直接做一套專屬的場地預約系統。
最後的價格設定介面如下：
重點一：現成的預約外掛，卡在「動態的預約時段」
業主評估過幾套主流的 WordPress 預約外掛——FluentBooking、LatePoint 這一類，結論是它們都處理不了這種動態時段選擇。
它們的設計前提通常是「固定的服務 ＋ 固定的時長 ＋ 固定的價格」，例如剪頭髮 60 分鐘、做臉 90 分鐘。但空間租借是「客人自己拉一段連續時間」，這段時間的可選性（有沒有被別人佔走、是否落在開放時間內、是不是被關閉的假日）和金額（跨不跨分界、平日還是假日、有沒有到折扣門檻），全都得動態運算，硬要拿現成外掛去套，等於不斷跟它的資料模型打架，最後客製的成本比重寫還高。
於是我們幫業主開發了一套 WordPress 預約系統，核心是一個自訂的「空間」內容類型（Custom Post Type），而且刻意不引入任何第三方自訂欄位外掛，全部用 WordPress 內建的 Meta Box API 處理。每間空間的後台就能維護：多張圖片、介紹文案、地址、那組「平日／假日 × 分界前／後」的費率、以及多組長租折扣級距。
前台則用一個自己刻的週／月日曆，把已被佔用的時段灰掉，客人點空檔就能填表預約，同一套架構不只能跑會議室預約系統，業主之後要新增任何一種空間，都是後台填一填就上線。
重點二：結帳流程的最佳化——不繞 WooCommerce，直接從表單結帳
第二個關鍵決策，是金流要怎麼接。
最直覺的做法是套 WooCommerce，把每筆預約變成一張訂單、丟進購物車、走它的結帳頁。我自己寫過一整個 WooCommerce 金流串接的實戰系列，正因為熟，才更清楚這條路對這個案子是包袱。
如果還要透過 WooCommerce 處理，整個預約流程會變得很繁瑣——客人選好時段後，得先「加入購物車」，再跳到結帳頁重新確認，而 WooCommerce 那一整套商品、運送、稅務的設定，對一個「租時段」的場景根本用不到。我得花很多力氣去隱藏、去改寫它原本的流程，才能讓它看起來像個預約系統。
所以我把它整個拿掉，改成直接從預約表單完成金流結帳。客人在空間頁填完表單按下送出，後端就建立一筆預約紀錄、組好藍新金流（NewebPay）的加密參數，直接把人帶到信用卡付款頁。整條線就是「填表 → 付款 → 回寫狀態 → 寄通知信」，沒有多餘的中轉站。
這個決定也讓後續所有功能都長在自己的地基上：訂單編號、付款回傳的驗章與防超賣、退款，全部是我能完全掌控的邏輯，不必去遷就一個通用電商外掛的假設。其中我自己最滿意的一個小設計，是「重新付款」——當客人第一次沒付成功、要再付一次時，系統會在同一筆預約下重新產生一組訂單編號，既避開了金流商「訂單編號不可重複」的拒絕，又能讓付款回傳對應回同一筆預約。
後來我把這套藍新串接踩過的坑與退款 API 細節也整理成另一篇紀錄，這裡就不展開。
重點三：合作模式的亮點——業主先用 AI 把介面刻出來
這個案子讓我印象最深刻的，其實是合作方式。
通常接客製專案，最耗時、最容易來回拉扯的環節是「介面長什麼樣」。設計稿、版面、欄位擺哪、按鈕放哪，往往要來回確認好幾輪，做工的人和提需求的人之間總有一段理解落差。
但這位業主很不一樣——他自己先用 AI 把整個預約表單的介面刻了出來，直接給我一份完整的版面設計，甚至中途還迭代了一版新的 UI 給我。
這一點非常棒！它讓「介面溝通」這個最容易卡關的環節幾乎一次到位。我不用猜他想要的樣子，他也不用反覆描述抽象的需求，雙方直接對著一個看得到、摸得到的成品討論。省下來的時間，我全部投到真正需要工程含量的地方——後端邏輯的設計與測試。
我認為這會是接下來很值得推廣的協作模式：業主用 AI 把「想要的樣子」具象化，開發者專注在 AI 還做不好、也最不該出錯的後端與整合。
其他功能細節
把上面三個主軸定下來之後，剩下的就是把一個真正能上線收錢的空間租借系統，一塊一塊補完整：
- 同時預約與時段保留：兩個客人同時搶同一個時段怎麼辦？我在資料庫層用具名鎖（MySQL
GET_LOCK）擋住後送出的請求，先送出者贏，並把那個時段保留一小時。超過三十分鐘沒付款寄提醒信，滿一小時還沒付就自動釋出時段。
- 完整的交易型通知信：從預約成功、未付款提醒、逾時取消，到付款成功（信裡附上到場資訊與空間進入密碼），再到活動前一天的提醒信，整套生命週期的 Email 都串好。空間密碼還特別做成獨立、顯眼的欄位呈現。
- 顧客自助取消／改期／退款：客人不是網站會員，所以我用一組綁在預約上的安全 token 來驗證身分，讓他透過信件裡的連結自助操作。退款則內建級距規則——三天前全額退、一天前退一半、當天不退——並直接呼叫金流商的退款 API 寫回。
- Google 行事曆同步：客人一旦付款完成，預約就自動寫進該空間綁定的 Google Calendar，取消時自動刪除，方便業主用熟悉的行事曆掌握所有檔期。為了不讓專案背上一堆相依套件，我沒裝官方 SDK，而是自己用 service account 簽 JWT 直接打 Calendar API。
- 假日與開放時間控制：每間空間都能各自設定開放時段、要不要接受假日預約，而且前端會即時反映、後端也會再驗一次，不信任前端送來的任何值。
開發過程我全程走 TDD，關鍵的同時預約、加解密、退款計算都有測試守著。最後上線前，還用了多個 AI 模型（Codex、Grok 加上 Claude）交叉做了一輪程式碼審查，互相挑彼此漏掉的問題，確認沒有資安與重複寄信的風險才發版。
小結
系統上線後，開頭那個來回問檔期的流程就消失了——客人自己在官網選時段、線上付款、收確認信，業主不必再守著 LINE 一筆筆回。原本綁在人工排程上的時間，業主拿回去經營空間本身。
這個案子對我來說是一個蠻完整的縮影：當需求的核心邏輯夠特殊（這裡是動態時段定價），與其硬套現成外掛、再花更多力氣去改它，不如老老實實做一套專屬的客製化預約系統，反而更省、更穩、也更好維護。而業主先用 AI 把介面具象化、開發者專注後端的這種分工，也讓我看到 AI 時代客製專案一個很有效率的合作姿態。
順帶一提，這個業主做的是空間租借，如果你對這個產業的經營現場有興趣，我以前也寫過一篇共同工作空間的初體驗觀察。
如果你也有「現成外掛差一點點就是搔不到癢處」的需求，這種客製化的路，也非常歡迎與我們聊聊！