Wir haben unsere ConnectWise-Manage-Integration von Grund auf gebaut. Hier ist warum.

Die Integration, die “funktioniert”, und die Integration, die funktioniert

Es gibt zwei Arten von Integrationen, und die meisten Plattformen unterscheiden nicht klar zwischen ihnen.

Die API-Calls-umwickelnde Variante. Die Plattform legt HTTP-Tools offen: GET /v2/tickets, POST /v2/tickets, PATCH /v2/agreements/{id}. Der Nutzer (oder die KI des Nutzers) findet die richtige Call-Sequenz heraus. Authentifizierung, Pagination und Rate-Limiting sind Problem des Nutzers. Wenn die API MSP-spezifische Konzepte wie “Agreement” hat, die keine generischen “Record”-Typen sind, weiß oder kümmert sich die Integration nicht.

Die die-Domäne-sprechende Variante. Die Plattform versteht, dass ein ConnectWise Agreement nicht nur ein Record ist — es ist eine Abrechnungsstruktur, die regelt, ob Zeit-Einträge auf ein Retainer angerechnet oder zu T&M-Raten abgerechnet werden. Sie versteht, dass eine Configuration kein CRUD-Objekt ist — es ist das Inventar der MSP-getrackten Client-Assets, in das das RMM einspeist und das die Triage-KI lesen muss, um kontextbezogene Antworten zu generieren. Sie versteht, dass Bulk-Ticket-Zeit-Schreibvorgänge nicht “POSTe denselben Endpunkt N-mal” sind — sie sind eine einzelne transaktionale Operation, die Doppelabrechnung bei Retry verhindert.

Für ConnectWise Manage haben wir die zweite Art gebaut.

Was MSPs tatsächlich mit ConnectWise tun

Bevor wir eine Zeile Code geschrieben haben, haben wir 14 kleine MSPs (4–25 Techniker) dazu befragt, was sie an einem typischen Tag tatsächlich in ConnectWise tun. Das Muster war konsistent:

1. Eingehende Tickets triagieren. Der Service Desk liest das Ticket, vergibt Priorität, routet auf das richtige Board. Benötigt wird: Ticket lesen, Configurations des Kunden lesen (damit die KI kontextbezogene Antworten entwerfen kann), Agreement lesen (damit die KI die SLA-Stufe kennt), interne Notiz mit dem entworfenen Response für die Techniker-Review schreiben.

2. Zeit auf Tickets buchen. Techniker schreiben am Ende jedes Tages (oder Freitagnachmittag) Zeit-Einträge. Ein Techniker hat vielleicht 30–50 Einträge über 15 Tickets. Das Tippen ist die Arbeit. Benötigt wird: Bulk-Schreiben von Zeit-Einträgen mit transaktionaler Semantik, damit ein Retry nicht doppelt postet.

3. Abrechenbare vs. Retainer-Zeit abgleichen. Derselbe Zeit-Eintrag bedeutet gegen ein T&M-Agreement etwas anderes als gegen ein Retainer-Agreement. Benötigt wird: Agreements lesen und sie nutzen, um Zeit-Einträge beim Schreiben zu klassifizieren.

4. Configurations synchron halten. RMM- und Monitoring-Tools generieren ständig Configuration-Updates. Diese in ConnectWise zu überführen, ohne Duplikate zu erzeugen oder benutzererfasste Notizen zu überschreiben, ist ein ständiger kleiner Ärger. Benötigt wird: Deduplikation auf Integrations-Ebene, nicht “jeder Feed hat seine eigene Dedup-Logik”.

5. QBR- / Kunden-Review-Pakete erzeugen. Monatlich oder quartalsweise: Agreement-Details, Configuration-Inventar, Ticket-Zusammenfassung, SLA-Performance ziehen. Benötigt wird: All das strukturiert lesen, damit eine KI zusammenfassen kann.

Nichts davon ist “generische CRUD-Operationen gegen einen REST-Endpunkt”. All das hängt davon ab, dass die Integration Domänenkonzepte versteht.

Was wir gebaut haben

Die Integration liefert diese erstklassigen Oberflächen:

Configurations

ConnectWise Configurations als strukturierte Objekte lesen und aktualisieren, nicht als JSON-Blobs. Wenn ein RMM ein Configuration-Update einspeist (Software-Inventar, Hardware-Änderung, Patch-Status), dann:

• dedupliziert die Integration gegen bestehende Configurations für denselben Kunden + Asset
• erhält benutzererfasste Notizen, die der Feed nicht abdeckt
• schreibt ein einzelnes transaktionales Update, nicht N partielle Updates

Wenn die KI eine Ticket-Antwort entwirft, kann sie relevante Configurations über ein strukturiertes Tool lesen — nicht durch Scraping der ConnectWise-UI oder Parsen von API-Responses.

Agreements

Agreements auf Domänenebene lesen und durchdenken. Ein Agreement hat:

• Ein Abrechnungsmodell (Retainer, T&M, Pauschalpreis, ticketbasiert)
• Eingeschlossene Abdeckung (welche Service Boards, welche Configurations, welche Work Types)
• SLA-Stufe (Reaktionszeit, Lösungszeit)
• Rate Tables (Techniker-Typ → abrechenbarer Satz)

Die Integration macht all das als strukturierte Daten für KI und Operatoren zugänglich. Wenn die KI eines MSP eine Ticket-Antwort generiert, weiß sie, ob der Kunde unter einem “Gold”- oder “Bronze”-SLA steht, und entwirft entsprechend.

Bulk-Operationen für Ticket-Zeit

Das Killer-Feature für Techniker, die 30 Minuten pro Tag an Zeit-Eintrag verlieren.

• Bulk-Write — 50 Zeit-Einträge für den Tag eines Technikers in einer einzigen Operation übermitteln
• Transaktional — wenn irgendein Eintrag fehlschlägt, rollt der Batch sauber zurück (kein halb geschriebener Teilzustand)
• Deduplikation — wenn der Operator wegen eines Timeouts retriet, erkennt der zweite Versuch den Teilzustand des ersten und vervollständigt ihn, statt doppelt zu posten
• KI-Assistenz-Kennzeichnung — Zeit-Einträge, die von KI geschrieben werden, tragen ein sichtbares [AI-Assisted]-Präfix. Der MSP entscheidet, ob er das dem Kunden auf Rechnungen offenlegt, aber der Audit-Trail ist immer da.

Rate-Limiting und Retry

ConnectWise Manage hat pro Client unterschiedliche API-Rate-Limits je Lizenzstufe. Die Integration:

• respektiert das Pro-Client-Rate-Limit als erstklassiges Konzept, nicht als “bei 429 nochmal versuchen”
• verwendet ein Token-Bucket pro Client-Tenant, nicht einen globalen Zähler
• implementiert idempotente Retries mit einem aus dem Request-Payload abgeleiteten Dedup-Key — damit ein Retry wegen eines Netzwerk-Aussetzers nicht zweimal schreibt

Cross-Account-Isolation

Die Integration wird mit einer Cross-Account-Sicherheits-Testsuite ausgeliefert, die speziell verifiziert: Eine Aktion, die auf Kunde A gescoped ist, kann keine Daten für Kunde B lesen oder schreiben, auch wenn die eingesetzten API-Keys breiteren Zugriff haben. Die Testsuite ist Teil unserer CI und blockiert jede Regression.

Das ist das Feature, das der Auditor interessiert. Wenn SOC-2- oder HIPAA-Compliance auf dem Spiel steht, ist “wir haben getestet, dass Tenant-Isolation funktioniert” der Unterschied zwischen einem sauberen Audit und einem Finding.

Was die KI sieht

Die Integration ist für die KI-Schicht von JieGou über strukturierte MCP-Tools exponiert. Ein Recipe oder Workflow, der Ticket-Triage übernimmt, kann:

read_configurations(client_tenant: "Acme Corp", filter: { active: true })
  → gibt strukturierte Liste von Configurations zurück

read_agreement(client_tenant: "Acme Corp", agreement_id: "AGR-123")
  → gibt strukturiertes Agreement mit Abrechnungsmodell + SLA-Stufe zurück

draft_ticket_response(ticket_id: "T-456", context: { configurations, agreement })
  → KI generiert Antwort unter Kenntnis des spezifischen Kundenkontexts

submit_for_approval(draft, action: "post_to_ticket_notes")
  → tritt in die Shadow-Mode-Freigabe-Warteschlange ein

[Operator prüft und genehmigt]

write_time_entry(ticket_id, hours, description, billable: from_agreement_rules)
  → transaktionales Schreiben über die Integration

Die KI muss nicht wissen, dass ConnectWise’s HTTP-API existiert. Sie komponiert Domänen-Aktionen. Die Integration übersetzt.

Was es gekostet hat, das zu bauen

Mehr als ein REST-Wrapper, weniger als ein grüner-Wiese-PSA. Kalendarisch rund zwei Sprints Engineering, fokussiert speziell auf ConnectWise-Semantik, plus laufende Verfeinerung, während Pilot-MSPs Edge Cases zutage fördern.

Die Alternative — ein generischer API-Wrapper — hätte einen Sprint gekostet. Er hätte auf dem Happy Path funktioniert. Er wäre beim Bulk-Time-Fall gescheitert, beim Retry-Dedup-Fall, beim Agreement-Rate-Lookup-Fall und beim Tenant-Isolation-verifiziert-Fall.

Für ein Vertical wie MSPs, wo die Tiefe der PSA-Integration das Kaufkriterium ist, ist ein Sprint zusätzlicher Integrationsarbeit der richtige Trade.

Was als Nächstes kommt

Aktuell auf der Roadmap:

• ConnectWise-Automate-Integration — die RMM-Seite der CW-Suite; gleiches Governance-Modell
• ConnectWise-PSA-Reporting — spiegelt die Report-Struktur, die MSPs bereits von CW erwarten, von KI nach Zeitplan generiert
• Autotask-PSA-Integration — das andere große PSA, dasselbe Muster erstklassiger Oberflächen

Wenn Sie ein MSP sind, der ConnectWise Manage nutzt, und unser Ansatz für Sie passt: Demo buchen und wir gehen eine Live-Integrations-Walkthrough mit Ihnen durch. Wenn Sie auf einem anderen PSA sind und diese Tiefe der Integration für Ihr Tooling wollen, schreiben Sie uns — die Roadmap reagiert auf namentlich genannte MSPs.