「会动」的集成 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。