適用範圍
適用 Odoo 19；各流程須具備相應應用、訂閱、權限及郵件設定。例子均為虛構，介面翻譯可能不同。
研究方法
僅核對 Odoo 19 官方文件；本輪沒有新增 Odoo 產品實測。來源核對僅涵蓋下列 scope。
先選一個有人負責回覆的支援渠道。Helpdesk 提供共享工單記錄，但不代表所有信箱或 WhatsApp 對話都會自動辨認為同一客戶問題。本文依據 Odoo 19 官方文件協助選擇受理方式，沒有實際建立及解決即時工單。
目錄
選擇受理路徑
| 情況 | 建議起點 | 需要確認的條件 |
|---|---|---|
| 問題原本以電郵到達 | Helpdesk 團隊電郵別名 | 入站路由及有人監察 |
| 需要訂單編號及問題描述 | Website Form | 正確網站、必填欄位及已發佈表格 |
| 有人可即時處理對話 | Live Chat | 團隊渠道、操作員及網站／工具設定 |
以虛構換貨查詢為例，收集訂單編號、受影響商品及簡短描述即可；不要要求付款卡資料或密碼。新增公開聯絡渠道前，先訂立誰處理未指派工單，以及「已解決」的定義。
先設定電郵再承諾受理
官方路徑為 Helpdesk → Configuration → Helpdesk Teams。開啟團隊，核對 Channels／Email Alias 設定。文件流程以來信主旨建立工單標題，以內文建立描述。Odoo Online／Odoo.sh 與本地部署的郵件前提不同；本地部署的電郵別名需要外部郵件伺服器設定。
在交接表記錄預期別名及所屬團隊。自訂公司網域是另一個郵件路由決定，不是所有 Odoo 託管別名的必要條件。轉寄電郵未必保留團隊所需結構化資料，因此仍要規定操作員須核對哪個訂單編號。
即時聊天指令與聊天機械人的界線
使用文件列明的 /ticket 前，先在 Helpdesk 團隊 Channels 啟用 Live Chat，設定由此建立的聊天渠道並加入操作員。指令用於實際支援的對話內，不能在 Odoo 任意位置輸入便當作完成工單。對話文字會加入新工單描述；本文沒有執行該指令。
聊天機械人需要 Live Chat 渠道及已設定腳本，不是只安裝 Helpdesk。在渠道的 Channel Rules 選取機械人，按需要設定只在無操作員時啟用。Chatbots 按鈕通往腳本，仍須設計步驟及答案條件。公司網站另需核對 Website → Configuration → Settings → Email & Marketing → Live Chat 的渠道；外部網站需要提供的嵌入工具。這是對接工作，不代表機械人會理解任何支援問題。
定義解決與交接
以下虛構工單表可避免單憑內部假設便結案：
| 檢查點 | 所需記錄 |
|---|---|
| 已收到 | 訂單編號及所報故障 |
| 已指派 | 具名操作員及下次檢視日 |
| 調查中 | 待提供證據及提供者 |
| 已提出方案 | 換貨／維修建議及批准者 |
| 按團隊規則結案 | 已記錄結果並核對客戶通知 |
這些是建議工作規則，不是預設 Helpdesk 階段。結案備註可寫「按議定編號寄出替代品，已於記錄日期通知客戶」，比「完成」具體。是否需要客戶確認，應依服務承諾決定。
內部討論使用 Log note，並檢查提及對象。Odoo 19 提醒，若備註標記外部聯絡人，對方可收到內容及附件電郵。聯絡客戶時，則先檢查 Send message 的收件人及追蹤者。內部備註與真正發送回覆是兩個動作。
排查遺漏與重複查詢
| 現象 | 先檢查 | 處理方式 |
|---|---|---|
| 來信後看不到工單 | 別名路由、目標團隊及權限 | 保留來源信，分清路由與可見性問題 |
| 網站看不到表格 | 網站、發佈狀態及團隊設定 | 修正入口後才宣傳 |
| 看不到聊天 | 渠道、網址規則及嵌入設定 | 核對實際頁面路徑及預期開放情況 |
| 同一問題有多張工單 | 各記錄的客戶編號及渠道 | 先指定統一負責人，再決定如何整合 |
| 團隊已回覆但客戶沒有收到 | 真正寄送訊息、收件人及投遞狀態 | 分清私人備註與外發故障 |
先採用一個團隊及一條受理路徑。可用虛構問題、預期負責人及回覆承諾，請 APAA 整理受理與交接範圍。有人負責腳本及未能回答的情況後，才加入聊天機械人。
參考來源
- Receiving tickets
團隊渠道、電郵別名、/ticket、聊天機械人規則及網站表格
來源查核日期
- Chatter
內部備註、外部聯絡人提及及訊息收件人
來源查核日期