解決方案手冊
這是一份針對 Make 客服分流循環的規劃指南，涵蓋 Custom webhook 觸發器、Run once 測試路徑、HTTP 模組、Make History 驗證、Jodoo 欄位與上線檢查清單。
開啟手冊MAKE + JODOO
使用 Make + Jodoo 的 AI 客服工單分流
透過 Make 搭配 Jodoo 接收客服工單 webhook，以 HTTP 模組傳送結構化分流欄位，將升級處理欄位回寫至 Jodoo，並讓客服後續追蹤清楚可查。
透過 Make webhook 接收工單分類優先順序與狀態將 SLA 欄位寫入 Jodoo讓升級處理的後續追蹤可被持續追蹤在 Make History 中檢視作業、點數與執行狀態
影片導覽
Make 示範中會發生什麼
影片展示一個客服循環：工單進入 Make Custom webhook，Make 透過 HTTP 模組傳送分流欄位，並由 Jodoo 保留升級處理記錄。
工單進入 Make
此情境從 Custom webhook 開始，可接收來自客服表單、入口網站、聊天工具或收件匣事件。
Make 傳送分流欄位
HTTP 模組會送出類別、優先順序、狀態、負責人、SLA 目標、回覆草稿與後續追蹤備註。
History 記錄執行結果
Make History 面板會確認手動執行、作業次數、點數使用量、執行時間與資料傳輸。
Jodoo 儲存工單
結構化結果會寫入 Jodoo 客服應用程式，讓團隊可以篩選、指派並檢視。
重要工單保持可見
升級工單可從 Jodoo 記錄進一步進入負責人佇列、SLA 檢視、提醒與儀表板。
展示摘要
Make 負責工單分流，Jodoo 追蹤升級處理
當您的團隊希望先用可視化的 Make 情境處理客服進件，再由 Jodoo 作為升級後續追蹤的系統記錄時，這種做法特別實用。
Custom webhook 觸發
客服資料 payload 透過 Custom webhook 進入 Make。
HTTP 回寫
Make 的 HTTP 模組會傳送結構化的客服分流欄位。
History 成功執行
Make History 顯示手動執行已成功完成，共有兩次作業。
情境使用情況
Make 執行會記錄此客服流程測試的作業次數、點數、執行時間與資料傳輸。
Jodoo 回寫
Jodoo 會儲存優先順序、狀態、SLA 目標、提出人與類別欄位。
可重複使用的循環
Make 執行情境，Jodoo 保留客服記錄。
工作流程工具包
建立相同的 Make 客服分流循環
先檢查客服欄位對應、複製工作流程配方，再使用 Jodoo 應用程式藍圖，之後再把 Make webhook 調整為您自己的客服來源。
您的團隊可重複使用的內容
Make 透過 Custom webhook 接收工單事件，再透過 HTTP 模組傳送結構化分流輸出，並在 History 中記錄作業、點數與執行時間。Jodoo 會保留穩定可用的客服記錄、升級狀態、負責人佇列與稽核軌跡。
商務工作流程Jodoo 欄位模型代理提示詞上線檢查清單
可重複使用的工作流程
工作流程負責判斷，Jodoo 讓工作持續推進。
- 01
Make webhook
表單、入口網站、收件匣、聊天記錄或內部系統
- 02
Make 情境
接收工單 webhook、執行 HTTP 回寫，並在 History 中確認執行結果
- 03
HTTP 模組
以 JSON post request 傳送分流欄位並解析回應
- 04
Make History
顯示成功狀態、作業、點數、執行時間與資料傳輸
- 05
Jodoo 回寫
建立客服工單並回傳 data ID
- 06
客服後續追蹤
SLA 檢視、負責人佇列、升級狀態與稽核軌跡
工作流程循環
從 Make webhook 到已分派的升級處理
客服申請會從表單、入口網站、收件匣、聊天工具或內部系統送到 Make Custom webhook。
Run once 會讓 Webhooks 模組進入等待狀態，以便擷取傳入的測試 payload。
Make 情境會將事件清楚呈現為兩個模組流程：Webhooks app 觸發器與 HTTP app 回寫。
HTTP 模組使用 JSON body、post method、parse response，以及已儲存的 URL；當臨時端點變更時，必須重新確認。
HTTP 請求會以 JSON 傳送問題類別、優先順序、SLA 目標、狀態、負責人、回覆草稿與後續追蹤備註。
Make History 會記錄手動執行、作業次數、點數使用量、執行時間與資料傳輸。
結構化結果會送往 Jodoo 回寫端點或安全的中介層。
Jodoo 會建立客服工單記錄，並讓其可用於 SLA 檢視、負責人佇列、儀表板與稽核歷程。
欄位對應
代理輸出轉為 Jodoo 欄位
| 代理或來源資料 | Jodoo 記錄欄位 |
|---|---|
| requester_name, requester_email, requester_department | 申請人姓名、申請人電子郵件、申請人部門 |
| issue_category, affected_asset | 問題類別、受影響資產 |
| priority, sla_target, ticket_status | 優先順序、SLA 目標日期、工單狀態 |
| assigned_owner, routing_reason, follow_up_note | 指派負責人、處理備註、後續追蹤備註 |
AI 代理配方
提示詞與結構化輸出
工作流程角色
接收傳入的客服工單 payload，並回傳 Jodoo 可儲存、分派與報表分析的結構化欄位。
分流指示
依據緊急程度、影響範圍、類別、SLA 風險與負責歸屬來分類工單。請讓輸出格式保持穩定，以利 Make HTTP 回寫步驟使用。
必要輸出
請回傳 ticket_summary、issue_category、priority、sla_target、assigned_owner、ticket_status、response_draft、follow_up_note 與 routing_reason。
Make 模組規格
在將工作流程交接給客服團隊之前，請明確確認 Webhooks bundle、HTTP method、JSON content type、parse response 設定、已儲存的端點 URL，以及 Run once 驗證。
{
"issue_category": "存取與權限",
"priority": "緊急",
"sla_target": "2026-06-04 09:00",
"assigned_owner": "支援升級 / 身分團隊",
"ticket_status": "已升級"
}Jodoo 入門應用程式
Make 客服工單分流入門應用程式
設定 Make Custom webhook 與 Jodoo 回寫工作流程時，可使用此欄位模型。
包含的欄位
- 工單編號
- 申請人姓名
- 申請人電子郵件
- 申請人部門
- 問題類別
- 受影響資產
- 優先順序
- SLA 目標日期
- 工單狀態
- 指派負責人
- 問題描述
- 處理備註
- 後續追蹤備註
- 附件
- 提交日期
- 原始代理輸出
建議檢視
- 重大升級案件
- SLA 風險
- 負責人佇列
- 需要更多資訊
- Make 執行檢查
- 所有客服工單
自動化規則
- 在 Make HTTP 模組完成後，建立或更新 Jodoo 客服工單記錄。
- 當優先順序為 Critical 或狀態為 Escalated 時，通知指派負責人。
- 將資訊不足的工單移至檢查佇列。
- 當 Make History 顯示 HTTP 作業失敗時，將記錄標示為待檢查。
- 在稽核軌跡中保留原始工作流程輸出。
上線檢查清單
正式上線前需確認的事項
- 定義客服類別、SLA 目標與升級負責人。
- 決定哪些工單來源應觸發 Make webhook。
- 在每次 Run once 測試前，確認 HTTP 模組 URL 已儲存。
- 使用臨時 tunnel 時，請檢查端點健康狀態。
- 將每個 Make 輸出欄位對應到 Jodoo 工單欄位。
- 在正式流量前，先用模擬工單進行測試。
- 加入錯誤處理、重試提醒與人工檢查佇列。
工作流程
從 Make webhook 到可追蹤的升級處理
Make 處理傳入事件與回寫步驟。Jodoo 儲存客服工單欄位，讓團隊可以檢視、篩選並採取後續行動。
客服申請會從表單、入口網站、收件匣、聊天工具或內部系統送到 Make Custom webhook。
Run once 會讓 Webhooks 模組進入等待狀態，以便擷取傳入的測試 payload。
Make 情境會將事件清楚呈現為兩個模組流程：Webhooks app 觸發器與 HTTP app 回寫。
HTTP 模組使用 JSON body、post method、parse response，以及已儲存的 URL；當臨時端點變更時，必須重新確認。
HTTP 請求會以 JSON 傳送問題類別、優先順序、SLA 目標、狀態、負責人、回覆草稿與後續追蹤備註。
Make History 會記錄手動執行、作業次數、點數使用量、執行時間與資料傳輸。
結構化結果會送往 Jodoo 回寫端點或安全的中介層。
Jodoo 會建立客服工單記錄，並讓其可用於 SLA 檢視、負責人佇列、儀表板與稽核歷程。
Jodoo 記錄
Jodoo 儲存的內容
在 Make 執行後，Jodoo 會保留穩定可用的客服欄位：提出人、類別、受影響資產、優先順序、SLA 目標、狀態、負責人與後續追蹤備註。
工單編號申請人資料問題類別受影響資產優先順序SLA 目標日期工單狀態指派負責人問題描述處理備註後續追蹤備註原始工作流程輸出
實際執行
Make 情境已將客服工單寫入 Jodoo
這些截圖使用模擬客服資料，展示 Make 情境畫布、成功的 Make History 執行記錄，以及回寫後的 Jodoo 客服工單資料表。
Make 情境設定
Make 畫布使用 Custom webhook 與 HTTP 模組來呼叫 Jodoo 回寫端點。
成功的 Make History 執行
Make History 顯示客服情境已成功完成，包含作業、點數、執行時間與資料傳輸。
Jodoo 回寫
經 Make 分流的工單已出現在 Jodoo 中，包含提出人、類別、優先順序、SLA 目標與狀態欄位。
常見問題
常見問題
了解如何將代理平台搭配 Jodoo 記錄、工作流程與應用程式範本使用的相關解答。
這個 Make 客服工作流程是否已完成端對端測試？
是的。Make 情境的 History 記錄顯示一次成功的手動執行，而 Jodoo 資料表也顯示由該次執行建立的模擬 Critical 客服工單。
這需要付費版 Make 方案嗎？
此次驗證使用的是免費 Make 帳號與模擬客服資料。正式使用時，成本可能會依作業量、串接服務與端點使用情況而有所不同。
工單來源可以來自 Jodoo 以外的系統嗎？
可以。觸發來源可以是任何能將 webhook payload 傳送到 Make 的系統，之後再把結果寫入 Jodoo。
團隊可以在 Make 中加入模型驅動的代理步驟嗎？
可以。已驗證的路徑採用穩定的 webhook 與 HTTP 回寫流程。只要類別、優先順序、SLA、負責人與狀態欄位保持可預測，團隊也可以加入 Make AI 步驟或串接模型呼叫。
執行 Make 情境前應該先檢查什麼？
請確認 Custom webhook 正在等待資料、HTTP 模組 URL 已儲存、請求內容為 JSON，若使用臨時 tunnel，也要確認端點健康檢查已通過。
這和以程式碼為主的 webhook 工作流程有何不同？
Make 會把客服流程以畫布上的模組形式清楚呈現。建置人員可以先看到 Webhooks 觸發器、HTTP 請求、作業次數、點數使用量與 History 結果，再由 Jodoo 團隊檢視工單。
如果 Make 的 HTTP 模組失敗會怎樣？
請將此次執行視為尚未完成。在蒐集截圖或將此工作流程用於真實客服流量之前，請先檢查已儲存的 URL、JSON body、端點健康狀態與 Make History 錯誤。
測試期間 Make 情境可以維持未啟用嗎？
可以。手動驗證時，Run once 可以在不啟用排程或常駐情境的情況下等待 webhook 事件。正式上線前，請在端點健康狀態、配額、重試機制與錯誤通知都準備完成後再啟用情境。
哪些 Make 畫面有助於排查客服流程問題？
可使用 Scenario Usage、History、模組 bundle 輸出、HTTP 狀態碼、資料傳輸、作業次數與點數使用量，確認工單已通過 Make，再去檢查 Jodoo 記錄。
為什麼要把結果存到 Jodoo，而不是只看 Make History？
Make History 對建置人員很有幫助，而 Jodoo 則能提供客服團隊所需的欄位、檢視、負責人、SLA 佇列、儀表板、工作流程狀態與稽核脈絡。
下一步
把 Make 客服進件變成可重複使用的分流工作流程
您可以先從客服工單分流開始，再把同樣模式延伸到 IT 申請、Customer Success 升級案件、錯誤回報進件或現場服務問題。