跳到內容
Dot Agents文件
進入 Dot Agents

飯店

飯店週一早上：評論 agent 整理上週評論、問清楚發生什麼事再寫回覆草稿，房價 agent 比完競品給一筆調價等你按

兩位 agent 各自被排程叫醒：評論讀上週五則住客評論，負評先到群組問客房與餐飲當時發生什麼事，再為每則寫 80 字內的回覆草稿、寫一頁週報；房價比對兩家競品與自家房況，只有一筆符合規則，寫一頁建議後停在審核頁等人按。從排程到點到兩件事做完，3 分半。回覆與調價都是草稿，人按了才算數。

5 則
回覆草稿等審核
1 筆
調價建議
3 分半
兩件事從排程到點到做完

這是誰、遇到什麼

同一家海邊飯店。週一早上經理要做兩件事：回上週各平台的評論，和看下週末的房價要不要調。回評論要先問房務「那間冷氣怎麼了」、問餐廳「那天早餐怎麼了」，不然回出去的是客套話；調價要開三個網站抄競品的價格，再對自家房況。兩件事加起來一個上午，常常拖到週三才回評論。

資料都在，就是散：評論在各平台，事件在維修紀錄，競品價格查得到，自家房況在訂房系統。缺的是每週一早上有人把它們放在一起看。

讓兩位 agent 分工

agent 是你在 Dot Agents 裡建立的 AI 同事。這家飯店建了評論與房價兩位，放在群組「營運組」，客房與餐飲也在裡面，方便問。

飯店評論與房價團隊實際介面
評論住客評論回覆與週報
房價競品比價與調價建議
客房房間的維修紀錄
餐飲餐廳的處理紀錄
評論整理評論與回覆草稿，房價比競品給調價建議；客房與餐飲在群組裡回答「當時發生什麼事」。
評論住客評論回覆與週報每週一 08:00 被排程叫醒。讀「住客評論」裡未回覆的評論，負評先問客房或餐飲實際狀況，再為每則寫回覆草稿寫回那一列、把狀態改成「待審核」，最後寫一頁週報。給它：資料庫「住客評論」、工作區，而且「修改資料列」設成需核准。它的靈魂文件寫明：草稿不承諾賠償或折扣，不對外提房號。
房價競品比價與調價建議每週一 08:30 被排程叫醒。比對「競品房價」與「房況與房價」，照規則判斷哪幾筆要調，先寫一頁建議，再改牌價。給它：這兩個資料庫、工作區，「修改資料列」設成需核准。規則寫在靈魂文件裡：剩不到三間且便宜超過一成就調漲，剩超過八間且比競品貴就調降，單次調幅不超過兩成，訂房率超過八成的日期不動。
客房、餐飲同一家飯店的同事。被問到某間房、某天早餐發生什麼事時，查「維修紀錄」回日期、問題、處理結果；紀錄沒寫的就說沒寫，不推測。

一件事怎麼在他們之間接力

沒有人開口。兩個排程相隔半小時到點，評論在群組「營運組」問客房與餐飲，房價另開一段同事往來問訂房，六張核准卡在審核頁等主管。

  1. 10:41
    排程「每週一評論整理」到點
    排程「每週一評論整理」排程到點評論「今天是週一，請整理上週的住客評論：準備回覆草稿並寫週報。」
  2. 資料庫「住客評論」查資料
    資料庫「住客評論」評論查資料上週 5 則未回覆：兩則五星、一則四星、一則三星（週末早餐熱食補不上）、一則兩星（冷氣整晚異音）。
  3. 群組「營運組」問
    群組「營運組」評論問客房@客房：10/7 那則「冷氣整晚嗡嗡聲、反映後隔天才處理」，實際狀況與處理？不給房號。
  4. 問
    評論問餐飲@餐飲：10/9 那則「週末早餐熱食補不上」，實際狀況？兩個請求一起發。
  5. 回報
    客房回報評論維修紀錄：10/6 接獲異音反映，10/8 更換風扇馬達，測試正常；延後處理的原因紀錄沒寫，勿自行推測。
  6. 回報
    餐飲回報評論10/5 週末 08:30 曾發生熱食補餐慢；10/11 起週末加開一條補餐線、增派一位人員；紀錄沒寫等候時間，勿確認「十五分鐘」。
  7. 10:42
    排程「每週一房價比對」到點
    排程「每週一房價比對」排程到點房價「今天是週一，請比對下週末的競品房價並提出調價建議。」
  8. 審核頁等核准
    審核頁評論等核准主管第一則回覆草稿要寫進「住客評論」那一列、狀態改「待審核」。修改資料列要核准，每則一張卡。
  9. 資料庫「競品房價」「房況與房價」查資料
    資料庫「競品房價」「房況與房價」房價查資料六筆房型與日期逐一比：10/23 標準雙人房剩 9 間、牌價 3,200 高於競品均價 2,850；其餘五筆都不到門檻。
  10. 同事往來「房價 ↔ 訂房」問
    同事往來「房價 ↔ 訂房」房價問訂房10/23 的訂房率有沒有超過八成？訂房查「訂單」：約一成，可以調。
  11. 10:43
    工作區「下週末房價建議」寫頁
    工作區「下週末房價建議」房價寫頁六筆各一行：現價、競品均價、建議價、調或不調、理由。
  12. 審核頁等核准
    審核頁房價等核准主管10/23 標準雙人房牌價 3,200 改 2,850。核准卡並列原本與改成。
  13. 核准
    主管核准評論五則回覆草稿各按一次。
  14. 核准
    主管核准房價那一筆調價按一次，牌價寫入。
  15. 10:44
    工作區「住客評論週報」寫頁
    工作區「住客評論週報」評論寫頁平均 3.8 分、最常被提到的三件事、本週要改善的事、每則草稿一行摘要。
  16. 執行紀錄回報
    執行紀錄評論回報主管「5 則草稿已寫入、狀態待審核；已向客房、餐飲確認兩則負評；週報在這裡。」距離排程到點 3 分半。
  17. 回報
    房價回報主管「已調整 1 筆：10/23 標準雙人房 3,200 降至 2,850；其餘 5 筆維持。明細在這裡。」

經理週一早上看到的是：五則回覆草稿等著逐則看、一筆調價等著按、兩頁可以直接拿去早會講。

主控台 · 審核(評論回覆與調價)實際介面
審核頁上的兩張卡：評論要把回覆草稿寫進那一則評論、狀態改成待審核；房價要把一筆牌價從 3,200 改成 2,850。原本與改成並列，看完再按。

系統、接口、把關

步驟對接系統需要的接口權限等級
1每週一叫醒兩位排程「每週一評論整理」08:00、「每週一房價比對」08:30，各自的執行紀錄看得到做了什麼規則
2讀上週的評論Google、Booking.com、Agoda有串接的用連接器把評論同步進「住客評論」；沒有就由同仁每天貼進表唯讀
3問當時發生什麼事資料庫「維修紀錄」客房與餐飲查紀錄回答；紀錄沒寫的說沒寫唯讀
4寫回覆草稿資料庫「住客評論」評論改那一列的「回覆草稿」與「回覆狀態」；「修改資料列」設需核准；貼到平台仍由人做人核准
5比對競品房價資料庫「競品房價」有比價服務的用連接器同步；沒有就每天手動填唯讀
6改牌價訂房系統或資料庫「房況與房價」房價改那幾列的牌價；「修改資料列」設需核准，主管按了才改人核准
7週報與調價建議工作區兩頁先寫好，早會直接用寫入草稿

讀得多，寫得少：回覆是草稿、調價是建議，按下去的都是人。

出狀況時

「競品房價」表裡下週末的價格還是上週填的。房價不會拿舊價格算出一筆調價。它在建議頁最上面寫「競品資料是 10/5 的，建議先更新再決定」，六筆全部標「維持」，不送任何調價卡。主管看到的是一頁提醒，不是一筆錯的調價。

用到哪些功能

這個場景跨了 6 個系統：三個評論平台、「住客評論」與「維修紀錄」資料庫、「競品房價」資料庫、「房況與房價」資料庫、工作區。

排程兩個排程每週一到點，各有自己的執行紀錄。群組協作評論在群組問客房與餐飲，房價另開同事往來問訂房；誰回了什麼都在時間線上。審核回覆草稿與調價都是「修改資料列」，停下來等人；核准卡並列原本與改成。資料庫住客評論、維修紀錄、競品房價、房況與房價都是工作區裡的表。工作區週報與房價建議是兩頁文件，早會直接開。連接器有串接的飯店把評論平台與比價服務接進來，同仁就不用貼。

怎麼設定

  1. 主控台 → Agent → 新增建評論與房價兩位，各寫一份靈魂文件。評論的要寫：負評先問客房或餐飲、草稿不承諾賠償、不提房號；房價的要把調價規則一條一條寫清楚。
  2. 工作區 → 新增 → 資料庫建「住客評論」（含「回覆草稿」「回覆狀態」兩欄）、「維修紀錄」、「競品房價」，分享給對應的 agent。
  3. 評論、房價 → 工具分頁把「修改資料列」設成需核准。
  4. 評論 → 排程分頁新增「每週一評論整理」，每週一 08:00；房價 新增「每週一房價比對」，每週一 08:30。
  5. 群組 → 新群組建「營運組」，四位都加進去，各寫一句負責什麼。
  6. 按「立即執行」試一次到群組頁看評論怎麼問客房與餐飲，到審核頁逐張看回覆草稿與那一筆調價。
每則回覆一張卡

評論每寫一則草稿就停一次，五則就是五張卡。想一次看完再決定，可以把評論的「修改資料列」改成允許：草稿照樣寫進表、狀態照樣是「待審核」，人到表裡逐則看過再貼到平台。