Los ingenieros de soporte técnico y los equipos de operaciones técnicas (TechOps) se enfrentan con frecuencia a una dolorosa desconexión operativa: las quejas de los usuarios, los acuerdos de nivel de servicio (SLA) y las colas de soporte se gestionan en Zendesk, mientras que el código fuente, la resolución de fallos y las discusiones de ingeniería viven en GitHub. Ante esta división, los agentes de soporte pierden incontables horas alternando entre herramientas, buscando manualmente issues en repositorios de código, copiando trazas de errores y preguntando a los desarrolladores por Slack sobre el estado de cada corrección. Esto fomenta la duplicación de reportes de errores y retrasa las respuestas al cliente.
Dust (dust.tt) resuelve esta fragmentación no mediante reglas rígidas de sincronización de campos, sino mediante la orquestación contextual con agentes de inteligencia artificial. Al conectar Zendesk y GitHub dentro de Dust, los equipos pueden crear agentes inteligentes que combinan el historial de interacciones con clientes y el contexto técnico del código fuente. Estos agentes clasifican tickets de soporte entrantes, detectan incidencias ya conocidas en GitHub, redactan notas internas de diagnóstico y abren issues estandarizadas para ingeniería sin fricción humana.
A continuación, se detalla paso a paso cómo diseñar, configurar y desplegar una arquitectura de triaje técnico unificada con Dust, Zendesk y GitHub.
Visión arquitectónica: Cómo conecta Dust el soporte y la ingeniería
Para entender cómo opera Dust entre Zendesk y GitHub, conviene distinguir sus tres capas de integración:
| Capa arquitectónica | Funcionalidad en Zendesk | Funcionalidad en GitHub |
|---|---|---|
| Connections (Conocimiento) | Indexa semánticamente tickets resueltos o cerrados (últimos 180 días por defecto) y artículos del Centro de Ayuda (Guide). | Sincroniza en tiempo real issues, discusiones, comentarios principales de pull requests y, opcionalmente, el código de la rama por defecto. |
| Tools (Acciones) | Permite al agente ejecutar Get Ticket (detalle), Search Tickets (búsqueda sintáctica) y Draft Reply (borrador de nota privada interna). | Permite al agente buscar issues, crear nuevos reportes y comentar en discusiones o pull requests. |
| Surfaces (Interfaz y Triggers) | Inserta la app de Dust en la barra lateral de tickets de Zendesk y activa ejecuciones automáticas vía webhooks ante eventos de tickets. | Recibe eventos de GitHub (apertura de PRs, cambios de estado de issues) para activar flujos de trabajo autónomos. |
Esta arquitectura garantiza que Dust no sea un simple conector pasivo. Funciona como un motor de análisis que interpreta los síntomas reportados por el cliente a la luz del desarrollo técnico y ejecuta acciones controladas en ambos sistemas.
Paso 1: Establecer las conexiones de datos del espacio de trabajo
Para que los agentes puedan realizar un triaje preciso, requieren acceso de lectura al conocimiento histórico de soporte y a los registros de incidencias de ingeniería.
1. Conexión de Zendesk con Dust
- En el espacio de trabajo de Dust, vaya a Spaces > Connections y seleccione Zendesk.
- Introduzca el subdominio de su cuenta de Zendesk (
https://<subdominio>.zendesk.com). - Complete la autenticación OAuth con una cuenta que tenga permisos de administrador tanto en Dust como en Zendesk (con roles de administración en Support y Guide).
- Abra la opción Manage de la conexión para ajustar los filtros de sincronización:
- Alcance y retención de tickets: Dust sincroniza de forma predeterminada los tickets resueltos o cerrados actualizados en los últimos 180 días, con una depuración diaria para los anteriores a 120 días. Si necesita contrastar incidentes en curso, active Sync Unresolved Tickets.
- Privacidad y protección de datos (PII): Active Hide Customer Information para omitir nombres y correos de los clientes en los metadatos sincronizados, preservando intacto el contenido técnico del ticket.
- Filtros por etiquetas y campos personalizados: Configure Included Tags (como
tier-2obug) para aislar tickets técnicos. Si utiliza campos personalizados en Zendesk para registrar componentes de software o severidad, introduzca el ID numérico del campo en Custom Field Tags; Dust lo convertirá en etiquetas legibles con el formatofieldName:valuepara búsquedas semánticas. - Control de tasa de llamadas (TPS): Ajuste el límite de transacciones por segundo si su plan de Zendesk impone restricciones estrictas en su API.
2. Conexión de GitHub con Dust
- En Dust, diríjase a Spaces > Connections > GitHub y haga clic en Connect.
- Autentique la conexión con privilegios de administrador de la organización de GitHub.
- Seleccione los repositorios clave a los que Dust tendrá acceso (por ejemplo, servicios backend, aplicaciones web o SDKs públicos).
- Active la opción Code synchronization (opcional): permítale a los agentes inspeccionar directamente los archivos de la rama predeterminada. El código se sincroniza cada 8 horas, mientras que los issues y PRs se actualizan de forma instantánea.
- Guarde la configuración. Dust indexará automáticamente los títulos, cuerpos, etiquetas y autores para su recuperación semántica.
Paso 2: Activar las herramientas de acción (Tools) de Zendesk y GitHub
Las conexiones de datos otorgan capacidad de lectura. Para que el agente pueda buscar tickets en vivo, redactar notas de diagnóstico y crear issues en GitHub, debe habilitar las Tools:
- Vaya a Spaces > Tools y elija Add Tools.
- Active las Zendesk Tools:
Search Tickets: Búsqueda de tickets mediante sintaxis avanzada (por ejemplo:status:open priority:urgent tags:bug).Get Ticket: Obtención del historial íntegro de comentarios, metadatos y métricas de SLA.Draft Reply: Generación de notas internas privadas (Private Comment), invisibles para el cliente final, destinadas a revisión del equipo de soporte.
- Active las GitHub Tools:
- Seleccione el modo de credenciales: se recomienda Workspace Credentials, con el cual todas las acciones e issues se publican bajo el bot oficial
@dust-agent, garantizando una trazabilidad centralizada (o elija Personal Credentials para heredar los permisos de cada usuario individual).
- Seleccione el modo de credenciales: se recomienda Workspace Credentials, con el cual todas las acciones e issues se publican bajo el bot oficial
Paso 3: Configurar el agente de triaje en Agent Builder
Con los datos y las herramientas activas, cree un agente especializado en triaje y escalamiento dentro de Agent Builder (por ejemplo, @tier2-triage).
Configuración del agente
- Modelo: Seleccione un modelo con alto razonamiento técnico y comprensión de código (como Claude 3.5 Sonnet, GPT-4o o Gemini 1.5 Pro).
- Conocimiento (Knowledge): Asigne las conexiones de Zendesk (artículos y tickets) y de GitHub (repositorios seleccionados).
- Herramientas (Tools): Habilite
Search Tickets,Get Ticket,Draft Replyde Zendesk y las herramientas de búsqueda y creación de issues en GitHub. - Instrucciones del sistema: Establezca pautas claras para el diagnóstico, la deduplicación de errores y la estructura de las notas internas.
Eres el copiloto de soporte de nivel 2 y triaje de incidencias (Tier-2 Triage Copilot). Tu objetivo es analizar los tickets técnicos de Zendesk, contrastarlos con nuestros repositorios de GitHub y proporcionar un triaje técnico preciso.
Al analizar un ticket de Zendesk:
1. Extrae el mensaje de error, la traza de la pila o el comportamiento anómalo y busca en el repositorio correspondiente de GitHub (por defecto: dust-tt/app-backend) si existe algún issue abierto o recientemente cerrado que coincida.
2. Busca en los tickets históricos de Zendesk para determinar si este problema ya ha ocurrido antes y si existe una solución temporal (workaround) validada.
3. Si coincide con un issue existente en GitHub:
- Utiliza la herramienta "Draft Reply" de Zendesk para redactar una nota privada interna (Private Comment).
- Incluye: (a) Enlace al issue de GitHub y su estado actual, (b) Resumen de la causa raíz, (c) Solución alternativa recomendada para compartir con el cliente.
4. Si se confirma como un fallo nuevo y reproducible:
- Crea un nuevo issue en GitHub con la herramienta correspondiente usando el formato: [Triage] Descripción breve del fallo. En el cuerpo, incluye el ID del ticket de Zendesk, entorno, pasos de reproducción y registros de error.
- Redacta una nota privada interna en Zendesk con el número del issue de GitHub recién creado.
5. Nunca envíes respuestas públicas directamente al cliente final. Todo el contenido generado debe ser una nota privada interna o presentarse en la barra lateral de Dust para revisión humana previa.
Paso 4: Despliegue de la interfaz y automatización con Webhooks
El agente puede operar en dos modalidades complementarias: asistencia bajo demanda en la interfaz de Zendesk y triaje automático en segundo plano mediante Webhooks.
Modalidad A: Copiloto interactivo en la barra lateral de Zendesk
- Instale la aplicación oficial de Dust desde el Zendesk Marketplace.
- En el Centro de Administración de Zendesk, acceda a la configuración de la app de Dust.
- Introduzca su Workspace ID de Dust y una API Key creada por un administrador de Dust.
- En el campo Default Agent IDs, configure el ID de su agente
@tier2-triage. Así, al abrir un ticket, los especialistas verán directamente a este asistente en la barra lateral derecha. - Verifique que el correo del agente en Zendesk coincida con su cuenta en Dust. Frente a un ticket complejo, el operador puede preguntar: "¿Hay algún commit reciente que solucione este fallo en la pasarela de pagos?", y el agente responderá de inmediato con las referencias exactas de GitHub.
Modalidad B: Triaje autónomo mediante Webhooks
Para diagnosticar incidencias críticas de forma automática en cuanto se registran:
- En Dust, vaya a Spaces > Triggers y pulse Add source.
- Seleccione el proveedor nativo Zendesk y vincule su cuenta.
- En la configuración del agente
@tier2-triage, diríjase a Triggers > Add triggers y seleccione la fuente de Zendesk creada. - Establezca las condiciones de ejecución:
- Evento a escuchar: Ticket Created (Creación de ticket) o Ticket Updated (Actualización).
- Condición: Describa en lenguaje natural el filtro deseado, por ejemplo:
"priority is urgent or tags contain technical-escalation". - Carga útil: Active Include webhook payload para enviar el título, cuerpo y etiquetas directamente al agente.
- Límite de tasa: Defina un límite de ejecuciones diarias para controlar el uso de la API en momentos de contingencia masiva.
- Guarde el agente. Cuando entre un ticket urgente, Dust lo procesará automáticamente en segundo plano y dejará una nota interna con el diagnóstico y el issue de GitHub antes de que un agente humano lo abra.
Comparativa: Triaje con Dust frente a extensiones de sincronización convencionales
| Criterio de evaluación | Herramientas de enlace punto a punto (p. ej., Git-Zen) | Triaje inteligente con Dust |
|---|---|---|
| Detección de duplicados | Requiere ingresar manualmente el ID exacto o referenciar la sintaxis en commits. | Utiliza búsqueda semántica RAG para encontrar issues similares basándose en descripciones y registros técnicos. |
| Diagnóstico de causa raíz | Nulo; únicamente replica texto plano entre plataformas. | Sintetiza el código del repositorio, casos históricos resueltos y trazas de error para sugerir hipótesis y mitigaciones. |
| Redacción de respuestas | Inexistente; el agente humano debe escribir cada respuesta técnica desde cero. | Redacta borradores internos privados (Draft Reply) técnicamente precisos listos para validación. |
| Privacidad y cumplimiento | Riesgo de enviar datos personales del cliente (PII) directamente a repositorios de código. | Filtra y enmascara metadatos personales antes de indexar la información técnica. |
| Impacto en tiempos de resolución | Automatiza solo el enlace; el diagnóstico sigue tomando horas. | Reduce el tiempo de análisis inicial y escalamiento técnico a unos pocos minutos. |
Gobernanza, precios y buenas prácticas
- Mantener la supervisión humana (Human-in-the-Loop): Asegúrese de que el agente use exclusivamente
Draft Replypara publicar comentarios internos. Un profesional de soporte debe ser quien revise y envíe la comunicación externa al cliente. - Optimizar filtros para no agotar cuotas: Limite las ejecuciones automáticas por webhook a colas técnicas o niveles de severidad elevados, evitando invocar modelos avanzados para tickets rutinarios de facturación o reseteo de contraseñas.
- Planificación de créditos y licencias: Los planes Business de Dust funcionan en modalidad autoservicio, ofreciendo Pro (24 €/asiento/mes con facturación anual, incluyendo 8.000 créditos/mes) y Max (120 €/asiento/mes con facturación anual, con 40.000 créditos/mes). El plan Enterprise ofrece fondos comunes de créditos, aprovisionamiento SCIM, logs de auditoría y acuerdos de nivel de servicio (SLA). Dimensione adecuadamente los créditos según el volumen de webhooks previsto.
Al unir el flujo de incidencias de Zendesk con el conocimiento de desarrollo en GitHub mediante Dust, las organizaciones técnicas erradican la duplicación de tareas, agilizan la resolución de averías y garantizan una alineación impecable entre soporte e ingeniería.