Cómo Accionar tus Leads

Acccionar un lead de forma correcta no es solo cuestión de velocidad — es cuestión de método. GitLab tiene un sistema de decisiones claro que determina cómo contactar a cada prospecto, qué canal usar y qué secuencia aplicar. En este capítulo cubrimos todo el flujo: desde la búsqueda de número de teléfono hasta la gobernanza de secuencias.

---

High Touch vs Low Touch

La regla de oro es simple: SIEMPRE hace default a High Touch. Low Touch es el último recurso, no el camino cómodo.

¿Por qué High Touch primero?

Las secuencias High Touch combinan múltiples canales (email, teléfono y LinkedIn) lo que aumenta significativamente la tasa de respuesta. El teléfono sigue siendo el canal de mayor conversión en outbound. Usar solo email (Low Touch) reduce las posibilidades de conectar con el prospecto de forma relevante.

Diagrama de decisión

flowchart TD
    A[Nuevo Lead] --> B{¿Tiene número de teléfono en SFDC?}
    B -- Sí --> HT[Secuencia High Touch\nMulticanal · 10+ pasos · ~2 semanas]
    B -- No --> C[Buscar en ZoomInfo / Cognism / SalesNav por email]
    C --> D{¿Encontró número?}
    D -- Sí --> HT
    D -- No --> E[Investigación manual\nWebsite empresa, LinkedIn, etc.]
    E --> F{¿Encontró número?}
    F -- Sí --> HT
    F -- No --> LT[Secuencia Low Touch\nHasta 4 emails automatizados · Duración corta]

Paso 1 — Buscar número de teléfono

Antes de seleccionar una secuencia, agota las tres fuentes de búsqueda en orden:

1. SFDC: verificar el campo de teléfono en el registro del Lead o Contact.
2. Herramientas de datos (ZoomInfo, Cognism, SalesNav): buscar el mismo contacto usando su email como identificador.
3. Investigación manual: website de la empresa (sección “About”, “Team”, “Contact”), perfil de LinkedIn, etc.

Si en cualquiera de esos tres pasos encuentras un número de teléfono válido, el resultado es el mismo: secuencia High Touch.

Paso 2 — Seleccionar tipo de secuencia

Resultado de búsqueda	Secuencia a usar
Número encontrado (cualquier fuente)	High Touch — multicanal (email + teléfono + LinkedIn), ~2 semanas, 10+ pasos
Sin número tras 3 verificaciones	Low Touch — hasta 4 pasos de email automatizados, duración corta

Low Touch no es una decisión de comodidad. Es el resultado de agotar genuinamente las tres fuentes de búsqueda y no encontrar un número de teléfono.

---

Do Not Call (DNC)

El campo Do Not Call en el registro de Lead o Contact es una restricción legal y ética — no una preferencia. Violarlo puede tener consecuencias para GitLab y para ti.

Reglas básicas

• Antes de cualquier llamada: verificar el campo Do Not Call en el registro.
• Do Not Call = true: no llamar. Sin excepciones, sin escalaciones informales.
• Si el prospecto pide no ser llamado durante una conversación: establecer Do Not Call = true de inmediato. No borrar el número de teléfono — solo se activa el flag.

¿Cuándo se puede desmarcar Do Not Call?

Para remover el flag de Do Not Call, ambas condiciones deben ser verdaderas simultáneamente:

1. El opt-in de email está activo (Do Not Email = false).
2. El prospecto declaró explícitamente que quiere ser llamado.

Importante: no puedes enviar un email a un contacto sin opt-in de email para preguntarle si quiere ser llamado. Eso sería usar un canal no autorizado para solicitar permiso sobre otro canal no autorizado.

---

Email, Unsubscribe y Do Not Contact

Obligaciones en email outbound

Cada email outbound enviado por un BDR debe contener un link de unsubscribe funcional. Esto es un requisito de compliance, no una buena práctica opcional.

Automatizaciones de Marketo

Marketo puede establecer automáticamente los flags DNC (Do Not Call) o DNE (Do Not Email) basado en:

• País del prospecto (regulaciones locales como GDPR, CASL, etc.)
• Lead source
• Tipo de dominio
• Criterios específicos del equipo de compliance

No anules estos flags sin instrucción explícita de Marketing Ops o del equipo de Privacy. Si un flag parece incorrecto, escala — no lo borres unilateralmente.

Jerarquía de restricciones

flowchart LR
    A[Marketo auto-flag] --> D{¿Restricción aplicada?}
    B[Solicitud del prospecto] --> D
    C[Regulación del país] --> D
    D -- Sí --> E[Respetar el flag\nsin excepciones]
    D -- No --> F[Continuar outreach\nnormal]

---

White Glove Event Follow-Up

Los eventos de alto impacto — especialmente Executive Roundtables — generan oportunidades que requieren un tratamiento diferenciado. El campo Last Event Notes en SFDC puede contener instrucciones específicas, incluyendo los nombres de miembros de GitLab que interactuaron con el prospecto durante el evento.

Proceso de seguimiento White Glove

Paso 1 — Enrolar al prospecto: Agregar al prospecto en la secuencia White Glove dentro de la Outreach Collection White Glove.

Paso 2 — Personalizar el primer email: El primer paso de la secuencia no es automático — requiere personalización manual. En el email debes:

• Referenciar el evento específico donde se conocieron.
• Mencionar o poner en CC a los individuos de GitLab citados en el campo Last Event Notes.

Paso 3 — Enviar screenshot al SAE/AE: Una vez enviado el email personalizado, tomar un screenshot y enviarlo al SAE/AE(s) que estuvieron en CC. Esto mantiene al equipo de cuenta al tanto del outreach y crea visibilidad.

Paso 4 — Tarea de seguimiento (Día 12): La secuencia White Glove incluye una tarea integrada en el Día 12 para hacer follow-up con el SAE/AE si el prospecto no ha tenido engagement hasta ese momento. Este paso no es opcional — es parte del proceso de responsabilidad compartida.

Resumen del flujo White Glove

sequenceDiagram
    participant BDR
    participant Outreach
    participant SAE_AE as SAE/AE
    participant Prospecto

    BDR->>Outreach: Enrolar en secuencia White Glove
    BDR->>BDR: Leer Last Event Notes en SFDC
    BDR->>Prospecto: Email personalizado (CC a miembros GitLab mencionados)
    BDR->>SAE_AE: Screenshot del email enviado
    Note over Outreach: Día 12
    Outreach->>BDR: Tarea: ¿Hubo engagement?
    alt Sin engagement
        BDR->>SAE_AE: Follow-up coordinado
    else Con engagement
        BDR->>BDR: Continuar proceso normal
    end

---

High Priority Campaigns y Leads

¿Cuándo un lead es High Priority?

Un lead es marcado como High Priority cuando se cumple al menos una de estas dos condiciones:

• Es miembro de una campaña en SFDC donde el campo High Priority = true.
• Su cuenta asociada tiene BDR Prospecting Status = Actively Working.

Cómo identificar leads High Priority

Los leads de alta prioridad aparecen automáticamente en la vista B1 priority en SFDC. Dos campos clave te dan contexto:

Campo en SFDC	Descripción
High Priority Timestamp	Fecha y hora exacta en que se aplicó el flag
High Priority Reason	La campaña específica o el trigger que provocó la clasificación

Revisar ambos campos antes de contactar al lead te permite personalizar el approach con el contexto correcto (¿por qué es high priority ahora? ¿qué campaña lo activó?).

Mover un lead fuera de High Priority sin contactarlo

A veces un lead High Priority no puede o no debe ser contactado (por ejemplo, ya está siendo trabajado por otro equipo, o hay un bloqueo temporal). En ese caso existe una secuencia específica que:

1. Crea una tarea de seguimiento.
2. Mueve al lead al estado Accepted.
3. Remueve el flag de High Priority.

No muevas manualmente el flag — usa la secuencia designada para garantizar que el proceso quede documentado correctamente.

---

Gobernanza de Secuencias

Las secuencias de Outreach no son documentos vivos que cualquiera puede editar. Tienen un proceso de aprobación de cuatro etapas que garantiza calidad, consistencia y rendimiento.

Las 4 etapas

Etapa	Responsable	Acción
1. Request	XDR Manager	Abrir un issue cuando hay un gap de mensajería. Transferir ownership del BDR al Manager para que la secuencia no quede huérfana
2. Manager Review	XDR Manager	Validar naming, tags, Schedule Days, tracking, throttle limits y variables. Al aprobar: aplicar label “Manager Checked and Approved”
3. Director Approval	Regional Director	Spot-check del contenido y configuraciones. Activar la secuencia. Aplicar label “Director Launched and Monitoring” con fecha de revisión a 60 días
4. Performance Review	Director + Manager	A los 60 días: evaluar métricas y decidir si se promueve a Good Collection, se mantiene con ajustes, o se depreca

Flujo de gobernanza

flowchart TD
    A[BDR detecta gap de mensajería] --> B[XDR Manager abre issue\ny toma ownership]
    B --> C[Manager Review\nNaming · Tags · Schedule · Throttle · Variables]
    C --> D{¿Aprobado?}
    D -- No --> B
    D -- Sí --> E[Label: Manager Checked and Approved]
    E --> F[Regional Director\nSpot-check y activación]
    F --> G[Label: Director Launched and Monitoring\nFecha: +60 días]
    G --> H{Performance Review a los 60 días}
    H -- Alta performance --> I[Promover a Good Collection]
    H -- Ajustes menores --> J[Mantener con cambios]
    H -- Bajo rendimiento --> K[Deprecar]

Una secuencia que salta estas etapas no debería estar activa. Si encuentras una secuencia sin los labels correctos, repórtala a tu Manager.

---

Traducción de Secuencias

Solo se pueden traducir secuencias que completaron el proceso de gobernanza completo. Traducir una secuencia en borrador o sin aprobación es crear deuda de proceso.

Proceso de traducción

1. Identificar la secuencia en inglés aprobada (con labels de Manager y Director).
2. Clonar la secuencia en Outreach.
3. Reemplazar cada paso con el contenido localizado.
4. La secuencia traducida también debe pasar por el proceso de gobernanza.

DRIs por idioma

Idioma	Sales Dev DRI	Soporte de Localización
AMER Spanish	Kenia Rodriguez	Disponible
AMER Portuguese	Leo Viera	Disponible
EMEA Spanish	Camilo Hernandez Murillo	Disponible
French	TBD	Disponible — sin emojis; saludo formal: “Hello [Last Name]“
German	Riko Pfennig	Disponible — tono muy formal; sin emojis
Japanese	Eri Nitani	Disponible
Italian	Francesca Gianfiglio	Disponible

Cada idioma tiene convenciones culturales específicas. Las notas de la columna de soporte no son sugerencias — son requisitos de localización. El alemán y el francés, por ejemplo, tienen expectativas de formalidad distintas al inglés o al español latinoamericano.

---

Firma de Email

Las firmas de email se provisionan automáticamente basado en el perfil de Okta de cada BDR. No necesitas configurar tu firma manualmente.

Para verificar que tu firma está correcta y actualizada, consulta el handbook de OpenSense. Si hay discrepancias entre lo que aparece en Outreach y tu perfil de Okta, el canal correcto de resolución es a través de IT o de tu Manager — no edites la firma directamente en Outreach.

---

Resumen del Capítulo

Este capítulo cubrió los pilares del accionar correcto de leads en GitLab:

• Entender la regla de default High Touch y cuándo aplica Low Touch
• Conocer las tres fuentes de búsqueda de número de teléfono en orden
• Respetar y gestionar correctamente los flags DNC y DNE
• Aplicar el proceso White Glove para eventos de alto impacto
• Identificar y gestionar leads High Priority desde la vista B1
• Conocer las 4 etapas de gobernanza antes de crear o modificar secuencias
• Entender las convenciones de localización por idioma

En el siguiente capítulo profundizamos en la gestión de cuentas y la coordinación con el equipo de ventas (AE/SAE) para maximizar la efectividad del outreach.