← Volver al listado de tecnologías ← Índice de GitLab Sales Development

SLAs y KPIs del Sales Development

Por: Artiko
gitlabSLAKPImétricasSDRBDR

SLAs y KPIs del Sales Development

En GitLab, el rendimiento de un SDR o BDR no se mide con una sola cifra. Se mide a través de un conjunto de Service Level Agreements (SLAs) y Key Performance Indicators (KPIs) que cubren velocidad de respuesta, calidad de investigación, volumen de actividad y conversaciones reales con prospectos.

Entender estas métricas desde el primer día no es opcional: son el lenguaje común entre tú, tu manager y el equipo de ventas. Ignorarlas equivale a operar en modo ciego.

¿Por qué SLAs y no solo cuotas?

La cuota de pipeline (oportunidades generadas) es el resultado final, pero los SLAs son los indicadores adelantados que predicen si llegarás a esa cuota. GitLab define SLAs porque:

flowchart LR
    A[Actividad diaria\nSLAs de velocidad] --> B[Conversaciones\nbidireccionales]
    B --> C[MQLs calificadas\nAWA / 6QA]
    C --> D[Pipeline SAO\nCuota]
    style A fill:#fc6d26,color:#fff
    style B fill:#e24329,color:#fff
    style C fill:#fca326,color:#000
    style D fill:#6b4fbb,color:#fff

SLAs Inbound

Los SLAs inbound gobiernan la forma en que el equipo responde a leads que ya mostraron interés activo (rellenaron un formulario, solicitaron una demo, respondieron a un email).

Tabla de SLAs Inbound

MétricaUmbralPor qué importa
Response time — net new MQLs2 horas de trabajo desde la MQL DateUn lead caliente se enfría rápido. 2 horas es el límite para que la conversación se sienta oportuna.
Response time — inbound replies8 horas de trabajoCuando un prospecto responde, está señalando interés. Dejar pasar más de 8 horas rompe el momentum.
High Touch Sequence usageMás del 70% de leads inbound en secuencias High TouchLas secuencias High Touch combinan llamadas, emails personalizados y LinkedIn. Son más efectivas que secuencias genéricas.
Tasks past due per dayNo más del 10% pendientes; 90% completadas (no omitidas)Las tareas omitidas significan prospectos sin contactar. El 10% es el margen máximo tolerable.
Two-way conversationsMínimo 50 por semanaUna conversación bidireccional (reply, llamada conectada) es la única forma de calificar. 50 semanales aseguran suficiente señal para generar oportunidades.

Response Time: las 2 horas que cambian todo

El umbral de 2 horas para net new MQLs parte de un principio simple: el costo de oportunidad de responder tarde supera cualquier ahorro de tiempo que obtengas al agregar un lead a una cola.

“Horas de trabajo” significa que el reloj corre solo durante el horario laboral definido. Si un MQL entra a las 4:45 PM y el horario laboral termina a las 5:00 PM, tienes hasta las 2:00 PM del día siguiente para completar el primer contacto (asumiendo inicio a las 8:00 AM).

sequenceDiagram
    participant Sistema as Sistema (Salesforce / Outreach)
    participant SDR
    participant Prospecto

    Sistema->>SDR: MQL Date registrada (ej. 10:00 AM)
    Note over SDR: Reloj de 2 horas comienza
    SDR->>Sistema: Revisa MQL, crea tarea inmediata
    SDR->>Prospecto: Primer contacto (llamada + email) antes de 12:00 PM
    Prospecto-->>SDR: Responde (mismo día o siguiente)
    SDR->>Sistema: Registra conversación bidireccional

Cómo monitorizarlo: Outreach y Salesforce permiten crear vistas filtradas por MQL Date vs First Activity Date. Revisa esta vista cada mañana antes de empezar a prospectar outbound.

High Touch Sequences: calidad sobre cantidad

Una secuencia High Touch en GitLab típicamente incluye:

  1. Llamada telefónica (intento de conexión)
  2. Email personalizado con referencia al pain específico del prospecto
  3. Conexión en LinkedIn con nota
  4. Segunda llamada
  5. Email de seguimiento con valor agregado (caso de estudio, artículo relevante)
  6. Llamada final y email de ruptura (“break-up”)

El umbral del 70% no es arbitrario: significa que la mayoría de tus leads inbound deben recibir un esfuerzo multicanal real, no simplemente ser enrollados en una secuencia de emails automáticos.

Two-Way Conversations: la métrica que más importa

Las 50 conversaciones bidireccionales semanales son el KPI que mejor predice éxito a largo plazo. Una conversación bidireccional se cuenta cuando:

Por qué 50 y no más: es el número que GitLab ha determinado como suficiente para generar el pipeline necesario sin comprometer la calidad de cada interacción.

SLAs Outbound

Los SLAs outbound definen el volumen y la calidad del trabajo proactivo de identificación y desarrollo de cuentas objetivo. Aplican principalmente a BDRs (Business Development Representatives) enfocados en cuentas target.

Tabla de SLAs Outbound

MétricaUmbralPor qué importa
AWA’d accounts por trimestre — Enterprise75 cuentas por BDREnterprise requiere más investigación y ciclos más largos. 75 es el volumen manejable con calidad.
AWA’d accounts por trimestre — Hybrid Ent & Mid-Market, First Order125 cuentas por BDRMid-Market tiene ciclos más cortos; mayor volumen compensa el menor tiempo de investigación.
6QA’d accounts por trimestre25 por BDRCada cuenta 6QA’d es una oportunidad potencial para el equipo de AE. 25 por trimestre = ~2 por semana.
Research qualityMás del 80% de AWA con intent dataLa intent data confirma que la cuenta está activamente buscando soluciones. Sin ella, estás disparando a ciegas.
Prospects por cuenta5-10 por cuenta AWA, matching ICP personasDiversificar contactos por cuenta reduce el riesgo de depender de un solo punto de contacto.
6QA account review SLA48 horas para Accepted o DisputedLas cuentas auto-6QA’d requieren revisión rápida para no dejar oportunidades sin acción.

AWA (Actively Working Accounts): el corazón del outbound

AWA significa que una cuenta está en BDR Prospecting Status = Actively Working. Esto implica que el BDR ha:

  1. Investigado la cuenta (industria, tamaño, stack tecnológico, noticias recientes)
  2. Identificado entre 5 y 10 contactos que coinciden con los ICP personas (CISO, CTO, VP Engineering, etc.)
  3. Añadido intent data que justifica el contacto en este momento
flowchart TD
    A[Cuenta en territorio asignado] --> B{¿Cumple criterios ICP?}
    B -- No --> C[Excluir / monitorear]
    B -- Sí --> D[Investigación: industria\nnoticias, stack, intent data]
    D --> E{¿Intent data\npresente?}
    E -- No --> F[Watchlist / siguiente trimestre]
    E -- Sí --> G[AWA: Actively Working Account]
    G --> H[Identificar 5-10 contactos\nICP personas]
    H --> I[Iniciar secuencia outbound]
    I --> J{¿Conversación\nqualificada?}
    J -- Sí --> K[6QA: 6 Qualifier Account]
    J -- No --> L[Continuar seguimiento\no pausar cuenta]
    style G fill:#fca326,color:#000
    style K fill:#6b4fbb,color:#fff

6QA: el estándar de calificación de GitLab

6QA (6 Qualifier Account) es el marco de calificación propio de GitLab. Una cuenta llega a estado 6QA cuando cumple los 6 calificadores definidos internamente (autoridad del contacto, necesidad identificada, timing, presupuesto potencial, fit con GitLab, next step acordado).

El SLA de 48 horas para revisión existe porque las cuentas auto-6QA’d son oportunidades calientes que el sistema ha marcado automáticamente basado en señales de comportamiento. Dejarlas sin revisión más de 48 horas puede significar perder el momentum con el prospecto.

Research Quality: el 80% de intent data

El umbral de más del 80% de AWA con intent data es un control de calidad. Sin intent data, una cuenta AWA es solo un nombre en una lista. Con intent data (búsquedas activas, visitas a páginas de comparación, descarga de contenido de competidores), tienes evidencia de que la cuenta está en modo de evaluación.

Fuentes de intent data en el ecosistema GitLab:

Los Tres Pilares de Performance

GitLab organiza las expectativas de performance alrededor de tres pilares complementarios. No son métricas aisladas: se refuerzan mutuamente.

graph TD
    P1[Pilar 1\nUphold Daily Activity Metrics]
    P2[Pilar 2\nDisplay Business & Sales Acumen]
    P3[Pilar 3\nMaintain Cross-functional Relationships]
    P1 & P2 & P3 --> R[Resultado: Pipeline predecible\ny relaciones de confianza]
    style P1 fill:#fc6d26,color:#fff
    style P2 fill:#e24329,color:#fff
    style P3 fill:#6b4fbb,color:#fff
    style R fill:#fca326,color:#000

Pilar 1: Uphold Daily Activity Metrics

Este pilar cubre las métricas de actividad que garantizan que estás en el mercado de forma consistente:

Las Golden Call Hours son los bloques horarios donde la tasa de conexión es estadísticamente más alta. En mercados de habla inglesa típicamente son 8-9 AM y 4-5 PM (hora local del prospecto). En mercados de EMEA o LATAM, los BDRs ajustan estos bloques a sus zonas horarias objetivo.

Por qué 50 actividades por día: Es el volumen mínimo para que las tasas de conversión promedio (apertura de emails ~25%, respuesta ~5%, conexión de llamada ~10%) generen suficientes conversaciones bidireccionales para alcanzar las 50 semanales.

xychart-beta
    title "Embudo de actividad semanal"
    x-axis ["Actividades (250/sem)", "Emails abiertos (~62)", "Respuestas (~12)", "Llamadas conectadas (~25)", "Conversaciones 2-way (≥50)"]
    y-axis "Cantidad" 0 --> 260
    bar [250, 62, 12, 25, 50]

Pilar 2: Display Business and Sales Acumen

Este pilar mide la calidad de las interacciones, no el volumen. Dos aplicaciones concretas:

Personalización CoM (Command of the Message): Cada email o llamada outbound debe referenciar algo específico de la cuenta o del prospecto. GitLab usa el framework CoM (Command of the Message) para estructurar conversaciones que conectan los pain points del prospecto con el valor diferencial de GitLab.

Un email de baja calidad: “Hola [Nombre], quería presentarme y contarte sobre GitLab…”

Un email que demuestra acumen: “Hola [Nombre], vi que [Empresa] anunció la migración de su infraestructura a Kubernetes el mes pasado. Muchos equipos en ese proceso enfrentan el problema de X [pain conocido]. En GitLab hemos ayudado a [empresa similar] a reducirlo en Y%. ¿Vale la pena explorar si aplica a tu contexto?”

Cold Calls CoM: Las llamadas frías de calidad siguen una estructura: relevancia (por qué llamo hoy), impacto (qué problema resolvemos), pregunta de calificación. Sin estructura, las llamadas se convierten en lectura de scripts que los prospectos detectan inmediatamente.

Pilar 3: Maintain Cross-functional Relationships

El SDR/BDR no opera en un silo. Las relaciones con dos equipos son críticas:

Sales Team (AEs y SAEs): La alineación con el Account Executive asignado determina la calidad del handoff. Un BDR que no se comunica regularmente con su AE:

Field Marketing: El equipo de Field Marketing organiza eventos, webinars y campañas regionales. Un BDR que coordina con Field Marketing puede:

Ramping Periods y Lead Routing

Un SDR/BDR nuevo no enfrenta expectativas de rendimiento completo desde el día 1. GitLab define un período de ramping estructurado de 4 meses que gradúa tanto el acceso a leads como la cuota esperada.

Tabla de Ramping

NivelPeríodoLead RoutingQuota
OnboardingMes 0OffNinguna
Ramping 1Mes 150%25%
Ramping 2Mes 2100%50%
Ramping 3Mes 3100%75%
ExpertMes 4+100%100%
xychart-beta
    title "Progresión de cuota durante ramping"
    x-axis ["Mes 0\n(Onboarding)", "Mes 1\n(Ramp 1)", "Mes 2\n(Ramp 2)", "Mes 3\n(Ramp 3)", "Mes 4+\n(Expert)"]
    y-axis "% de cuota" 0 --> 100
    line [0, 25, 50, 75, 100]

Cuotas según fecha de ingreso

El mes “0” se define por cuándo ingresas dentro del mes:

Si ingresas el primer lunes del mes (o antes):

Si ingresas el día 16 o después:

Por qué importa esta distinción: Si ingresas el 15 de julio, tu Mes 0 es julio y tu Mes 1 (25% cuota) es agosto. Si ingresas el 18 de julio, tu manager puede extender el onboarding hasta agosto, dándote más tiempo antes de que el reloj de cuota empiece. Clarifica esto con tu manager en la primera semana.

Por qué el 50% de Lead Routing en Ramp 1

Recibir el 50% de leads durante el primer mes tiene una lógica específica: te da suficiente volumen para practicar el proceso completo (clasificar, secuenciar, hacer seguimiento, documentar) sin abrumarte con una cola llena mientras aún estás aprendiendo el producto, la propuesta de valor y las herramientas.

El salto al 100% de lead routing en Ramp 2 (Mes 2) es deliberado: para entonces deberías tener el proceso operativo y poder enfocarte en mejorar la calidad de las conversaciones.

Cómo Monitorizar tus SLAs día a día

La automonitorización es responsabilidad del SDR/BDR. No esperes a que tu manager te señale un SLA incumplido en el 1:1 semanal.

Herramientas clave

flowchart LR
    A[Salesforce\nFuente de verdad de leads\ny MQL Dates] --> D[Dashboard Personal\nde KPIs]
    B[Outreach\nActividades, secuencias\ny tareas] --> D
    C[6sense / LinkedIn\nIntent data y\nresearch] --> D
    D --> E[Revisión diaria\n09:00 AM]
    D --> F[Revisión semanal\nviernes]

Checklist de revisión diaria

Checklist de revisión semanal (viernes)

Resumen: el sistema de métricas como guía de acción

Los SLAs y KPIs de GitLab no son burocracia: son un sistema de feedback rápido que te dice en tiempo real si tus acciones están alineadas con los resultados esperados.

La forma más práctica de internalizarlos es agruparlos por frecuencia de revisión:

FrecuenciaMétrica a revisar
Cada horaMQLs nuevos, inbound replies
DiariaActividades totales (50/día), tareas vencidas (<10%)
SemanalConversaciones 2-way (≥50), llamadas (≥200), avance AWA trimestral
TrimestralAWA totales (75 Enterprise / 125 Mid-Market), 6QA (25/BDR), research quality (>80% intent data)

El siguiente capítulo cubre el proceso completo de calificación inbound: cómo pasar de un MQL recién asignado a una conversación calificada que el AE pueda tomar con confianza.

← Volver al listado de tecnologías ← Índice de GitLab Sales Development