解決方案手冊
Make 客戶導入交接迴圈的規劃指南，包含設定、Jodoo 欄位、驗證記錄與上線推廣備註。
開啟手冊MAKE + JODOO
使用 Make + Jodoo 的 AI 客戶導入交接
了解 Make 與 Jodoo 如何處理客戶導入交接：檢視來源申請、回傳結構化決策欄位、將結果寫入 Jodoo，並讓負責人、狀態與下一步行動保持可見。
1
以一致的評估準則檢視客戶導入資料
2
將導入階段、風險等級、缺漏資訊、啟動會議優先順序、導入負責人、客戶成功負責人與下一步最佳行動寫入 Jodoo
3
讓負責人佇列與後續追蹤狀態保持可見
4
先使用 Make 驗證成果，再將工作流程調整至正式資料來源
5
公開驗證使用 Make Run once 模式，因此擷取的截圖可在情境歷史中顯示 webhook bundle、模組泡泡、操作次數與 HTTP 回應。
影片導覽
Make 示範中會發生什麼
影片展示 Make 如何處理 Aster Retail Group 進入導入流程的情境，包含已簽方案脈絡、上線目標、利害關係人備註、導入風險與缺漏的整合細節，接著由 Jodoo 儲存營運記錄。
Custom webhook 接收申請
Aster Retail Group 帶著已簽方案脈絡、上線目標、利害關係人備註、導入風險與缺漏的整合細節進入導入流程。
Make 準備結構化審查欄位
工作流程會明確保留導入階段、風險等級、缺漏資訊、啟動會議優先順序、導入負責人、客戶成功負責人與下一步最佳行動，而不是只回傳一段鬆散文字。
HTTP 模組寫入 Jodoo
經測試的執行會將審查輸出送至 Jodoo，並從橋接層接收 Jodoo 資料 ID。
Make 驗證可持續檢視
公開驗證使用 Make Run once 模式，因此擷取的截圖可在情境歷史中顯示 webhook bundle、模組泡泡、操作次數與 HTTP 回應。
Jodoo 保留團隊記錄
Jodoo 應用程式儲存客戶名稱、方案或套裝、合約金額、主要聯絡人、上線目標、導入負責人、導入階段，供後續檢視與追蹤。
展示摘要
Make 檢視申請，Jodoo 追蹤後續行動
此導入方式適合需要可視化情境畫布、Run once 測試與模組歷史的營運團隊。頁面會保留可視化情境設定、實際執行結果與 Jodoo 回寫畫面。HTTP 模組證據是可視化的：方法、端點、body 類型、解析後回應與完成狀態，都能在不開啟程式碼編輯器的情況下檢視。
Make 情境
Make Custom webhook 接收範例 payload，HTTP 模組將結構化欄位送入 Jodoo。
結構化決策
工作流程會回傳 Aster Retail Group 的導入階段、風險等級、缺漏資訊、啟動會議優先順序、導入負責人、客戶成功負責人與下一步最佳行動。
Make 成功執行
Make 執行歷史會顯示 HTTP 模組完成狀態、操作細節與 Jodoo 資料 ID 回應。
Make 導入細節
從 Custom webhook 開始，貼上範例申請，讓 Make 推斷 bundle，再將決策欄位對應到 HTTP 模組 body。
客戶導入配方細節
針對客戶導入交接，Make bundle 應在 HTTP 模組寫入 Jodoo 前，讓客戶名稱、方案、上線目標、利害關係人備註、啟動會議風險與導入負責人保持可見。
Jodoo 回寫
Jodoo 會儲存客戶導入記錄，並讓下一步行動保持可見。
營運後續追蹤
建議的下一步行動是安排啟動會議、指派導入負責人，並在上線規劃前收集整合需求。
可重複使用套件
重點套件包含手冊、Jodoo 欄位藍圖與 Make 工作流程配方。
平台設定說明
Make 的特定特色
Jodoo 記錄模型可以維持一致，但各個代理平台的建置方式、測試檢視與正式上線交接流程各不相同。
設定驗證
此驗證使用 Run once，讓傳入 bundle 與 HTTP 回應保持可見。
動作路徑
HTTP 模組會讓方法、URL、body 類型與回應解析保持可檢視。
配方重點
情境歷史會提供操作、時間長度與回寫回應的可視化記錄。
正式環境規劃
正式環境規劃應涵蓋 webhook 管理責任、分派器、錯誤處理器與操作用量。
證據細節
公開驗證使用 Make Run once 模式，因此擷取的截圖可在情境歷史中顯示 webhook bundle、模組泡泡、操作次數與 HTTP 回應。
執行證據
HTTP 模組證據是可視化的：方法、端點、body 類型、解析後回應與完成狀態，都能在不開啟程式碼編輯器的情況下檢視。
建置細節
從 Custom webhook 開始，貼上範例申請，讓 Make 推斷 bundle，再將決策欄位對應到 HTTP 模組 body。
導入路徑
當高價值合約、緊急發票或缺漏資訊案例需要不同的 Jodoo 佇列時，可在基礎驗證後使用分派器。
防護機制
將 Run once 驗證轉為啟用中的工作流程前，請先檢視操作用量、webhook 管理責任與情境排程。
審查控制
在 HTTP 模組周圍加入錯誤處理器，讓失敗的回寫可以重試，或移至人工審查路徑。
情境配方
針對客戶導入交接，Make bundle 應在 HTTP 模組寫入 Jodoo 前，讓客戶名稱、方案、上線目標、利害關係人備註、啟動會議風險與導入負責人保持可見。
工作流程調整
分派器可將企業客戶、缺漏導入資料與緊急上線日期分流到不同的導入佇列。
工作流程工具包
建立相同的客戶導入交接迴圈
檢視手冊、複製工作流程配方，並在調整 Make 工作流程時使用 Jodoo 欄位模型。
可重複使用的工作流程
工作流程負責判斷，Jodoo 讓工作持續推進。
- 01
Custom webhook
以 Aster Retail Group 啟動客戶導入測試。從 Custom webhook 開始，貼上範例申請，讓 Make 推斷 bundle，再將決策欄位對應到 HTTP 模組 body。
- 02
Make 情境
Make Custom webhook 接收範例 payload，HTTP 模組將結構化欄位送入 Jodoo。
- 03
HTTP 模組
將結構化 JSON 送至 Jodoo 回寫橋接層。HTTP 模組證據是可視化的：方法、端點、body 類型、解析後回應與完成狀態，都能在不開啟程式碼編輯器的情況下檢視。
- 04
驗證回應
顯示平台成功執行與 Jodoo 資料 ID。公開驗證使用 Make Run once 模式，因此擷取的截圖可在情境歷史中顯示 webhook bundle、模組泡泡、操作次數與 HTTP 回應。
- 05
Jodoo 佇列
儲存欄位以供負責人檢視、狀態追蹤與後續追蹤。將 Run once 驗證轉為啟用中的工作流程前，請先檢視操作用量、webhook 管理責任與情境排程。
工作流程循環
從 Make 客戶導入交接到 Jodoo
Custom webhook 先以合成資料接收或啟動客戶導入交接。
Make 套用聚焦的審查指示，並回傳導入階段、風險等級、缺漏資訊、啟動會議優先順序、導入負責人、客戶成功負責人與下一步最佳行動。
HTTP 模組將結構化輸出送至 Jodoo 回寫橋接層，並接收資料 ID。
針對客戶導入交接，Make bundle 應在 HTTP 模組寫入 Jodoo 前，讓客戶名稱、方案、上線目標、利害關係人備註、啟動會議風險與導入負責人保持可見。
分派器可將企業客戶、缺漏導入資料與緊急上線日期分流到不同的導入佇列。
情境歷史可協助客戶成功主管說明從銷售端傳入了什麼、工作流程做了什麼決策，以及 Jodoo 儲存了哪些後續追蹤內容。
驗證完成後，Make 可加入 CRM 查詢、Slack 通知與高風險交接的升級分派。
從 Custom webhook 開始，貼上範例申請，讓 Make 推斷 bundle，再將決策欄位對應到 HTTP 模組 body。
當高價值合約、緊急發票或缺漏資訊案例需要不同的 Jodoo 佇列時，可在基礎驗證後使用分派器。
Jodoo 會建立「客戶導入追蹤器」記錄，並儲存客戶名稱、方案或套裝、合約金額、主要聯絡人、上線目標、導入負責人、導入階段、風險等級。
團隊檢視佇列、指派負責權，並完成下一步行動：安排啟動會議、指派導入負責人，並在上線規劃前收集整合需求。
將 Run once 驗證轉為啟用中的工作流程前，請先檢視操作用量、webhook 管理責任與情境排程。
在 HTTP 模組周圍加入錯誤處理器，讓失敗的回寫可以重試，或移至人工審查路徑。
欄位對應
代理輸出轉為 Jodoo 欄位
| 代理或來源資料 | Jodoo 記錄欄位 |
|---|---|
| 來源申請詳細資料 | 客戶名稱、方案或套裝、合約金額、主要聯絡人 |
| 審查決策欄位 | 導入階段、風險等級、缺漏資訊、啟動會議優先順序、交接摘要 |
| 工作流程回應 | 來源平台、原始工作流程輸出 |
AI 代理配方
提示詞與結構化輸出
Make 角色
檢視一筆客戶導入交接申請，並回傳 Jodoo 可儲存、分派與報表化的結構化欄位。從 Custom webhook 開始，貼上範例申請，讓 Make 推斷 bundle，再將決策欄位對應到 HTTP 模組 body。
審查指示
使用 Aster Retail Group 的範例脈絡，決定導入階段、風險等級、缺漏資訊、啟動會議優先順序、導入負責人、客戶成功負責人與下一步最佳行動，並讓建議的下一步行動保持具體。針對客戶導入交接，Make bundle 應在 HTTP 模組寫入 Jodoo 前，讓客戶名稱、方案、上線目標、利害關係人備註、啟動會議風險與導入負責人保持可見。
回寫合約
透過 HTTP 模組送出可預期的 JSON 物件；Jodoo 每次執行都應收到相同欄位名稱。當營運團隊希望用畫布、篩選器、分派器與模組層級執行歷史來說明交接時，Make 很有幫助。
必要輸出
回傳導入階段、風險等級、缺漏資訊、啟動會議優先順序、導入負責人、客戶成功負責人與下一步最佳行動，以及 source_platform、agent_confidence 和原始工作流程輸出，作為稽核脈絡。
Make 控制項
將 Run once 驗證轉為啟用中的工作流程前，請先檢視操作用量、webhook 管理責任與情境排程。在 HTTP 模組周圍加入錯誤處理器，讓失敗的回寫可以重試，或移至人工審查路徑。記錄 webhook URL 的負責人，以及誰有權編輯承載正式申請資料的模組。
客戶導入實作備註
針對客戶導入交接，Make bundle 應在 HTTP 模組寫入 Jodoo 前，讓客戶名稱、方案、上線目標、利害關係人備註、啟動會議風險與導入負責人保持可見。分派器可將企業客戶、缺漏導入資料與緊急上線日期分流到不同的導入佇列。情境歷史可協助客戶成功主管說明從銷售端傳入了什麼、工作流程做了什麼決策，以及 Jodoo 儲存了哪些後續追蹤內容。驗證完成後，Make 可加入 CRM 查詢、Slack 通知與高風險交接的升級分派。
{
"customer_name": "Aster Retail Group",
"plan_or_package": "成長營運導入",
"contract_value": 42000,
"primary_contact": "Jordan Lee",
"go_live_target": "2026-07-15",
"implementation_owner": "導入營運團隊",
"onboarding_stage": "啟動會議準備",
"risk_level": "中",
"missing_information": "整合需求與資料移轉負責人",
"kickoff_priority": "高",
"customer_success_owner": "客戶成功團隊主管",
"next_best_action": "安排啟動會議並收集整合需求"
}Jodoo 入門應用程式
客戶導入入門應用程式
為您的團隊調整客戶導入交接工作流程時，可使用此欄位模型、檢視與自動化設定。
包含的欄位
- 客戶名稱
- 方案或套裝
- 合約金額
- 主要聯絡人
- 上線目標
- 導入負責人
- 導入階段
- 風險等級
- 缺漏資訊
- 啟動會議優先順序
- 交接摘要
- 下一步最佳行動
- 客戶成功負責人
- 來源平台
- 原始工作流程輸出
建議檢視
- 新客戶交接
- 可安排啟動會議
- 缺漏資訊
- 高風險導入
- 所有導入記錄
自動化規則
- Make 回傳結構化輸出後建立 Jodoo 記錄。
- 將高優先順序或例外記錄移至正確的負責人佇列。
- 當存在缺漏資訊或暫停原因時，通知建議負責人。
- 保留原始工作流程輸出作為稽核脈絡。
上線檢查清單
正式上線前需確認的事項
- 啟用情境前，先將合成資料送至 Custom webhook。
- 編輯後重新開啟 HTTP 模組，並確認已儲存的 JSON 對應。
- 使用情境歷史確認狀態、操作與回應 body。
- 等基礎回寫穩定後，再加入分派器、篩選器與通知。
- 將 Run once 驗證轉為啟用中的工作流程前，請先檢視操作用量、webhook 管理責任與情境排程。
- 在 HTTP 模組周圍加入錯誤處理器，讓失敗的回寫可以重試，或移至人工審查路徑。
- 記錄 webhook URL 的負責人，以及誰有權編輯承載正式申請資料的模組。
- 分派器可將企業客戶、缺漏導入資料與緊急上線日期分流到不同的導入佇列。
- 情境歷史可協助客戶成功主管說明從銷售端傳入了什麼、工作流程做了什麼決策，以及 Jodoo 儲存了哪些後續追蹤內容。
- 驗證完成後，Make 可加入 CRM 查詢、Slack 通知與高風險交接的升級分派。
工作流程
從 Make 客戶導入到 Jodoo 記錄
Make 處理可視化情境；Jodoo 保留團隊可篩選、指派與檢視的記錄。
Custom webhook 先以合成資料接收或啟動客戶導入交接。
Make 套用聚焦的審查指示，並回傳導入階段、風險等級、缺漏資訊、啟動會議優先順序、導入負責人、客戶成功負責人與下一步最佳行動。
HTTP 模組將結構化輸出送至 Jodoo 回寫橋接層，並接收資料 ID。
針對客戶導入交接，Make bundle 應在 HTTP 模組寫入 Jodoo 前，讓客戶名稱、方案、上線目標、利害關係人備註、啟動會議風險與導入負責人保持可見。
分派器可將企業客戶、缺漏導入資料與緊急上線日期分流到不同的導入佇列。
情境歷史可協助客戶成功主管說明從銷售端傳入了什麼、工作流程做了什麼決策，以及 Jodoo 儲存了哪些後續追蹤內容。
驗證完成後，Make 可加入 CRM 查詢、Slack 通知與高風險交接的升級分派。
從 Custom webhook 開始，貼上範例申請，讓 Make 推斷 bundle，再將決策欄位對應到 HTTP 模組 body。
當高價值合約、緊急發票或缺漏資訊案例需要不同的 Jodoo 佇列時，可在基礎驗證後使用分派器。
Jodoo 會建立「客戶導入追蹤器」記錄，並儲存客戶名稱、方案或套裝、合約金額、主要聯絡人、上線目標、導入負責人、導入階段、風險等級。
團隊檢視佇列、指派負責權，並完成下一步行動：安排啟動會議、指派導入負責人，並在上線規劃前收集整合需求。
將 Run once 驗證轉為啟用中的工作流程前，請先檢視操作用量、webhook 管理責任與情境排程。
在 HTTP 模組周圍加入錯誤處理器，讓失敗的回寫可以重試，或移至人工審查路徑。
Jodoo 記錄
Jodoo 儲存的內容
工作流程執行後，Jodoo 會保留可持續使用的客戶導入欄位：客戶名稱、方案或套裝、合約金額、主要聯絡人、上線目標、導入負責人、導入階段、風險等級。
客戶名稱方案或套裝合約金額主要聯絡人上線目標導入負責人導入階段風險等級缺漏資訊啟動會議優先順序交接摘要下一步最佳行動客戶成功負責人來源平台原始工作流程輸出
真實測試執行
Make 工作流程已將客戶導入寫入 Jodoo
截圖使用合成資料，並展示 Make 設定、成功執行，以及由工作流程建立的 Jodoo 資料列。
Make 情境設定
Make Custom webhook 接收範例 payload，HTTP 模組將結構化欄位送入 Jodoo。
Make 成功執行
Make 執行歷史會顯示 HTTP 模組完成狀態、操作細節與 Jodoo 資料 ID 回應。
Jodoo 回寫
客戶導入交接已寫入 Jodoo，並顯示客戶名稱、方案或套裝、合約金額、主要聯絡人、上線目標、導入負責人等欄位。
常見問題
常見問題
了解如何將代理平台搭配 Jodoo 記錄、工作流程與應用程式範本使用的相關解答。
這個 Make 客戶導入交接是否已完成端到端測試？
是。此驗證使用合成資料、真實 Make 執行，以及含驗證清單的已確認 Jodoo 回寫截圖。
為什麼使用 Make 處理客戶導入交接？
當營運團隊需要可視化情境畫布、Run once 測試與模組歷史時，可使用 Make。接著由 Jodoo 保留可持續使用的記錄，供檢視與後續追蹤。
這個 Make 實作與其他平台範例有何不同？
公開驗證使用 Make Run once 模式，因此擷取的截圖可在情境歷史中顯示 webhook bundle、模組泡泡、操作次數與 HTTP 回應。從 Custom webhook 開始，貼上範例申請，讓 Make 推斷 bundle，再將決策欄位對應到 HTTP 模組 body。針對客戶導入交接，Make bundle 應在 HTTP 模組寫入 Jodoo 前，讓客戶名稱、方案、上線目標、利害關係人備註、啟動會議風險與導入負責人保持可見。
工作流程執行後，Jodoo 會儲存什麼？
Jodoo 會儲存客戶名稱、方案或套裝、合約金額、主要聯絡人、上線目標、導入負責人、導入階段、風險等級、缺漏資訊、啟動會議優先順序，以及作為稽核脈絡的原始工作流程輸出。
之後可以連接正式來源資料嗎？
可以。先從已驗證的合成資料執行開始，等客戶導入交接結構穩定後，再連接表單、入口網站、收件匣、API 或內部系統。當高價值合約、緊急發票或缺漏資訊案例需要不同的 Jodoo 佇列時，可在基礎驗證後使用分派器。
哪些內容仍應由團隊檢視？
工作流程可以準備決策欄位，但負責人仍應檢視業務風險、付款或法務簽核，以及最終營運決策。請記錄 webhook URL 的負責人，以及誰有權編輯承載正式申請資料的模組。
下一步
將客戶導入轉為可追蹤的後續行動
先從一次已驗證的 Make 執行開始，再將相同的回寫模式重複用於相鄰的審查佇列與營運交接。將 Run once 驗證轉為啟用中的工作流程前，請先檢視操作用量、webhook 管理責任與情境排程。