在【Day 2】梳理了場地資產與紙本訂房簿的 5 大表面痛點後，我與中心的負責志工進行了一次深入的流程訪談。

這次對話不僅幫我們簡化了房間預約的邏輯，更揭露了一個在紙本時代運行多年、志工因為不常在中心而無法察覺的致命管理死角——「事後套用舊取消紀錄（人情套單）」，以及「跨世代志工與職工對時間格式習慣不同」的 UI/UX 課題。

今天我們不急著搬出各式各樣的開發工具，而是專注於「把現場痛點與人情營運，收斂成清晰、可被程式執行的系統 logic、防呆規則與包容性設計」。

一、 現場訪談補完：被忽視的 6 大營運潛規則
在紙本訂房簿的運作下，許多沒有寫在標準作業程序（SOP）裡的邊界條件、人為操作與使用者習慣逐漸浮出水面：

房間回歸獨立預約（簡化邏輯）：
經過與志工討論，中心決定將房間邏輯回歸簡單——活動室 A1、A2、B1、B2 與小型洽談室，一律視為獨立房間進行預約。若職員需要較大的空間，直接同時預約 A1 與 A2 兩間即可，系統不必在現階段處理複雜的打通房聯動鎖定，大幅降低邊界檢查的複雜度。

防範霸場的 90 天預約上限：
為了防止個別部門或職員一次把半年後的黃金時段全部訂滿，造成其他人的不公平，中心規定最多只接受 90 天內的預約。

1 天前最晚取消時限：
臨時取消會造成場地閒置。中心規定最遲必須在借用前 1 天完成取消，以便將空出的時段釋放給其他職員臨時申請使用。

60 天改期，且最多「2 次」為限：
取消後允許在 60 天內重新預約抵用。若改期後因故又取消，整個預約序列最多僅允許改期 2 次。第三次取消即視為放棄，該次預約直接結案並照常計費/扣除額度。

破解「事後湊舊單」的人情漏洞：
職工有新預約需求時，有時會偷偷將其標記為「之前某次已取消的預約改期」，藉此規避重新計費。由於負責志工不是每天都在中心，傳統紙本又沒有不可篡改的時間戳與流水號，根本無法查證該筆預約到底是不是真的由舊紀錄轉來。

跨世代時間習慣差異（12小時制 vs. 24小時制）：
訪談中發現，年長志工普遍不習慣看 24 小時制（容易把 14:00 與 16:00 搞混，偏好「下午 02:00」），而年輕職工則習慣使用 24 小時制（14:00）。無論介面或月結報表，若只強制採用單一格式，都會造成其中一方的閱讀障礙或填表錯誤。

二、 系統邏輯建模：五重防呆與包容性機制
針對上述訪談整理出的規則，我們必須在系統設計階段建立 「五重邏輯與 UI 防線」：

防線一：時間邊界閘門 (Time Gate Control)
90 天遠端限制： 系統自動比對 預約日期 - 當前日期 <= 90 天。超過 90 天的日期在日曆介面上直接呈現不可選取狀態，徹底杜絕過早霸場。

1 天前取消門檻： 取消功能僅在 預約日期 - 當前日期 >= 1 天 時開放。若在借用當天臨時取消，系統自動判定為「違規取消/照常計費」，不予發放改期抵用額度。

防線二：獨立資源與移動物資排程 (Resource Scheduler)
房間獨立化： A1、A2、B1、B2、洽談室各自為獨立 ID，時段衝突檢查只需做最基礎的單一房間時段重疊判定（Overlapping Check）。

移動設備動態扣減： 預約房間時，系統同步檢查「移動電視（限量 1）」、「投影機（限量 1）」與「手提電腦（限量 2）」的剩餘庫存，避免訂了房間卻無影音設備可用的尷尬。

防線三：帶次數與時效的狀態機 (State Machine with TTL & Counter)
針對「取消與改期」的生命週期，我們設計了帶有過期時間（TTL）與計數器的狀態流轉：

[正常預約] ──(提前 1 天前取消)──> 
                         [產生改期令牌 (60天有效, 改期計數 = 1)]
                         │
                         ├───> 60天內重新預約 ───> [改期預約成功]
                         │                        │
                         │                 (若再次提前 1 天取消)
                         │                        ▼
                         │               [改期計數 = 2 (達上限)]
                         │                        │
                         │                 (若第三次取消)
                         │                        ▼
                         └───> 逾期 60 天未補訂 
                            ───> [結案：照常計費 / 額度沒收]

防線四：唯一核銷令牌 (Reschedule Token) 與系統不可篡改時間戳
為了徹底封殺「人情套單」漏洞，系統採取嚴格的銷案機制：

• 獨一無二的改期 Token： 當符合資格的取消發生時，系統自動生成一組唯一的 Reschedule_Token（內含 60 天倒數期限與 Reschedule_Count 次數標籤）。

• 一對一強制核銷： 職員若要發起「改期預約」，必須在系統中選擇自己名下有效、未逾期且次數未達上限的 Token 進行折抵。Token 一旦使用，狀態立即變更為 Redeemed，絕不可能拿同一筆取消紀錄重複使用，更無法事後補套。

• 系統自動時間戳 (System Timestamp)： 所有新增、修改、取消操作，後端強制寫入當下的系統時間（Created_At），任何人都無法透過手寫或改單來偽裝「這是一個月前的預約」。

防線五：雙時制兼容顯示與報表引擎 (Dual-Format Engine)
解決跨世代使用習慣的衝突，軟體不該做單選題，而是要做「雙向包容」：

• 互動介面（UI）： 預設採用「雙格式併存」標示（例如：14:00 (下午 02:00)），並在系統右上角提供一鍵切換（12H / 24H Toggle）按鈕，記住使用者的喜好偏好。

• 月結報表（Reporting）： 底層資料庫統一以 ISO-8601 標準時間格式（24小時制）儲存與運算；但在匯出或給志工查看的月結視圖中，自動渲染為「帶有上/下午標記」的 12 小時制格式，確保志工核對無障礙。

三、 表面痛點與系統邏輯解決方案對映
整理這三天的討論，我們將 NGO 現場的所有問題，全數收斂為軟體設計上的邏輯對策：