預約系統–維護與新模組開發迭代
接手已上線的看診預約系統，維護2年，並陸續開發新模組。 從小 bug 到全新功能，在既有的資料結構、操作習慣與第三方串接限制下，判斷哪裡能改、哪裡動了會塌，高效與開發合作/除蟲並動態上線。
Year
2024~2026
Duration
2years
Client
Agency( 諮商診所x3 )
Role & Responsibility
接手維護｜需求釐清｜模組規劃與設計｜測試與交付文件｜客戶溝通與客服
Category
預約服務前後台
1｜報到系統
診所人手不足，櫃檯同時要負責協助報到、查詢預約、引導等候、檢查遲到
—這些高人力、低價值的重複流程佔掉大部分人力。
以個案自助報到、多項自動通知與設定，降低櫃檯人員協助報到、查詢預約、引導等候、檢查遲到等高人力流程
達到半自動化、高節省人力之報到流程。
掃描報到系統
個案到達診所後使用預約成功時收到的QRcode，以櫃檯平板掃描的形式來報到。
排除其他形式：
掃描槍掃描：需另購、安裝內部系統，較難控制突發狀況，且還是需要人員掃描，無法自主報到
個案手機線上報到：無法阻止未到個案擅自報到，就算是到診所後查看當日報到碼來輸入報到，也會需要個案手機有穩定網路以及更多步操作，較不方便
自助報到機台：雖然可以直接報導與付款，但硬體費用高昂、需使用廠商系統，串接DBee較不可控與困難，且諮商費用非固定，容易更混亂
最終流程
預約成功 → 個案收到 QR code（診所可設定自動提醒時間）→ 抵達後於平板掃碼（或輸入驗證碼）→ 系統自動通知指定醫師與櫃檯 LINE 群組。
遲到、報到失效、未到等支線流程一併窮舉處理。
後台配合調整
行事曆卡片新增報到狀態 Tag、報到設定頁（規則可自訂）、LINE 通知群組綁定（可對應心理師與成員、隨時更新）、訊息用量監測（總則數／各類型／已傳送對象數／串接群組數）。
交付
系統更新頻率經測試權衡設為 30 秒；開發完成後接兩週多輪測試，交付簡介圖、完整操作手冊、操作錄影，並完成第一輪回饋收集與 QA。
2｜新增付款方式模組
因應客戶經常需要調整付款方式，每次都要由我們（系統方）在後端修改調整，因此新開模組讓客戶可主動管理付款方式（現金、LINE Pay、第三方支付）。
也強制讓個案線上付款時只能使用一種付款方式，避免很多背後長久以來的bug與不可抗力的金流串接問題。
可管理各付款方式—是否開放、是否預設
付款方式綁定個案— 可指定某個案只能使用某種付款方式，解決個案付款時混亂或無法使用的問題。若需要現場付款、付款時再確認等需求，綁定僅現金付款可解決個案預先線上付款。
因有多個層級，明確設定優先排序與取代條件非常重要，詳細規劃與測試了邏輯與操作結果
（優先套用層級：直接在預約調整 > 個案綁定 > 預設 > 是否開放 ）
3｜隱私權升級
因陸續有隱私與資料暴露問題出現，
全面檢查前後台安全性與資安漏洞。
處理：
｜敏感與個人資料需二次驗證訪問身份｜
如個案需填寫的相關文件，訪問需要個案手機末四碼，且單純複製連結無法開啟（避免惡意傳播）
｜後台設定不同操作層級可訪問頁面與功能｜
四個權限層級：擁有者、管理員、服務員、專業人員
每個後台模組與功能，皆有權限設定。擁有者可操作部分權限開放給指定層級
避免內部人員收集敏感資訊、組織重要資訊，或操作重大設定
｜系統方避免直接儲存客戶帳密｜
確保我方除了資料庫外，不直接儲存客戶帳密，採分散與本地儲存
4｜同預約項目可選擇其歷史金額
同位個案預約的服務項目基本相同，唯醫師會根據個案狀況，參考或調整收費。
因此開發「應付金額跟著個案過往紀錄走」之功能
應付金額預設顯示該個案上次預約的新額（若無則顯示該服務項目原始金額），
可再選擇該個案過往的被設定金額。
本功能看似簡單，但牽涉金額設定邏輯，需完整檢視、測試所有金額環節，確保無遺漏而造成金額有誤的嚴重問題
5｜避免「申請改約」後可直接取消已成立的預約
阻止個案點擊「申請改約」後，可再取消預約的Bug（已成立的預約，僅能遊診所方取消預約，個案方只能提出申請）
原為系統漏洞，「申請改約」的預約會被視為「未確認」之預約，因尚未被診所確認，因此可由個案直接取消。
因此申請改約後，應新增狀態「改約待確認」，來與「未確認」明確區分，確保不會發生預約直接被取消的狀況
6｜登入綁定LINE帳號與手機簡訊驗證，確保為真人預約
有效降低重複性帳號，以及建立後為預約的比例
窮舉並處理流程中各種可能的操作與斷點，確保任何行為皆不會中斷
但仍有無法克服的問題：串接簡訊自動發送的服務，有極低一定比例無法順利發送到個案手機，因此積極與客戶溝通如何告知與手動解決。
7｜AI功能初步規劃
「心理諮商診所 LINE AI 預約秘書」
打造 24 小時在線的 AI 業務秘書，透過 LINE 官方帳號實現「對話即預約」
AI 根據已被提供的資訊，自動於LINE回覆使用者的問題與要求，價值在於 AI pipeline 與相關的知識設定等等
三核心：
自然語言預約
— 個案說「約下週三晚上」，AI 直接列出空檔卡片，點擊即完成預約
舊客一鍵回診
— 系統自動調閱歷史紀錄，提供「照舊預約」按鈕，3 秒完成回購
AI 智能導診
— 個案問「最近睡不好」，AI 推薦擅長失眠的心理師 + 可預約時段卡片
（參與階段：初步規劃、完整case示意、訪談討論與回饋修改、非技術之需求文件50%）
重要：服務邊界
僅處理「行政預約流程」與「媒合導診」。非預約相關內容（即時心理諮商、危機處理、閒聊）不在服務範圍內，系統需引導聯繫真人客服。
其他功能與維運
功能開發
新增預約詳情頁（個案可檢視歷史預約細節）
前後台常用頁面 RWD（因操作人員常只能用手機）
日常維運
每日收集診所回饋，依嚴重與緊急程度分流：
直接回答／測試後教學／bug 排查與排程／測試站驗收與上線／進度回報
環境維護：正式與測試環境、內外部帳號、客戶試用帳號、總管理後台、Google 與 LINE 官方 API 串接
文件維護：Onboarding、操作教學、工作流程、常見問題
常見問題與處理方式
Google 日曆不同步 → 調整更新頻率、未收到更新自動重送
LINE 通知漏發 → 逐案排查、請工程師查 log、與客戶說明原因與解法
金流重複付款或對不攏 → 與第三方支付銀行團隊建立直接溝通管道
產品資料難尋 → 經多手維護後資料冗餘重複，持續整理
未來排程 DBee 3.0（客戶已提出的需求）
服務項目架構調整（前台只顯示個別／聯合諮商，EAP、社福轉介不另列項目）
團體諮商預約架構優化（首次由後台建立，後續團長團員可自行預約）
後台自訂公休日（如國定假日自動公休）
報到流程與權限調整（心理師可自審、只看到自己的個案、可直接幫個案預約下次）
收據欄位自訂與完整歷史紀錄
Takeaway
接手一套上線中的系統，和從 0 to 1 design 有很大的差距
接手既有產品，架構容易成為限制。
維護期最有效的設計判斷，絕對不是「重做流程」，而是「補一個狀態」、「定一組優先序」、「把一個欄位開放給客戶自己設定」—成本最低，解決得最徹底，且每改一個部分都需要把相關影響徹查完整一遍，避免上線後因各種花式操作而導致bug甚至崩潰。
設計工作的邊界比我想像的寬。實際在做的包括每日回饋分類與分級、bug 排查與排程、測試站驗收、Onboarding 文件與操作教學維護、與第三方支付銀行團隊建立溝通管道。這些都不存在於設計稿，但決定了設計與意圖能不能真的體現在產品中。
