預約流程
- 客戶從 LINE／AI 或由員工代為提出預約需求。
- 系統辨識地點、項目、醫師、日期與時段。
- 檢查醫師班表、預約空檔及必要資源。
- 原時段不可用時，提供其他可預約時段。
- 確認後建立系統預約及 Google Calendar 事件。
- 特殊情況或 AI 無法判斷時轉人工。
01 / Overview
訪談結論
初悅婦妍目前的資料與作業分散在既有系統、Google Calendar、LINE 與紙本。主要問題不是缺少單一功能，而是各流程沒有串接，也無法快速確認員工是否完成紀錄、扣庫存或客戶追蹤。
核心需求
範圍待確認
尚未簽核
02 / Current state
目前現況與痛點
| 現況／痛點 | 造成的問題 |
|---|---|
| 客戶與作業資料分散在不同地方 | 需要人工交叉查找，沒有完整的單一客戶視圖 |
| 預約主要依賴 Google Calendar 與人工處理 | 客戶、醫師、員工等行事曆不易統一管理，也無法直接承接 AI 預約 |
| 同意書、問卷等資料仍有紙本流程 | 資料不易搜尋、整合及追蹤 |
| 員工可能忘記扣庫存、漏填紀錄或不熟悉系統 | 主管或指定人員需每週重新核對，耗費時間 |
| 療程後及保健品使用後的追蹤仰賴人工記憶 | 容易漏掉客戶，曾出現客戶認為診所治療後未持續關心的情況 |
| 檢測異常項目及複檢時間沒有完整管理 | 無法穩定提醒客戶回診，也不易確認員工是否已聯絡 |
| LINE 顯示名稱未必能直接辨識客戶 | 對話、會員資料及歷史紀錄難以串接 |
| 現有系統可匯出資料，但欄位與可搬遷範圍不明 | 導入新系統前需要先做資料盤點與欄位對照 |
03 / Requirements
需求總表
院方明確提出的核心需求
| 編號 | 需求 | 期望行為 | 建議優先度 |
|---|---|---|---|
| R1 | AI／線上預約 | 客戶以自然語言提出日期、時段、醫師或服務需求；系統查詢可用時段、提供替代方案、確認預約，無法處理時轉人工 | 高 |
| R2 | Google Calendar 同步 | 確認預約後自動寫入 Google Calendar，並與診所系統的預約資料保持一致 | 高 |
| R3 | LINE 會員綁定 | 客戶首次加入時以姓名、電話等資料完成綁定；也要支援員工協助綁定 | 高 |
| R4 | LINE 客戶資訊整合 | 員工處理 LINE 訊息時，可以識別客戶並查看會員、歷史療程、保健品及追蹤紀錄 | 高 |
| R5 | 保健品追蹤 | 每項保健品可設定功能、說明、價格、追蹤時間及要詢問的問題；同一客戶可同時使用多項保健品 | 高 |
| R6 | 療程追蹤 | 不同療程可設定不同追蹤節點，例如第 3 天、第 7 天、第 30 天的關心或回診提醒 | 高 |
| R7 | 檢測異常與複檢追蹤 | 記錄異常項目、建議複檢日期與後續處理，時間到時提醒客戶並產生員工聯絡名單 | 高 |
| R8 | 兩層式提醒 | 第一層由 LINE 自動提醒客戶；第二層由系統建立員工待辦，完成電話或人工 LINE 關懷後需留下完成紀錄 | 高 |
| R9 | 院方知識庫 AI 客服 | AI 僅根據院方提供並核准的保健品、療程、FAQ、活動及 SOP 回答，不自行從公開網路產生醫療說法 | 高 |
「高」是依訪談明確度提出的建議，不代表院方已完成開發優先順序簽核。
有明確痛點或表達興趣，但範圍待確認
| 編號 | 需求 | 訪談中的期待 | 尚待確認 |
|---|---|---|---|
| R10 | 庫存自動扣除與低庫存警示 | 使用產品後扣庫存；低於安全量時通知；可參考未來預約與預估用量協助補貨 | 哪些品項納管、扣庫存時點、批號／效期、盤點與採購是否納入 |
| R11 | 紀錄完整性與員工待辦 | 自動列出漏填資料、未完成紀錄、未扣庫存及未追蹤客戶，通知負責人並供主管查看統計 | 哪些欄位為必填、責任歸屬、逾期與通知規則 |
| R12 | LINE／定位打卡 | 員工透過 LINE 打卡並按月統計出勤 | 定位半徑、Wi-Fi／GPS 驗證、補登、請假與薪資串接範圍 |
| R13 | AI 銷售建議 | 根據近六個月的療程、購買與消費紀錄，提供新進員工可參考的溝通方向 | 是否列入第一階段，以及醫療適切性、審核與可推薦範圍 |
| R14 | 紙本資料數位化 | 將同意書、問卷及可能的顧客相簿紀錄整合到客戶資料 | 哪些文件要電子化、電子簽署方式、照片與文件保存規則 |
| R15 | 舊系統資料匯入 | 從現有系統匯出會員等資料後搬入新系統 | 可匯出格式、欄位、資料品質、歷史紀錄與附件是否可取得 |
| R16 | 業績／收款／財務管理 | 訪談開頭曾提到業績、現金帳戶及現有財務功能未使用，但語音內容不完整 | 是否有收款、醫師業績、對帳或財務報表需求，以及是否納入本案 |
04 / Workflows
核心流程整理
保健品／療程追蹤
- 替客戶選擇療程及一項或多項保健品。
- 依各項目的規則建立追蹤排程。
- 到期時透過 LINE 發送核准的提醒或問題。
- 同時或在未回覆時建立員工關懷待辦。
- 記錄聯絡結果，必要時建立後續任務。
檢測複查流程
- 記錄本次檢測與異常項目。
- 設定建議複檢日期及追蹤說明。
- 到期時提醒客戶並建立員工聯絡名單。
- 完成聯絡或複檢後更新狀態，保留歷次結果。
LINE 身分綁定
- 客戶加入官方 LINE 後啟動綁定。
- 輸入姓名、電話，或由員工協助配對會員。
- 保存 LINE user ID 與會員的關聯。
- 在工作台同時顯示客戶資料與對話脈絡。
05 / Inputs
院方需提供的資料
先取得以下內容，才能估算功能、建立原型並界定第一階段範圍。
- 01保健品清單
名稱、功能、用法、注意事項、價格、追蹤時間、追蹤問題及人工介入條件。
- 02療程清單
療程名稱、標準追蹤節點、訊息內容、回診週期及例外處理。
- 03檢測追蹤規則
檢測類型、需記錄的結果、複檢週期及通知方式。
- 04預約規則
診區、醫師、服務項目、時段長度、班表與不可由 AI 直接預約的情況。
- 05AI 知識庫內容
院方核准的 FAQ、療程與保健品說明、活動、SOP、內容負責人與更新頻率。
- 06現有資料樣本
舊系統匯出檔、欄位說明、Google Calendar 架構、紙本表單與現行流程。
- 07LINE 官方帳號資料
目前方案、訊息額度、既有好友／標籤／圖文選單與 Messaging API 狀態。
- 08角色與權限
醫師、護理師、櫃檯、主管可查看及可修改的資料範圍。
06 / Open questions
下一次訪談必須確認
第 13 題屬前置門檻：答案會決定本案是否落在目前可承接的業態範圍，建議最先確認；第 14、15 題則直接影響追蹤與檢測兩塊的開發規模。
- 第一階段只能先做哪些功能，驗收成功的標準是什麼？
- 預約資料以診所系統或 Google Calendar 哪一邊為主？雙向修改衝突時如何處理？員工平常是否會直接在 Google Calendar 上新增或修改預約（而非透過系統）？
- 客戶未回覆自動訊息後，何時升級成人工待辦？需要幾次提醒？
- 哪些內容 AI 可以直接回答，哪些必須轉交醫師或人工客服？
- 保健品與療程追蹤是固定範本，還是可依個別客戶調整？誰有權調整？
- 檢測異常由誰輸入、誰審核？系統只做提醒，或需要保存完整檢測報告？
- 舊系統實際可匯出哪些資料？紙本、照片、同意書是否列入首批搬遷？
- 庫存、打卡、AI 銷售建議是否屬於第一階段，還是後續擴充？
- 訪談開頭提及的業績、現金帳戶與財務功能，是否為本案需求？
- 是否需要串接診所現有的簡訊、金流、電子簽署或其他第三方系統？
- 個資、醫療資料、LINE 對話與 AI 使用的告知同意、保存年限及操作稽核要求為何？
- AI API 與 LINE 訊息費用只是現況參考；院方可接受的每月預算與預估訊息量為何？
- 院方是否承作健保業務？ 產檢、接生與健保婦科門診各占多少比重，或院內為純自費業態？（此題決定本案能否納入目前可承接範圍，須先於其餘各題確認）
- 療程與保健品的追蹤節點是否必須為日粒度？ 例如「第 3 天」是否為實際作業需求，或「第 1 週／第 4 週」這類週粒度即可滿足？各節點之間的間隔是否需要逐客戶調整？
- 檢測追蹤需要到什麼深度？ 只需記錄異常項目、建議複檢日與到期提醒，或需保存結構化檢驗數值（單位、參考區間、歷次趨勢對照）？是否需掛載原始檢驗報告或影像？
07 / Next step
建議的需求確認順序
以下是分析建議，不是已核准的開發計畫。
- 先取得資料樣本、LINE／Calendar 現況及完整服務清單。
- 選定一個療程或一組保健品，完成「建立追蹤規則 → 自動提醒 → 員工待辦 → 完成紀錄」的流程原型。
- 驗證 LINE 會員綁定及 Google Calendar 同步方式。
- 由院方確認第一階段範圍、權限、個資與醫療內容審核機制。
- 完成簽核後，再拆分正式開發項目、估時與報價。
08 / Definition
一句話需求定義
建立一套以 LINE 為主要入口、串接會員與 Google Calendar，並能依療程、保健品及檢測規則自動提醒客戶、派發員工待辦及追蹤完成狀態的診所管理系統。