Las investigaciones de soporte son, en esencia, problemas de investigación, por lo que la parte más lenta de responder a los problemas de los clientes siempre ha sido reunir el contexto adecuado. Al reunir código, log, conocimiento del equipo y conversaciones anteriores en una sola sesión de Cursor, hemos eliminado ese cuello de botella en la mayor parte de nuestro trabajo.

Hoy, más del 75 % de las interacciones de soporte de Cursor se gestionan a través de Cursor, lo que multiplica por 5–10 la capacidad de los ingenieros de soporte. Esto ha supuesto un cambio radical en lo que los ingenieros de soporte pueden lograr frente a lo que era posible hace apenas un año.

#Empezar desde la base de código

Cuando investigamos, normalmente empezamos en Ask Mode. Lo orientamos hacia el síntoma y dejamos que rastree hacia atrás el comportamiento relevante del producto. Como toda nuestra base de código está disponible localmente, Cursor puede indexar y usar búsqueda semántica en el código del producto, la documentación y las herramientas internas en la misma sesión.

Aquí es donde los espacios de trabajo multi-root se vuelven especialmente útiles. El contexto del producto casi siempre abarca varios repositorios. Responder a la pregunta del usuario: "¿Por qué este botón está deshabilitado?" puede implicar lógica de frontend, comprobaciones de políticas en el backend y documentación que describa el comportamiento esperado. Mantenemos los repositorios relacionados juntos en un solo espacio de trabajo para que ese tipo de pregunta pueda responderse en un solo hilo.

#Integración de fuentes de soporte con MCP

Usamos servidores MCP para recuperar contexto e incorporarlo a nuestras investigaciones. Nuestros ingenieros de soporte ya no necesitan buscar en varias herramientas para obtener el contexto relevante, porque está disponible en Cursor.

Los servidores MCP nos permiten integrar:

• Bases de datos con información de clientes, como el nivel de suscripción, la configuración del equipo y la configuración de privacidad
• Logs de eventos en streaming que contienen detalles sobre los servicios utilizados, errores de telemetría e incidencias de red
• Plataformas de comunicación como Slack, llenas de hilos y conversaciones que nos ayudan a entender mejor cómo interactúan los clientes con el producto
• Plataformas de tickets de ingeniería que pueden abarcar decenas de equipos distintos, cada uno con su propia forma de trabajar
• Un servicio interno de documentación que contiene runbooks y guías de resolución de problemas
• Un servicio de gestión de cuentas con información crucial del cliente que puede cambiar el tono con el que lo abordas

Con Cursor y los servidores MCP, nuestros ingenieros de soporte pueden incorporar rápidamente la información necesaria directamente en sus investigaciones de la base de código.

#Identificar dónde se produjo el fallo

Cuando un cliente reporta un error, necesitamos entender: ¿el problema que está experimentando es reproducible o transitorio? ¿Y dónde falló exactamente Cursor (del lado del cliente, en el borde de la API, en una dependencia aguas abajo o en la autenticación)? Datadog MCP nos permite traer los logs y las trazas relevantes directamente al hilo de investigación, lo que nos ayuda a empezar a acotar las posibles causas.

#Encontrar casos similares

Cuando llega un nuevo ticket de soporte, es probable que otro cliente o alguien de nuestro equipo ya haya visto la incidencia. Un MCP que se integra con tu plataforma de soporte, así como con Slack, nos permite buscar directamente en ese contexto y recuperar los hilos más relevantes para la investigación. Primero buscamos identificadores inequívocos (cadenas de error, ID de solicitud), ampliamos la búsqueda si hace falta y buscamos el hilo más reciente que incluya un estado actual, una solución alternativa y una persona responsable.

#Determinar si se trató de un error

Muchas investigaciones se reducen a «¿error o comportamiento esperado?». Notion MCP nos permite incorporar al hilo el runbook pertinente, contrastarlo con lo que estamos viendo y confirmar si el comportamiento es el esperado o escalar el caso con un reporte de error mucho más claro.

#Presentar un reporte de error

Para cuando terminamos una investigación en Cursor, ya hemos reunido todo el material que necesitamos para presentar un ticket al equipo de ingeniería si hay que solucionar algo. Linear MCP nos permite tomar todo ese contexto y convertirlo en una escalación ya formateada directamente desde el mismo hilo.

#Actualizaciones de la documentación

Cuando varios clientes tienen las mismas dudas, suele ser una señal de que necesitamos mejorar nuestra documentación. El equipo de soporte técnico está en una posición ideal para solucionar este tipo de problemas directamente. Solo mencionamos a @Cursor en Slack indicando qué hay que actualizar, y un cloud agent abrirá un PR en nuestro repositorio de documentación.

#Automatización del proceso

#Comandos para pasos comunes

Usamos comandos slash para los pasos que se repiten con más frecuencia en el proceso:

# Crear ticket de soporte
Crea un ticket de Linear para el error reportado o la incidencia del usuario.

## Formato
- **Información de quien reporta:** Correo electrónico, ID de cuenta, plataforma, versión de la aplicación
- **Resumen:** Descripción breve de 1-2 frases
- **Esperado vs. real:** Qué debería pasar vs. qué pasa
- **Pasos para reproducir:** Lista numerada

## Notas
- Recopila la información del usuario a partir de los logs antes de crear el ticket
- Incluye request IDs o trace IDs si están disponibles
- Enlaza las consultas de logs o dashboards relacionados
- Usa prioridad media de forma predeterminada, a menos que se especifique lo contrario

# Redactar respuesta al cliente
Redacta una respuesta al cliente sobre su incidencia.

## Pautas
- Usa solo el nombre público del producto
- Evita nombres de servicios internos, nombres en clave o detalles de infraestructura
- No compartas códigos de error internos, rutas de archivo ni variables de entorno
- Limítate a las funcionalidades documentadas públicamente y a los pasos estándar de troubleshooting

## En caso de duda
Pregunta: "¿Podría un cliente descubrir esto mediante el uso normal del producto?"
Si no, reformúlalo usando enfoques generales de depuración.

# Buscar incidencias conocidas
Busca en Slack para determinar si una incidencia ya se conoce.

## Flujo de trabajo
1. Busca con identificadores (ID del ticket, código de error, mensaje de error exacto)
2. Acota por canal y rango de tiempo
3. Encuentra hilos con estado, solución alternativa o información del responsable

## Resultado
- **Veredicto:** Conocida / Posiblemente conocida / No encontrada
- **Mejor hilo:** Enlace permanente + resumen
- **Siguiente búsqueda:** Consulta para probar si los resultados son poco útiles

# Buscar logs
Consulta los logs de Datadog para el request, usuario o error especificado.

## Patrones comunes
- @requestId:{id} — encontrar un request específico
- @userId:{id} o @email:{email} — encontrar actividad del usuario
- status:error — filtrar solo errores
- service:{name} — filtrar por servicio

## Notas
- Especifica siempre un rango de tiempo (predeterminado: últimos 7 días)
- Los nombres de campo varían según la fuente; prueba varios patrones
- Empieza de forma amplia y luego acota según los hallazgos

#Reglas y Skills para patrones repetidos

Usamos Rules y Skills para automatizar procesos comunes en investigaciones de soporte.

# Skill: Respuesta al cliente (segura + accionable)

## Entradas que necesito
- Síntoma del cliente (lo que ve)
- Lo que encontramos (resumen fundamentado)
- Siguiente paso/solución alternativa (si la hay)
- 0–2 datos faltantes para solicitar

## Formato de resultado
- Breve confirmación
- Lo que encontramos (sin detalles internos)
- Qué probar a continuación (pasos numerados)
- Si es necesario: máximo dos preguntas (para desbloquear la investigación)
- Cierra con lo que haremos a continuación por nuestra parte

## Directrices
- Evita detalles internos de implementación y jerga interna
- Prioriza pasos concretos frente a la especulación
- Mantenlo conciso; optimiza para la "primera respuesta útil"

# Skill: Redactar un ticket de error de alta calidad

## Entradas que necesito
- Síntoma (visible para el cliente)
- Periodo de tiempo
- Cualquier ID (request id, user/team id)
- Fragmentos de evidencia (anonimizados)

## Formato de resultado
## Resumen
## Esperado vs. real
## Pasos para reproducir
## Evidencia
## Alcance/Gravedad
## Siguiente paso sugerido de depuración

## Criterio de calidad
- Sin lenguaje vago ("a veces", "no funciona") sin una condición concreta
- Sin jerga exclusivamente interna en el title
- Redacta la información específica del cliente salvo aprobación explícita

# Skill: Investigador de incidencias conocidas (Slack + Notion)

## Entradas que necesito
- Texto exacto del error (o la mejor aproximación posible)
- Palabras clave del área de la funcionalidad
- Periodo de tiempo (predeterminado: últimos 30 días)

## Workflow
- Busca primero en Slack frases exactas e identificadores.
- Si los resultados son flojos, amplía la búsqueda con palabras clave de la funcionalidad y filtros de tiempo.
- Busca en Notion runbooks/FAQ de la misma área de la funcionalidad.

## Formato de resultado
- Veredicto: Conocida / Posiblemente conocida / No encontrada
- Mejores hilos: 1–3 enlaces con una línea de "por qué es relevante"
- Solución alternativa / mitigación (si existe)
- Siguiente refinamiento de búsqueda: consulta exacta para ejecutar a continuación

#Subagentes para ejecutar pasos en paralelo

Los subagentes permiten ejecutar en paralelo pasos habituales del proceso de soporte, en lugar de hacerlo de forma secuencial.

• LogInvestigator busca en Datadog el punto de fallo y la evidencia que lo respalda.
• KnownIssueMiner revisa Slack y Notion en busca de hilos anteriores y soluciones alternativas.
• TicketWriter da formato a la evidencia para convertirla en una escalación completa.
• CustomerReplyDrafter redacta la respuesta al cliente, omitiendo los detalles internos.

Los resultados se fusionan en una única salida que revisamos y enviamos.

supportInvestigationPack:
  goal: >
    Genera un resumen fundamentado de la investigación, un borrador de ticket de error
    y una respuesta al cliente ejecutando agentes especializados en paralelo.
  inputs:
    - customer_symptom
    - time_window
    - identifiers:
        request_id: ""
        user_or_team_id: ""
        error_text: ""
    - investigation_notes
  agents:
    - name: LogInvestigator
      focus: "Datadog: identifica el punto de fallo más probable y la evidencia que lo respalda."
      output:
        - suspected_root_cause
        - strongest_evidence
        - disconfirming_checks
        - open_questions
    - name: KnownIssueMiner
      focus: "Slack/Notion: encuentra antecedentes, el estado actual y una solución alternativa."
      output:
        - verdict
        - best_links
        - workaround
        - next_search_query
    - name: TicketWriter
      focus: "Redacta un ticket de error orientado a ingeniería a partir de la evidencia + notas."
      output:
        - title
        - summary
        - expected_vs_actual
        - steps_to_repro
        - evidence
        - suggested_next_debug_step
    - name: CustomerReplyDrafter
      focus: "Redacta una respuesta al cliente: clara, segura y accionable."
      constraints:
        - "No incluyas detalles internos de implementación."
        - "Solicita como máximo dos datos que falten."
      output:
        - reply_text
        - questions_for_customer
  final_assembler:
    merges:
      - LogInvestigator
      - KnownIssueMiner
      - TicketWriter
      - CustomerReplyDrafter
    produces:
      - investigation_summary
      - ticket_draft
      - customer_reply

#Soporte técnico impulsado por IA

Al combinar estas herramientas, llevamos el análisis de código directamente al proceso de soporte técnico. Estimamos que esto permite a nuestro equipo ser hasta diez veces más productivo que con los enfoques tradicionales, que requieren más idas y vueltas entre herramientas y equipos. Esta mejora de productividad permite que nuestro pequeño (pero en crecimiento) equipo de ingenieros de soporte atienda eficazmente a nuestra base de usuarios, que crece rápidamente.

Si te interesa obtener más información sobre cómo incorporar Cursor a tu flujo de trabajo de CX, ponte en contacto.