La integración que «funciona» y la integración que funciona
Hay dos tipos de integraciones, y la mayoría de las plataformas no las distinguen con claridad.
La que envuelve llamadas a API. La plataforma expone herramientas HTTP: GET /v2/tickets, POST /v2/tickets, PATCH /v2/agreements/{id}. El usuario (o la IA del usuario) descubre la secuencia correcta de llamadas. Autenticación, paginación y rate limiting son problema del usuario. Si la API tiene conceptos específicos de MSP como «Agreement» que no son tipos genéricos de «record», la integración no lo sabe ni le importa.
La que habla el dominio. La plataforma entiende que un Agreement de ConnectWise no es solo un record — es una estructura de facturación que gobierna si las entradas de tiempo cuentan contra un retainer o se facturan a tarifa T&M. Entiende que una Configuration no es solo un objeto CRUD — es el inventario de activos rastreados por el MSP para sus clientes, al que el RMM alimenta, y que la IA de triaje necesita leer para generar respuestas contextuales. Entiende que las escrituras masivas de tiempo de ticket no son «POST al mismo endpoint N veces» — son una única operación transaccional que previene la doble facturación en retry.
Para ConnectWise Manage, construimos la segunda.
Qué hacen realmente los MSP con ConnectWise
Antes de escribir una línea de código, entrevistamos a 14 MSP pequeños (4 a 25 técnicos) sobre lo que realmente hacen dentro de ConnectWise en un día típico. El patrón fue consistente:
-
Triar tickets entrantes. El service desk lee el ticket, asigna prioridad, rutea al board correcto. Necesita: leer el ticket, leer las Configurations del cliente (para que la IA pueda redactar respuestas con contexto), leer el Agreement (para que la IA conozca el nivel de SLA), escribir una nota interna con la respuesta borrador para revisión del técnico.
-
Registrar tiempo contra tickets. Los técnicos pasan el final de cada día (o el viernes por la tarde) escribiendo entradas de tiempo. Un técnico puede tener 30–50 entradas a lo largo de 15 tickets. Escribir es el trabajo. Necesita: escritura masiva de entradas de tiempo con semántica transaccional para que un retry no duplique la publicación.
-
Reconciliar tiempo facturable vs. tiempo de retainer. La misma entrada de tiempo significa cosas distintas contra un Agreement T&M vs. un Agreement de retainer. Necesita: leer los Agreements y usarlos para clasificar las entradas de tiempo al escribir.
-
Mantener las Configurations en sincronía. Las herramientas RMM y de monitoreo generan actualizaciones de Configuration constantemente. Ingerirlas en ConnectWise sin crear duplicados ni sobrescribir notas escritas por el usuario es una irritación constante y menor. Necesita: deduplicación en la capa de integración, no «cada feed tiene su propia lógica de dedup».
-
Generar paquetes QBR / revisión de cliente. Mensual o trimestralmente, extraer detalles de Agreement, inventario de Configurations, resumen de tickets, desempeño de SLA. Necesita: leer todo lo anterior de manera estructurada para que una IA pueda resumir.
Ninguno de estos es «escribir CRUD genérico contra un endpoint REST». Todos dependen de que la integración entienda conceptos de dominio.
Qué construimos
La integración viene con estas superficies de primera clase:
Configurations
Leer y actualizar Configurations de ConnectWise como objetos estructurados, no blobs JSON. Cuando un RMM envía una actualización de Configuration (inventario de software, cambio de hardware, estado de parches), la integración:
- Deduplica contra las Configurations existentes para el mismo cliente + activo
- Preserva las notas escritas por el usuario que no cubre el feed
- Escribe una única actualización transaccional, no N actualizaciones parciales
Cuando la IA está redactando una respuesta a un ticket, puede leer las Configurations relevantes a través de una herramienta estructurada — no raspando la UI de ConnectWise ni parseando respuestas de la API.
Agreements
Leer y razonar sobre Agreements a nivel de dominio. Un Agreement tiene:
- Un modelo de facturación (retainer, T&M, precio fijo, basado en ticket)
- Cobertura incluida (qué service boards, qué configurations, qué tipos de trabajo)
- Nivel de SLA (tiempo de respuesta, tiempo de resolución)
- Tablas de tarifas (tipo de técnico → tarifa facturable)
La integración expone todo esto a la IA y a los operadores como datos estructurados. Cuando la IA de un MSP está generando una respuesta a un ticket, sabe si el cliente está bajo un SLA «Gold» o «Bronze» y redacta en consecuencia.
Operaciones masivas de tiempo de ticket
La función estrella para técnicos que pierden 30 minutos al día en entradas de tiempo.
- Escritura masiva — enviar 50 entradas de tiempo para el día de un técnico en una única operación
- Transaccional — si alguna entrada falla, el batch hace rollback limpiamente (sin estado parcial a medio escribir)
- Deduplicación — si el operador reintenta por un timeout, el segundo intento detecta el estado parcial del primero y lo completa en lugar de duplicar publicaciones
- Marcado de asistencia IA — las entradas de tiempo escritas por IA llevan un prefijo visible
[AI-Assisted]. El MSP elige si divulgar esto al cliente en las facturas, pero el rastro de auditoría siempre está ahí.
Rate limiting y retry
ConnectWise Manage tiene límites de tasa de API por cliente que varían según el nivel de licencia. La integración:
- Respeta el límite por cliente como un concepto de primera clase, no «reintenta en 429»
- Usa un token bucket por tenant de cliente, no un contador global
- Implementa retries idempotentes con una clave de dedup derivada del payload de la solicitud — para que un retry por un glitch de red no escriba dos veces
Aislamiento cross-cuenta
La integración viene con una suite de pruebas de seguridad cross-cuenta que verifica específicamente: una acción acotada al Cliente A no puede leer ni escribir datos del Cliente B, incluso si las claves API en uso tienen acceso más amplio. La suite de pruebas es parte de nuestra CI y bloquea cualquier regresión.
Esta es la función que le importa al auditor. Cuando el cumplimiento SOC 2 o HIPAA está en juego, «probamos que el aislamiento de tenant funciona» es la diferencia entre una auditoría limpia y un hallazgo.
Qué ve la IA
La integración está expuesta a la capa de IA de JieGou vía herramientas MCP estructuradas. Una recipe o workflow que maneja el triaje de tickets puede:
read_configurations(client_tenant: "Acme Corp", filter: { active: true })
→ devuelve lista estructurada de Configurations
read_agreement(client_tenant: "Acme Corp", agreement_id: "AGR-123")
→ devuelve Agreement estructurado con modelo de facturación + nivel de SLA
draft_ticket_response(ticket_id: "T-456", context: { configurations, agreement })
→ la IA genera respuesta consciente del contexto específico del cliente
submit_for_approval(draft, action: "post_to_ticket_notes")
→ entra en la cola de aprobación en modo sombra
[el operador revisa y aprueba]
write_time_entry(ticket_id, hours, description, billable: from_agreement_rules)
→ escritura transaccional a través de la integraciónLa IA no necesita saber que la API HTTP de ConnectWise existe. Compone acciones de dominio. La integración traduce.
Qué costó construir esto
Más que un wrapper REST, menos que un PSA desde cero. En calendario, aproximadamente dos sprints de ingeniería enfocados específicamente en la semántica de ConnectWise, más refinamiento continuo a medida que los MSP piloto hacen emerger casos límite.
La alternativa — un wrapper genérico de API — habría llevado un sprint. Habría funcionado para el happy path. Habría fallado para el caso de tiempo masivo, el caso de dedup de retry, el caso de búsqueda de tarifa de Agreement y el caso de aislamiento de tenant verificado.
Para un vertical como los MSP donde la profundidad de integración con el PSA es el criterio de compra, un sprint adicional de trabajo de integración es el trade correcto.
Qué sigue
En el roadmap actual:
- Integración con ConnectWise Automate — el lado RMM de la suite CW; mismo modelo de gobernanza
- Reporting de ConnectWise PSA — espejo de la estructura de reportes que los MSP ya esperan de CW, generados por IA en un calendario
- Integración con Autotask PSA — el otro gran PSA, mismo patrón de superficies de primera clase
Si eres un MSP que usa ConnectWise Manage y nuestro enfoque te suena adecuado, agenda una demo y haremos un recorrido de integración en vivo. Si estás en otro PSA y quieres esta profundidad de integración con tus herramientas, dínoslo — la roadmap responde a MSP nombrados.