店家不需要買伺服器：所有運算都在雲端（Cloudflare 與 LLM API）按用量付費；店內只需要網路和既有的手機／平板，正式營運才視需要加購出單機、備援網路與 UPS。
階段 1展示版
- 目標
- 讓店家看懂「路由＋專職 Agent＋交接包＋稽核」怎麼運作，確認設定檔要填哪些欄位。
- 店家要提供
- 不用提供；用虛構飯店示範（多間同時上線、各自 store_id）；另有 5 個一頁式「飯店官網 Demo」，右下角客服泡泡用同一套引擎。
- 雲端元件
- 靜態頁面（本 Demo），可放 Cloudflare Pages；規則式模擬，不呼叫 LLM。
- 設備
- 任何瀏覽器（電腦、手機）。
- 報表
- 無（只有畫面上的模擬報表）。
估計 雲端費用 NT$0／月
階段 2試用版
- 目標
- 換成真的 LLM，用店家真實設定檔跑 D-6／E-5 測試題，A1～A11 稽核全過才往下走。
- 店家要提供
- 填好店家設定檔（時間、價格、設施、退款規則、門檻）；指定 1 位窗口確認答案。
- 雲端元件
- Cloudflare Pages（試聊頁＋後台）、Workers（API）、外部 LLM API 或 Workers AI、KV（設定檔）。
- 設備
- 既有電腦或手機即可。
- 報表
- 可匯出對話與稽核紀錄（CSV）。
估計 約 NT$0～1,500／月（LLM 依用量）
階段 3小規模試營運
- 目標
- 接上真實客人，但交易仍由店員手動處理；觀察轉真人原因與知識缺口。
- 店家要提供
- LINE 官方帳號（店家自有）；值班人員；真人服務時間。不串 POS／訂房系統，AI 產生的訂房／加購單由店員手動建立。
- 雲端元件
- Workers（LINE Webhook）、Durable Objects（每位客人的 session、發話權、待處理佇列）、D1（交接包、案件、稽核）、KV（設定檔）、Pages 後台、LLM。
- 設備
- 只用現有手機／平板接收轉真人通知，不需新設備。
- 報表
- 每日／每週摘要（諮詢量、轉真人、未答問題），推送給店長。
估計 約 NT$1,500～6,000／月（Workers 付費方案＋LLM＋LINE 訊息量）
階段 4正式營運
- 目標
- 訂房、加購、退款直接寫入店家系統，AI 在授權範圍內自動結案。
- 店家要提供
- POS／訂房系統（PMS）API 權限；退款授權額度；管理者帳號啟用雙重驗證（2FA）。
- 雲端元件
- 上述全部＋PMS／POS API 串接、R2（對話附件、照片）、Workers AI 或外部 LLM、排程分析。
- 設備
- 餐飲業：雲端出單機；4G／5G 備援路由器；UPS 不斷電；管理者手機 2FA。
- 報表
- 後台儀表板＋Google Sheets 匯出；連鎖品牌可接 Looker Studio；每月 AI 分析建議。
估計 雲端約 NT$3,000～15,000／月；設備一次性約 NT$10,000～25,000（出單機、備援路由器、UPS）
費用皆為估計，不含導入服務費與人力；實際以 Cloudflare、LLM 供應商、LINE 官方公告與硬體報價為準。
雲端架構圖（正式營運）
Cloudflare 元件AI／Agent店家既有系統與設備使用者通路
資料隔離與個資
多間飯店共用同一套系統，但每間飯店（租戶）的資料彼此看不到；營運方（導入顧問）也只看彙總，不看客人對話內容。本 Demo 用上方「身分（模擬登入）」示範，正式版由伺服器端強制執行。
- 每一筆資料都帶 store_id：D1 的對話、交接包、案件、稽核、訂房單每一列都有
store_id 欄位並建索引。
- 查詢範圍由伺服器決定：Workers 從已驗證的登入身分（店家帳號／LINE 官方帳號 channel）取得租戶，SQL 一律
WHERE store_id = ? 綁定該租戶；不採用用戶端送來的 store_id（網址、表單、對話內容都無效），越權嘗試寫入存取紀錄。
- Session 依租戶分開：每位客人的 Durable Object 以
session:{store_id}:{user_id} 命名，發話權與待處理佇列不會跨店。
- R2／KV 依租戶加前綴：附件放
tenants/{store_id}/…，設定檔與快取用 tenant:{store_id}:…；瀏覽器端的暫存也依 store_id 分鍵（macs_t_{store_id}_…）。
- 報表遮蔽個資：報表與匯出只顯示遮蔽後的姓名（王**）與電話（09xx-xxx-123）；營運方總覽只看彙總數字。
- 營運方查看對話需店家授權：預設鎖住，店家授權有期限、可撤銷，授權與每次查看都留紀錄。
- 保存期限與刪除：依《個人資料保護法》的精神，只蒐集客服必要的資料，訂定保存期限（例如對話保留一定月數後刪除或去識別化），並提供客人查詢、更正、刪除的管道；實際期限與告知內容應由店家依自身情況與法律意見訂定。
- 存取稽核紀錄：登入、查看、匯出、授權、被拒的存取都寫入不可刪改的存取紀錄（誰、何時、看了哪個租戶的什麼）。
- 選配：每個租戶獨立一個 D1 資料庫：對資料隔離要求較高的客戶（例如連鎖品牌或有合約要求），可改為一店一個 D1，費用與維運成本較高。
本 Demo 為前端模擬：身分切換、權限判斷與遮蔽都在瀏覽器執行，用來示範行為，不是真正的身分驗證。以上為一般性做法說明，不構成法律意見。
飯店官網 Demo（虛構）
5 個一頁式官網，房型、設施、交通、入住須知都由同一份店家設定檔（data.js）產生；右下角客服泡泡固定該店 store_id，訪客無法切換。