「會動」的整合 vs. 真的好用的整合
整合有兩種,而大多數平台並沒有清楚區分。
包裝API呼叫那種。 平台暴露HTTP工具:GET /v2/tickets、POST /v2/tickets、PATCH /v2/agreements/{id}。使用者(或使用者的AI)自己想辦法拼出正確的呼叫順序。認證、分頁與速率限制都是使用者的問題。如果API擁有像「Agreement」這種MSP特有的概念——而非通用的「記錄」型別——整合並不知道也不在乎。
說業務語言那種。 平台理解ConnectWise的Agreement並不只是一筆記錄——它是一種計費結構,決定工時是否計入月費包或以T&M計費。它理解Configuration不只是一個CRUD物件——它是MSP追蹤客戶資產的清單,由RMM饋入,分流AI需要讀取才能產生符合上下文的回覆。它理解工單工時的批次寫入不是「對同一個端點POST N次」——而是一個避免在重試時重複計費的單一交易操作。
對於ConnectWise Manage,我們打造的是第二種。
MSP在ConnectWise裡到底在做什麼
在寫任何一行程式碼之前,我們訪談了14家小型MSP(4到25位技師),詢問他們在ConnectWise裡一天到底在做什麼。模式非常一致:
-
分流進來的工單。 Service Desk讀工單、分派優先級、路由到正確的面板。需求:讀工單、讀客戶的Configurations(讓AI能起草符合上下文的回覆)、讀Agreement(讓AI知道SLA分級)、寫內部備註並附上草擬的回覆給技師審查。
-
對工單記工時。 技師每天結束時(或週五下午)寫工時條目。一位技師可能在15張工單上有30–50筆條目。打字本身就是工作。需求:具交易語意的批次寫入工時,這樣重試不會重複記帳。
-
對帳可計費時數 vs. 月費保留時數。 同一筆工時在T&M Agreement與月費Agreement下意義不同。需求:讀取Agreements,並在寫入時利用它們對工時進行分類。
-
讓Configurations保持同步。 RMM與監控工具持續產生Configuration更新。將這些匯入ConnectWise而不製造重複或覆蓋使用者輸入的備註,是一個長期小困擾。需求:在整合層進行去重,而不是「每個饋入都有自己的去重邏輯」。
-
產生QBR / 客戶檢視包。 每月或每季,拉出Agreement細節、Configuration清單、工單摘要、SLA表現。需求:以結構化方式讀取以上全部,讓AI能進行摘要。
這些沒有一項是「對REST端點寫通用CRUD」。所有事項都仰賴整合對業務概念的理解。
我們打造了什麼
這個整合提供下列一等功能面:
Configurations
將ConnectWise Configurations讀取與更新為結構化物件,而非JSON塊。當RMM餵入Configuration更新(軟體清單、硬體變更、修補狀態)時,整合會:
- 對同一客戶+資產的既有Configurations進行去重
- 保留饋入未涵蓋的使用者輸入備註
- 執行單一交易更新,而非N次不完整更新
當AI在起草工單回覆時,可以透過結構化工具讀取相關的Configurations——而不是去爬ConnectWise UI或解析API回應。
Agreements
在業務層級讀取並推論Agreements。一個Agreement擁有:
- 計費模式(月費、T&M、固定費用、逐工單)
- 涵蓋範圍(哪些service board、哪些configurations、哪些工作類型)
- SLA分級(回應時間、解決時間)
- 費率表(技師類型 → 可計費費率)
整合將這一切以結構化資料的形式開放給AI與操作員。當MSP的AI在產生工單回覆時,它知道客戶處於「Gold」或「Bronze」SLA下並據此起草。
工單工時批次操作
對每天損失30分鐘在工時登錄上的技師來說,這是關鍵功能。
- 批次寫入 — 單次操作提交一位技師一天50筆工時條目
- 交易式 — 若任何一筆失敗,整批乾淨回滾(不會留下半寫入的部分狀態)
- 去重 — 若操作員因逾時重試,第二次嘗試會偵測第一次的部分狀態並完成它,而非重複寫入
- AI輔助標記 — 由AI寫入的工時會帶可見的
[AI-Assisted]前綴。MSP自行決定是否在發票上向客戶揭露,但稽核軌跡永遠都在。
速率限制與重試
ConnectWise Manage具有依授權層級而異的逐客戶API速率限制。整合會:
- 將逐客戶速率限制視為一等概念,而非「收到429再試一次」
- 對每個客戶租戶使用Token Bucket,而非全域計數器
- 以從請求負載衍生的去重鍵實作冪等重試——讓因網路閃斷的重試不會寫兩次
跨帳號隔離
整合附帶跨帳號安全測試套件,具體驗證:限定於客戶A的動作不能讀寫客戶B的資料,即使所用API金鑰有更廣的存取權限。該測試套件是我們CI的一部分,會阻擋任何回歸。
這就是稽核員在意的功能。當SOC 2或HIPAA合規攸關重大,「我們已測試租戶隔離運作」就是乾淨稽核與稽核發現之間的差異。
AI看到的是什麼
整合透過結構化的MCP工具開放給JieGou的AI層。處理工單分流的Recipe或工作流程可以:
read_configurations(client_tenant: "Acme Corp", filter: { active: true })
→ 回傳結構化的Configurations清單
read_agreement(client_tenant: "Acme Corp", agreement_id: "AGR-123")
→ 回傳結構化的Agreement含計費模式與SLA分級
draft_ticket_response(ticket_id: "T-456", context: { configurations, agreement })
→ AI產生回覆,理解客戶的具體上下文
submit_for_approval(draft, action: "post_to_ticket_notes")
→ 進入影子模式審批佇列
[操作員審查並核准]
write_time_entry(ticket_id, hours, description, billable: from_agreement_rules)
→ 透過整合進行交易式寫入AI不需要知道ConnectWise的HTTP API存在。它組合業務動作。整合負責翻譯。
建造這個花了多少力氣
比REST包裝器多,比從零打造PSA少。就工時而言,約兩個衝刺專注於ConnectWise的業務語義,外加隨著試行MSP浮現邊緣案例的持續調整。
替代方案——一個通用的API包裝器——只需一個衝刺。它會在一般路徑上正常運作。但會在批次工時、重試去重、Agreement費率查找、跨租戶隔離驗證等案例上失敗。
對於像MSP這種以PSA整合深度作為採購標準的垂直市場,多花一個衝刺的整合工作是正確的取捨。
下一步
目前路線圖中的:
- ConnectWise Automate整合 — CW套件的RMM側;相同治理模型
- ConnectWise PSA報表 — 按MSP既有的CW報表結構生成,由AI排程產出
- Autotask PSA整合 — 另一個主流PSA,相同的一等功能面模式
如果你是使用ConnectWise Manage的MSP,覺得我們的做法合你胃口,預約Demo,我們會帶你走過一次現場整合導覽。若你使用不同的PSA,並希望擁有同等深度的整合,告訴我們——路線圖會回應有名有姓的MSP。