Incorporación, Glosario y FAQ
Incorporación, Glosario y FAQ
En los capítulos anteriores cubriste todas las dimensiones operativas del rol de Sales Development en GitLab: desde el manejo de leads y el proceso de calificación, hasta el outreach estratégico, las herramientas tecnológicas, el uso de 6Sense y los marcos de compensación. Este capítulo cierra el tutorial reuniendo en un solo lugar los tres recursos que usarás como referencia permanente a lo largo de toda tu carrera en la organización: el proceso de incorporación estructurado para nuevos SDR y BDR, el glosario oficial de términos que aparecen en documentos, conversaciones y sistemas, y las preguntas frecuentes que resuelven los problemas más comunes del día a día.
No importa si estás en tu primera semana o llevas un año en el equipo: este capítulo es la hoja de referencia rápida a la que volver cada vez que aparezca un término desconocido, una situación de RoE ambigua o un problema técnico con las herramientas.
1. Proceso de Incorporación (Onboarding)
El onboarding de un nuevo SDR o BDR en GitLab combina entrenamiento de marketing, entrenamiento de ventas y formación técnica en un recorrido estructurado de varias semanas. El objetivo no es solo que conozcas las herramientas, sino que seas capaz de tener conversaciones de valor con prospectos técnicos desde las primeras semanas.
Diagrama del proceso de onboarding
flowchart TD
A[Día 1: Email de bienvenida + Issue de onboarding] --> B[Dentro de 3 días: Acceso a e-learning Command of the Message]
B --> C[Segunda semana: Invitación SQS por Sales Enablement]
C --> D[Workshop SQS - Sales Quick Start]
D --> E[Dentro de 1 semana post-SQS: CoM Fast Start 13 semanas]
E --> F[Primeras semanas: Sales Development Technical Development]
F --> G{¿Completado en 180 días?}
G -- Sí --> H[Habilitado para progressions y promociones]
G -- No --> I[Riesgo en progresión de carrera]
style A fill:#554488,color:#fff
style D fill:#554488,color:#fff
style H fill:#2a7d4f,color:#fff
style I fill:#8b0000,color:#fffPaso a paso del onboarding
Paso 1 — Día 1: Issue de onboarding de GitLab
People Team inicia un issue general de onboarding de GitLab. El primer día recibirás un email de bienvenida con el link a tu issue específico. Este issue es el tablero de control de todo tu proceso de incorporación: contiene tareas para ti, tareas para tu manager y links a todos los recursos necesarios.
Paso 2 — Dentro de los primeros 3 días: Command of the Message e-learning
En los primeros tres días recibirás acceso a los materiales e-learning de Command of the Message (CoM). CoM es el framework de conversación de ventas orientado a valor que usa GitLab. No es solo una metodología de pitch, es la manera en que los equipos de Sales Development articulan el valor de GitLab en términos que resuenan con los problemas reales del prospecto.
Paso 3 — Segunda semana: Invitación al SQS
Durante la segunda semana el equipo de Sales Enablement envía una invitación de calendario para el Sales Quick Start (SQS) junto con acceso al learning path en Google Classroom. Antes del workshop deberás completar el trabajo preparatorio de Google Classroom, que incluye lecturas, videos y ejercicios que te permitirán aprovechar al máximo el tiempo en vivo.
Paso 4 — Workshop SQS: Sales Quick Start
El SQS es el evento central del onboarding. Es un workshop intensivo donde practicas los conceptos de CoM, aprendes el proceso de calificación, trabajas casos simulados y te conectas con otros nuevos hires de toda la organización de ventas. Asistir al SQS no es opcional: es un requisito de graduación del onboarding.
Paso 5 — Dentro de 1 semana post-SQS: CoM Fast Start de 13 semanas
Una semana después de completar el SQS recibirás acceso al programa Command of the Message Fast Start de 13 semanas. Este programa profundiza los conceptos aprendidos en el SQS con práctica iterativa, role plays y feedback estructurado. Está diseñado para que al finalizar seas capaz de manejar conversaciones de calificación con confianza.
Paso 6 — Primeras semanas: Sales Development Technical Development
En las primeras semanas también recibirás acceso al Sales Development Technical Development training. Este programa cubre el conocimiento técnico del producto GitLab que necesitas para hablar con autoridad con prospectos de tecnología. Es fundamental completarlo dentro de los primeros 180 días, ya que está vinculado directamente a la progresión del SDR en la escala de carrera.
Checklist de graduación del onboarding
Para completar formalmente tu incorporación necesitas marcar todos estos hitos:
- Completar el issue general de onboarding de GitLab
- Completar el issue de onboarding específico BDR/SDR
- Completar el trabajo preparatorio de Google Classroom para SQS
- Asistir al workshop SQS (Sales Quick Start)
- Completar el programa de 13 semanas Command of the Message Fast Start
- Completar Sales Development Technical Development training (dentro de 180 días)
2. Glosario de Términos Frecuentes
Los siguientes términos aparecen en la documentación interna, en SFDC, en conversaciones de equipo y en los procesos de RoE. Conocerlos de memoria te ahorra tiempo en cada interacción con el sistema.
| Término | Definición |
|---|---|
| Accepted Lead | Lead que un SDR o BDR acuerda trabajar hasta calificar dentro o fuera. Cambiar el estado a Accepted es el primer compromiso formal con el lead. |
| Account | Organización rastreada en SFDC. Puede ser prospecto, cliente, ex-cliente, integrador, reseller o reseller prospectivo. La jerarquía de cuentas en SFDC sigue la estructura corporativa real. |
| Actively Working | BDR Prospecting Status que indica cuentas elegidas para outreach estratégico. Se reciclan después de 10 semanas si no hay progreso. Requiere BDR Account Strategy poblado, notas de Research y Next Steps cargadas dentro de los primeros 10 días, y mínimo 5 personas en secuencias activas. |
| AE | Account Executive. En AMER y EMEA Enterprise puede ser Major Account Executive o Strategic Account Executive (SAE). |
| APJ | Asia-Pacific y Japón. Una de las tres grandes regiones comerciales de GitLab junto con AMER y EMEA. |
| BDR | Business Development Representative. Rol enfocado en outbound: identificación y prospección activa de cuentas de alto potencial que aún no tienen relación comercial con GitLab. |
| CoM | Command of the Message. El framework de conversación de ventas orientado a valor de GitLab. Define cómo articular valor, descubrir problemas y posicionar soluciones en términos que importan al prospecto. |
| EwP | Expand with Purpose. Estrategia para cuentas estratégicas de Rank 1 con alta intención detectada por 6Sense. Estas cuentas se trabajan de forma muy estrecha junto con el SAE responsable. |
| FO | First Order. Cuentas sin relación comercial previa a nivel del Ultimate Parent Account (UPA). El concepto de “primera orden” se refiere a la primera transacción de la jerarquía corporativa completa, no solo de una subsidiaria. |
| Groundswell | Estrategia outbound enfocada en generar engagement, opt-ins, MQLs y señales de intención en la parte superior del funnel. Apunta a construir masa crítica de interés antes de un push comercial directo. |
| High Priority Lead | Lead marcado como High Priority por membresía en una campaña y match con una cuenta en estado Actively Working. Requiere seguimiento más rápido que los leads estándar. |
| IQM | Initial Qualifying Meeting. Primera reunión formal entre el prospecto y el AE o SAE. Es el evento que marca la conversión de un lead calificado en pipeline activo. |
| LAM | Licencable Addressable Market. Estimación del máximo potencial de usuarios de GitLab en una empresa específica. Se calcula en base a los empleados que podrían beneficiarse de las herramientas de DevSecOps. |
| MQL | Marketing Qualified Lead. Consulta calificada a través del sistema de lead scoring que combina criterios demográficos, firmográficos y conductuales definidos por Marketing. |
| Queued | BDR Prospecting Status que indica cuentas esperando para moverse a Actively Working. Los SDRs trabajan los MQLs que provienen de cuentas en este estado. |
| Restricted | BDR Prospecting Status que indica una restricción indicada por el SAE en la cuenta. Los BDRs deben manejar el cambio de estado, documentar la razón de la restricción y redirigir la actividad al BDR asignado. |
| SAO | Sales Accepted Opportunity. Una oportunidad que el equipo de Sales acepta perseguir formalmente después de completarse un IQM. Es el KPI principal de los BDRs y el momento en que se genera crédito de compensación. |
| SDR | Sales Development Representative. Rol enfocado en inbound: calificación y gestión de leads que llegan a través de canales de marketing, formularios web, trials y campañas. |
| TEDD | Technology, Engineering, Development, and Design. Segmento de empleados utilizado para estimar el máximo potencial de usuarios de GitLab (LAM) dentro de una empresa. |
| UPA | Ultimate Parent Account. La cuenta de nivel superior en la jerarquía corporativa dentro de SFDC. Toda la lógica de First Order (FO) y las estrategias de cuentas se evalúan a nivel UPA. |
| Worked in FY | BDR Prospecting Status que indica que la cuenta ya pasó por el estado Actively Working en el fiscal year actual. Se puede mover de vuelta a Actively Working más adelante si aparece nueva intención o nueva oportunidad. |
| 6QA | 6Sense Qualified Account. Cuenta que ha alcanzado el umbral de calificación de 6Sense basado en señales de intención agregadas. Las 6QAs se auto-importan como nuevas cuentas en SFDC cuando no existían previamente. |
3. FAQ — Troubleshooting General de Sales Dev
Esta sección responde los problemas técnicos y operativos más frecuentes que encuentran SDRs y BDRs en su trabajo diario. Si tu problema no está aquí, el primer punto de contacto es Sales Dev Operations.
P: No puedo ver ciertas colecciones de Outreach.
R: Probablemente fuiste agregado al equipo incorrecto de Sales Dev en Outreach. Algunas colecciones de secuencias y snippets están segmentadas por equipo (inbound vs. outbound, región, segmento). Contactar a Sales Dev Operations para que corrijan tu asignación de equipo.
P: Mi versión de Salesforce parece muy básica, no veo todos los campos ni las vistas que describen en la documentación.
R: Asegúrate de estar usando la versión Sales de Salesforce. En la esquina superior derecha encontrarás un botón desplegable azul que dice el nombre de la app actual. Despliégalo y selecciona “Sales”. La versión básica o Lightning App que carga por defecto a veces no incluye todas las vistas y widgets necesarios para el rol.
P: No he recibido acceso a todas mis herramientas y ya pasó una semana desde que empecé.
R: Notificar inmediatamente a tu manager y pedirle que comente en tu Onboarding Role Entitlements Issue. Los accesos a herramientas (Outreach, ZoomInfo, 6Sense, LinkedIn Sales Navigator, entre otras) se gestionan a través de ese issue. Si el issue no tiene los comentarios correctos del manager, el proceso de aprovisionamiento puede quedar detenido.
P: Subí más leads de ZoomInfo de los que aparecen en mi vista ZoomInfo Lead View en SFDC.
R: Estos leads probablemente ya existen en SFDC como Contacts en lugar de Leads. Cuando ZoomInfo intenta crear un registro que ya existe como Contact, SFDC no genera un Lead duplicado. Busca esos registros en tu vista ZoomInfo Contacts, no en la vista de Leads.
P: No sé qué acción realizó esta persona para calificar como MQL.
R: Hay dos lugares donde encontrar esta información. Primero, verificar el campo “Last Interesting Moment” en el registro SFDC del lead: describe la última acción significativa que disparó la calificación. Segundo, verificar el tab “Scoring” dentro del widget de Marketo Sales Insight en la página del lead, que muestra el detalle completo del puntaje acumulado y las acciones que lo generaron.
P: Un prospecto me envió una solicitud de datos personales (quiere saber qué información tenemos sobre él o quiere que la eliminemos).
R: Este tipo de solicitudes activan derechos legales de privacidad de datos. No las manejes directamente ni prometas nada al prospecto. Redirigir al prospecto al formulario Personal Data Subject Request de GitLab y reenviar cualquier email relacionado a [email protected]. No es tu responsabilidad procesar la solicitud, solo encauzarla correctamente.
P: ¿Por qué los BDRs ya no son el Account Owner en SFDC?
R: El cambio fue intencional para mejorar la visibilidad conjunta de Sales Dev y Sales sobre todos los prospectos y cuentas. Cuando el BDR era el Account Owner, los reportes cruzados entre equipos eran complicados. La solución fue mover la propiedad a un campo dedicado: usa el campo “BDR Assigned” para filtrar y encontrar tus cuentas en cualquier vista o reporte.
P: Un prospecto me dijo que iba a comprar a través del website de GitLab. ¿Cómo sé si realmente lo hizo y si tengo crédito?
R: Los SDRs reciben crédito por oportunidades donde tuvieron comunicación bidireccional significativa con el prospecto dentro de los 60 días anteriores a la compra web direct. Verifica en SFDC si existe una oportunidad Web Direct asociada al prospecto. Si la hay y tienes actividad bidireccional registrada en ese ventana de 60 días, procede a solicitar el crédito.
P: ¿Cómo solicito formalmente el crédito por una oportunidad web direct?
R: El proceso tiene tres pasos en Chatter sobre el registro de la oportunidad en SFDC:
- Tagear a Ramona Elliott, Ed Bao o Brian Tabbert. No contactar a Sales Support directamente para este tipo de solicitudes.
- Incluir el link al registro SFDC que muestra la actividad bidireccional ocurrida en los últimos 60 días.
- Explicar en pocas líneas cómo influiste en la decisión de compra del prospecto.
La revisión de estos casos toma tiempo, así que envíalo tan pronto como identifiques la oportunidad.
4. FAQ — RoE: Preguntas Comunes sobre Reglas de Engagement
Las Rules of Engagement (RoE) son las que más generan dudas en situaciones de borde. Estas son las más frecuentes.
P: ¿Deben los BDRs marcar cuentas duplicadas cuando las encuentran?
R: Sí. Los BDRs no tienen permisos para fusionar cuentas ellos mismos en SFDC. Cuando encuentres una cuenta duplicada, haz Chatter mencionando a @Sales Support y pídeles que realicen la fusión. No intentes resolverlo editando campos manualmente, ya que eso puede romper relaciones de oportunidades y jerarquías de cuentas.
P: ¿Cómo resolvemos una disputa sobre crédito de SAO entre un SDR y un BDR?
R: El proceso de resolución tiene tres niveles:
- SDR y BDR intentan resolver el desacuerdo entre ellos primero.
- Si no hay acuerdo, los managers de ambos deciden.
- Si los managers no se ponen de acuerdo, escalar a Senior Leadership.
No se otorga doble crédito ni doble compensación en ningún caso. La regla de escalación es clara y rápida para no dejar casos abiertos durante semanas.
P: ¿Qué pasa si un prospecto regresa directamente al BDR después de que la cuenta ya no está en estado Actively Working?
R: Si el prospecto toma contacto directo con el BDR (responde un email, contesta en LinkedIn o llama) después de que la cuenta salió de Actively Working, el BDR debe:
- Verificar que el lead esté en queue ownership.
- Mover la cuenta de vuelta a Actively Working.
Solo después de ese cambio el lead puede transferirse al ownership del BDR y procesarse correctamente. No intentar trabajar el lead sin que la cuenta esté en el estado correcto.
P: ¿Por qué mis leads están siendo reasignados a Inquiry Queue sin que yo haya hecho nada?
R: Marketing Ops corre una limpieza automatizada todos los días a las 10:30 PM EST. Este proceso actualiza todos los leads que tienen Lead Status = Inquiry asignándolos a la Inquiry Queue. Para prevenir que tus leads caigan en esta limpieza, debes actualizar el Lead Status a “Accepted” o agregarlos a una secuencia en Outreach antes de que corra el proceso nocturno.
P: ¿Qué deben hacer los BDRs cuando un prospecto expresa objeción a ser contactado?
R: Si un prospecto indica explícitamente que no quiere ser contactado, el proceso es:
- Contactar al Privacy Team a través del canal #privacy-team-help en Slack.
- Reenviar cualquier email del contacto a [email protected].
No continuar con ningún tipo de outreach hacia ese contacto hasta recibir confirmación del Privacy Team. Las solicitudes de opt-out tienen implicaciones legales bajo GDPR y otras regulaciones de privacidad.
P: ¿Cómo sé si un lead que recibí ya está siendo trabajado por un Partner?
R: Verifica el campo “Impartner Partner Account” en el registro del lead en SFDC. Si ese campo está poblado, significa que el lead está asignado al Partner Queue y existe un Partner activo trabajándolo. En ese caso, no proceder con outreach directo. Cualquier coordinación debe hacerse a través del canal correcto con el equipo de Partners.
5. Tanuki Tech
Tanuki Tech, también conocido como Tanuki Institute of Technology, es el bootcamp de ventas y tecnología que GitLab proporciona exclusivamente para la organización de Sales Development. El nombre juega con Tanuki, la mascota oficial de GitLab.
¿Qué es Tanuki Tech?
No es un curso único, sino un sistema de cursos progresivos organizados por trimestre (Q1 a Q4) que avanza en complejidad técnica y de ventas a medida que creces en la organización. El objetivo es que cada miembro del equipo desarrolle profundidad genuina en el producto y en la metodología de ventas, no solo conocimiento superficial.
Estructura de cursos por rol
| Rol | Cursos esperados | Impacto en carrera |
|---|---|---|
| SDR | Q1-Q4 Tanuki Techs progresivos | Requeridos para progressions y promociones |
| BDR | Q1-Q4 Tanuki Techs progresivos | Requeridos para progressions y promociones |
Los cursos Q1 cubren fundamentos de producto y metodología CoM básica. Los cursos Q2 y Q3 aumentan complejidad técnica y de conversación. El Q4 típicamente incluye simulaciones avanzadas de situaciones reales y preparación para el siguiente nivel en la escala de carrera.
Dónde encontrar los cursos
Los cursos de Tanuki Tech están disponibles en el canal GitLab LevelUp Training. LevelUp es la plataforma de aprendizaje interno de GitLab donde se publican todas las certificaciones, rutas de aprendizaje y exámenes de la organización. Verifica regularmente el canal porque se publican nuevas cohortes al inicio de cada trimestre.
Exámenes y certificaciones
Cada Tanuki Tech incluye un componente de examinación. Los resultados de los exámenes quedan registrados y son visibles para los managers durante los ciclos de evaluación de progressions. Completar los Tanuki Techs no es solo una recomendación: es parte de los criterios objetivos que los managers usan para evaluar si un SDR o BDR está listo para el siguiente nivel.
6. Recursos para Managers
Esta sección está dirigida a los managers de Sales Development y cubre el proceso de onboarding de nuevos hires desde la perspectiva del manager, las responsabilidades de offboarding y los recursos de liderazgo disponibles.
Onboarding de nuevos hires: responsabilidades del manager
Cuando un nuevo SDR o BDR se incorpora al equipo, el manager tiene un conjunto de responsabilidades paralelas al proceso del nuevo hire.
Proceso de onboarding desde el rol de manager (4 pasos)
flowchart LR
P1[Paso 1: Clonar Action Needed Dashboard y editar reports con nombres del equipo] --> P2[Paso 2: Revisar dashboard con el equipo y conectar con KPIs]
P2 --> P3[Paso 3: Notar discrepancias en 1:1s semanales]
P3 --> P4[Paso 4: Establecer expectativas de KPI realistas y cadencia de revisión]
style P1 fill:#554488,color:#fff
style P4 fill:#2a7d4f,color:#fffAntes del Día 1:
- Completar todas las tareas asignadas al Manager en el onboarding issue del nuevo hire.
- Programar una llamada de bienvenida para el primer día.
Después de que el nuevo hire comenzó:
- Completar las tareas restantes asignadas al Manager en el issue.
- Configurar la cadencia de 1:1s semanales.
- Agregar al nuevo hire al Action Needed Dashboard con su nombre.
Disponibilidad regional del equipo de Sales Dev Ops
El equipo de Sales Dev Operations es el soporte técnico y operativo para todos los SDRs, BDRs y managers. La asignación regional determina a quién contactar según tu zona horaria.
| Región / Timezone | Ops DRI | DRI Complementario |
|---|---|---|
| AMER | TBH | — |
| EMEA / APJ | Panos Rodopoulos | N/A |
Para problemas urgentes fuera del horario de tu DRI regional, usa el canal de Slack correspondiente de Sales Dev Ops y describe el problema con claridad para facilitar la respuesta asíncrona.
Onboarding de managers nuevos o promovidos
Cuando un manager se une a GitLab o es promovido desde un rol de IC, People Team crea automáticamente un issue “Becoming a GitLab Manager” específico para esa persona. Este issue contiene el checklist completo de responsabilidades del rol de manager, incluyendo acceso a sistemas de HR, comprensión de ciclos de compensación y protocolos de feedback.
Offboarding de miembros del equipo
Cuando un miembro del equipo deja GitLab, el proceso es el siguiente:
- People Team crea un Sales Dev Handover Issue para ese miembro.
- El manager debe completar todas las tareas asignadas al Manager dentro del offboarding issue del People Team.
- El Handover Issue documenta el estado de las cuentas, las secuencias activas, los leads en proceso y cualquier oportunidad pendiente para que el equipo pueda continuar sin pérdida de contexto.
No esperar a que el miembro haya salido para empezar el offboarding: el proceso debe iniciarse tan pronto como se confirme la fecha de salida.
Recursos de liderazgo
| Recurso | Propósito |
|---|---|
| Leadership Handbook | Herramientas, guías y recursos para people managers en GitLab. Cubre desde cómo hacer 1:1s efectivos hasta cómo manejar situaciones de bajo rendimiento. |
| Compensation Review Cycle | Guía de cómo realizar el Compa Review (revisión de compensación) para los miembros del equipo durante los ciclos oficiales de GitLab. |
| Sales Dev Manager Onboarding Checklist | Checklist que debe completarse para confirmar conocimiento de todas las herramientas, procesos y expectativas del rol de manager en Sales Dev. |
| 360 Feedback | Calendario y guía para los ciclos de feedback cross-funcional. Incluye cómo solicitar feedback, cómo darlo y cómo incorporarlo en los planes de desarrollo del equipo. |
| Workday | Sistema central donde se encuentra toda la información de HR de los miembros del equipo: datos de contratación, historial de compensación, días libres, documentos de performance. |
Cierre del tutorial
Llegaste al final del tutorial “GitLab Sales Development de 0 a Hero”. En estos 12 capítulos recorriste todo el ecosistema del rol de Sales Development en GitLab: la estructura organizacional, el proceso de calificación de leads, las herramientas tecnológicas, las estrategias de prospección inbound y outbound, el uso de 6Sense para señales de intención, los frameworks de Account Strategy, los procesos de compensación y carrera, y finalmente este capítulo de referencia con el glosario, el FAQ y el proceso de onboarding completo.
El objetivo no fue darte una lista de procedimientos a memorizar, sino que entiendas el “por qué” detrás de cada proceso. Cuando entiendes por qué existe cada regla de RoE, por qué los estados de prospectos funcionan como funcionan o por qué CoM articula el valor de la manera en que lo hace, puedes adaptarte a situaciones que ningún manual cubre explícitamente.
Usa este capítulo como referencia permanente. El glosario y el FAQ son recursos vivos: la organización evoluciona, los procesos cambian y las herramientas se actualizan. Siempre verifica en el Sales Development Handbook de GitLab si hay cambios recientes antes de tomar decisiones importantes basadas en las reglas de engagement.