Define los SLA internos entre el equipo de Customer Support y los equipos de Producto, Desarrollo y Ventas que establecen expectativas claras y eliminan los conflictos por prioridades. Con la metodología de definición de SLAs internos, los indicadores de cada tipo de acuerdo y el proceso de revisión trimestral.
Cuándo usarlo: SLA internos, acuerdos nivel servicio interno, customer support operaciones, gestión bugs soporte, handoff ventas soporte
Herramienta recomendada: Claude
Eres un Customer Support Operations Manager con experiencia implementando sistemas de SLA internos en organizaciones donde la falta de acuerdos formales entre soporte y otros departamentos generaba conflictos constantes, clientes sin respuesta y la sensación de que soporte era el último en la cadena de decisiones. Contexto: - Tamaño del equipo de soporte: [N personas] - Departamentos con los que tienes mayor fricción: [Producto / Desarrollo / Ventas / todos] - El problema más frecuente: [bugs sin priorizar / features prometidas por ventas que soporte no conoce / escalaciones sin respuesta / SLAs externos que no puedes cumplir sin apoyo interno] - Herramienta de tickets: [Zendesk / Freshdesk / Intercom / HubSpot Service / Jira Service Management] ## SLA Internos para Customer Support — [Empresa] ### 🧠 Por qué los SLA internos son más importantes que los externos **El problema sin SLA internos:** ``` ESCENARIO TÍPICO: → Un cliente reporta un bug crítico → Soporte abre un ticket en Jira y lo marca como "urgente" → Desarrollo lo ve pero tiene su propio sprint lleno → Soporte pregunta en Slack: "¿Alguien puede mirar esto?" → Nadie sabe quién debe responder ni en qué plazo → El cliente espera 5 días → El SLA externo se incumple → El problema: no es que desarrollo no se preocupe — es que no hay un acuerdo claro CON SLA INTERNOS: → El bug crítico tiene un nivel de severidad definido → Desarrollo tiene 4 horas para dar una primera respuesta y 24 horas para una estimación → Soporte puede comunicar al cliente un plazo real basado en el acuerdo interno → Si el SLA interno se incumple, hay un proceso de escalación definido ``` ### 📋 Los 4 SLA internos que toda empresa debería tener **SLA 1 — Soporte ↔ Desarrollo: gestión de bugs reportados por clientes** ``` CLASIFICACIÓN DE SEVERIDAD: SEV-1 (Crítico — sistema caído o pérdida de datos): → Impacto: cliente no puede usar el producto en absoluto → SLA respuesta interna: 1 hora (en horario laboral) / 2 horas (fuera de horario si hay guardia) → SLA estimación de fix: 4 horas → SLA fix desplegado: 24 horas → Comunicación: update al cliente cada 2 horas hasta resolución → Escalación automática a: CTO + VP Support si supera las 4 horas sin fix SEV-2 (Alto — funcionalidad importante degradada): → Impacto: el cliente puede trabajar pero con limitaciones significativas → SLA respuesta interna: 4 horas en horario laboral → SLA estimación de fix: 1 día laboral → SLA fix desplegado: 5 días laborables (dentro del sprint en curso) → Comunicación: update al cliente en 24 horas con estimación SEV-3 (Medio — funcionalidad menor afectada): → Impacto: inconveniente pero no bloquea el trabajo del cliente → SLA respuesta interna: 1 día laboral → SLA estimación de fix: 5 días laborables → SLA fix desplegado: próximos 2 sprints (2-4 semanas) → Comunicación: confirmación de recepción, se informa cuando esté fijado en sprint SEV-4 (Bajo — mejora menor o cosmético): → Entra en el backlog priorizado trimestralmente → No tiene SLA de respuesta urgente ``` **SLA 2 — Soporte ↔ Producto: solicitudes de feature provenientes de clientes** ``` EL PROBLEMA: Soporte recibe solicitudes de features de clientes constantemente. Sin un proceso, se pierden en Slack, se duplican, o se pasan sin contexto suficiente. EL ACUERDO: Obligaciones de Soporte: → Las solicitudes de feature se documentan en [herramienta: Productboard / Canny / Notion] con el formato estándar: - Descripción de lo que el cliente quiere hacer (job to be done, no la feature específica) - Empresa del cliente + ARR (para priorización por impacto) - Número de clientes que han pedido lo mismo - Impacto en churn si no se implementa (alto / medio / bajo) Obligaciones de Producto: → El PM asignado revisa las nuevas solicitudes cada lunes (30 minutos) → Cada solicitud recibe una respuesta al equipo de soporte en 5 días laborables: "Lo añadimos al roadmap Q3 / está en consideración / no es algo que vayamos a hacer porque [razón]" → El equipo de soporte necesita esta respuesta para dar una respuesta honesta al cliente NUNCA: "Lo hemos trasladado al equipo de producto" sin una fecha o resolución. ``` **SLA 3 — Soporte ↔ Ventas: handoff de cliente nuevo y promesas de ventas** ``` EL PROBLEMA: Ventas cierra un deal prometiendo features que no existen o plazos de implementación irreales. El cliente llega a soporte con expectativas que soporte no puede cumplir. EL ACUERDO: Obligaciones de Ventas antes de cerrar un deal: → Verificar con soporte/producto cualquier feature prometida antes de incluirla en el contrato → Completar el "Sales-to-Support Handoff Form" antes de la fecha de inicio del cliente: - Features especiales prometidas o negociadas - Plazos de implementación acordados - Nivel de soporte contratado (standard / premium / dedicated) - Contactos del cliente y estructura de uso - Expectativas específicas comunicadas durante el proceso de venta Obligaciones de Soporte: → Revisar el handoff form en 24 horas y confirmar que puede cumplir con lo prometido → Si hay algo que no puede cumplir: notificar a Ventas en 24h para resolverlo antes del onboarding → Participar en la llamada de kickoff del cliente nuevo (cuando el deal supera [umbral de ARR]) ``` **SLA 4 — Soporte ↔ Soporte: gestión interna de escalaciones y cobertura** ``` LOS ACUERDOS INTERNOS DENTRO DEL EQUIPO DE SOPORTE: Escalación de ticket a senior/especialista: → Un agente puede escalar si lleva más de [N] horas sin resolver → El especialista asignado tiene [N] horas para dar respuesta al agente que escala Cobertura de horarios: → Define los turnos, la cobertura de festivos y el proceso de guardia para SEV-1 → Sin esto, los SEV-1 en festivos se quedan sin atender porque "no era mi turno" Knowledge base: el agente que resuelve un ticket que no está en la KB tiene la obligación de añadir el artículo o actualizar el existente en 24 horas. ``` ### 📊 La revisión trimestral de los SLA internos ``` FRECUENCIA: trimestral — los SLA que no se revisan se quedan obsoletos o nadie los sigue. MÉTRICAS QUE REVISAR: □ Tasa de cumplimiento de cada SLA interno (¿cuántos bugs SEV-2 se resolvieron en plazo?) □ Número de escalaciones por incumplimiento □ Tendencia: ¿estamos mejorando o empeorando? □ SLA externos incumplidos que tuvieron como causa raíz el incumplimiento de un SLA interno QUIÉN PARTICIPA: → Head of Support + representante de cada equipo con SLA → La reunión es de revisión y ajuste — no de reproches OUTPUT: → Los SLA ajustados a la realidad actual (si el equipo ha crecido, los plazos pueden mejorar) → Los problemas sistémicos que requieren un cambio de proceso, no de SLA → Reconocimiento explícito de los equipos que han cumplido sus SLAs ``` ### 🔧 Cómo implementar los SLA internos sin que sean papel mojado La estrategia de implementación progresiva: cómo conseguir el buy-in de cada departamento, dónde documentar los SLAs para que sean accesibles, cómo hacer el tracking automático con las herramientas existentes (Jira, Zendesk) y cómo crear la cultura de accountability sin que la revisión de SLAs se convierta en una reunión de reproches.