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

Gestión de Base de Datos de Leads

Por: Artiko
gitlabsalesforceleadsduplicadosmergebase-de-datos

Gestión de Base de Datos de Leads

Uno de los mayores riesgos en un equipo de ventas es trabajar sobre datos sucios. Duplicados sin resolver, leads mal enrutados, registros con información geográfica incorrecta o contactos de baja calidad que consumen tiempo sin ningún potencial de conversión. Este capítulo cubre el proceso completo de due diligence que todo SDR de GitLab debe aplicar antes de trabajar un lead: cómo buscar duplicados, cómo interpretar los resultados, qué acción tomar según las Rules of Engagement (RoE), cómo fusionar registros y cómo limpiar la base cuando es necesario.

Campos clave para la gestión de leads

Antes de tocar un solo registro, es fundamental entender qué campos de Salesforce te dan la información necesaria para tomar decisiones correctas. Estos son los ocho campos que debes revisar en cualquier lead:

CampoDescripción
Lead StatusEstado actual del lead dentro del ciclo de ventas (MQL, Accepted, Recycle, etc.)
Matched Account InfoInformación de la cuenta con la que Salesforce ha hecho match automático del lead
BDR Prospecting StatusIndica si la cuenta asociada está siendo activamente prospectada por un BDR
Account TypeClasifica la cuenta como Customer (cliente activo) o Prospect (potencial cliente)
BDR AssignedBDR responsable de la cuenta matcheada, si existe
Initial SourceCanal o campaña que originó el lead por primera vez
Admin Company OverrideCampos de dirección que permiten corregir manualmente la ubicación geográfica del lead
Matched Opportunities InfoMuestra oportunidades abiertas o cerradas recientemente vinculadas a la cuenta

Estos campos forman el mapa de navegación para cualquier decisión de enrutamiento. Sin revisarlos, es imposible saber si estás pisando territorio de otro SDR, interrumpiendo un deal activo o procesando un lead que ya existe como contacto en otra forma.

Flujo de decisión general

Antes de entrar al detalle de cada paso, este diagrama muestra la lógica completa de gestión de un lead:

flowchart TD
    A[Lead entra al sistema] --> B[Paso 1: Buscar duplicados]
    B --> C{¿Se encontraron duplicados?}
    C -- No --> D[Priorizar match por Email Domain]
    C -- Sí --> E[Paso 2: Evaluar resultados]
    D --> E

    E --> F{¿Account Type = Customer?}
    F -- Sí y SMB --> G[Convertir y adjuntar a cuenta existente\nVerificar Total_CARR__c mayor que 0]
    F -- No --> H{¿Hay Opportunity abierta?}

    H -- Sí --> I[Lead Status = Recycle\nRecycle Reason = Evaluating]
    H -- No --> J{¿BDR Prospecting Status?}

    J -- Actively Working --> K[Verificar actividad últimos 30 días\nluego transferir al BDR]
    J -- Restricted --> L{¿Es cuenta Major?}
    J -- Ninguno --> M[Verificar duplicados y fusionar]

    L -- Sí --> N[Convertir lead a Contact\nChatter al AE inmediatamente]
    L -- No --> O[Chatter al SAE\nEsperar permiso 48 horas]

    M --> P{¿Dirección coincide con investigación?}
    P -- No --> Q[Poblar Admin Company Override]
    P -- Sí --> R[Proceder con enrutamiento normal]

    G --> S[Fin: Lead procesado]
    I --> S
    K --> S
    N --> S
    O --> S
    Q --> R
    R --> S

Paso 1 — Encontrar duplicados

El primer movimiento al recibir un lead es verificar si ya existe en la base de datos. Salesforce tiene una herramienta nativa para esto.

Cómo hacerlo en SFDC Classic:

  1. Abrir el registro del Lead
  2. Presionar el botón “Find Duplicates” ubicado en la barra de acciones del record
  3. Salesforce ejecuta una consulta simultánea sobre tres objetos: Leads, Contacts y Accounts

Esto te da visibilidad de si el contacto ya existe en alguna forma dentro del CRM, ya sea como lead activo, como contacto vinculado a una cuenta o como parte del registro de una empresa ya conocida.

Si no aparecen resultados

Cuando la búsqueda no devuelve nada, no significa que no haya duplicados: puede ser que el nombre o el email no coincidan exactamente. En ese caso, prioriza el match solo por Email Domain. Busca manualmente en Accounts si hay registros con el mismo dominio corporativo que el email del lead. Este paso es especialmente útil para empresas con múltiples empleados que ya tienen relación comercial con GitLab.

Paso 2 — Evaluar los resultados

Una vez que tienes los resultados de la búsqueda, el objetivo es responder tres preguntas antes de tomar cualquier acción:

¿Ya están trabajando leads similares?

Revisa el Lead Status y el Created Date de cualquier lead duplicado. Si hay un lead con status “Accepted” o “Qualifying” creado hace menos de 30 días, significa que otro SDR ya está en contacto activo. Actuar sin coordinación crea una experiencia horrible para el prospecto y conflictos internos en el equipo.

¿Existe una cuenta matcheada?

Revisa el campo Matched Account Info para saber si Salesforce ya vinculó el lead a una cuenta existente. Si existe, lo siguiente es revisar:

Estos dos campos juntos determinan el 80% de las decisiones de enrutamiento que verás en el Paso 3.

¿Hay Opportunities abiertas o cerradas recientemente?

Revisa el campo Matched Opportunities Info. Las reglas de GitLab son claras al respecto:

Paso 3 — Accionar según las Rules of Engagement (RoE)

Con la información de los pasos anteriores, ya puedes determinar la acción correcta. Las RoE de GitLab cubren todos los escenarios posibles:

Escenario 1: Account Type = Customer Y el lead es de segmento SMB

Acción: Convertir el lead y adjuntarlo a la cuenta existente.

Antes de hacerlo, verifica que el campo Total_CARR__c sea mayor que cero. Este campo confirma que la cuenta tiene contrato activo y ARR real. Si está en cero, puede ser un error de datos o una cuenta que canceló. En ese caso, consulta con tu manager antes de proceder.

Escenario 2: Account Type NO es Customer Y hay una Opportunity abierta

Acción: Cambiar el Lead Status a Recycle con Recycle Reason = “Evaluating”.

No toques el lead. El equipo de ventas ya tiene al prospecto en proceso. Tu intervención solo añade ruido. El lead volverá a la cola cuando el deal se cierre o se archive.

Escenario 3: Lead en University o institución educativa, fuera de US Public Sector, y el contacto es técnico

Acción: Tratar el lead como un lead regular del segmento correspondiente.

Las instituciones educativas no siempre caen bajo Public Sector. Si el dominio es una universidad pero no es una entidad gubernamental de EE.UU., y el contacto tiene un perfil técnico (desarrollador, DevOps, arquitecto), sigue el proceso estándar sin enrutarlo a Public Sector.

Escenario 4: BDR Prospecting Status = “Actively Working”

Acción: No transferir inmediatamente. Primero verifica actividad en los últimos 30 días.

Revisar si el BDR asignado ha tenido actividad reciente (llamadas, emails, tareas completadas) sobre esa cuenta. Si hay actividad reciente, el lead va directamente al BDR. Si no hay actividad en los últimos 30 días, el status puede estar desactualizado y debes coordinar con tu manager antes de transferir.

Escenario 5: Account marcada como Public Sector

Acción: Enrutar al manager de Public Sector (PubSec).

No trabajes este lead de forma autónoma. Las cuentas de gobierno tienen procesos de compliance, contratos específicos y equipos especializados. Haz chatter al manager PubSec con el contexto del lead.

Escenario 6: BDR Prospecting Status = “Restricted” (cuenta non-Major)

Acción: Convertir el lead a Contact y hacer chatter al AE.

Las cuentas en Restricted Status tienen un Account Executive activo que tiene ownership del territorio. Convierte el lead para no perder la información y notifica al AE con el contexto del Lead Interesting Moment (LIM) y actividad reciente.

Escenario 7: La cuenta NO está en “Actively Working”

Acción: Verificar duplicados y fusionar si corresponde.

Si la cuenta no está siendo prospectada activamente, tienes ownership del lead. Pero antes de trabajarlo, asegúrate de limpiar los duplicados y consolidar la información en un único registro de calidad.

Escenario 8: La dirección de la empresa no coincide con tu investigación

Acción: Poblar los campos de Admin Company Override.

Esto es crítico para el enrutamiento geográfico. Si el lead llega con una ciudad o país incorrecto, el sistema puede asignarlo al territorio equivocado. Los campos de override te permiten corregir esto sin tocar los campos de fórmula (que son de solo lectura).

Company Address y enrutamiento geográfico

Los campos de dirección estándar en un Lead o Contact (Company City, Company Country, etc.) son campos de fórmula de solo lectura. Salesforce los calcula automáticamente según una cascada de prioridad:

flowchart LR
    A[Account Demographic Fields] --> B{¿Tiene valor?}
    B -- Sí --> F[Usar ese valor]
    B -- No --> C[Admin Company Override]
    C --> D{¿Tiene valor?}
    D -- Sí --> F
    D -- No --> E[ZoomInfo]
    E --> G{¿Tiene valor?}
    G -- Sí --> F
    G -- No --> H[Campo en blanco]

La fuente de mayor prioridad gana. Esto significa que si ZoomInfo tiene un país incorrecto pero los Account Demographic Fields tienen el correcto, el sistema usa los campos de la cuenta.

Cuándo usar Admin Company Override

Usa los campos de Admin Override cuando:

Pasos para actualizar la dirección

  1. Navegar a la vista Lead/Contact Review Admin
  2. Completar los campos: Street, City, Country, Postal Code
  3. Seleccionar el valor apropiado en Admin Company Address Source, siguiendo esta jerarquía de confiabilidad:
PrioridadFuente
1ZoomInfo
2Cognism
3Company Website / SEC Filing
4Confirmación directa del cliente
5LinkedIn (último recurso)

LinkedIn es el último recurso porque la información de ubicación en perfiles puede ser imprecisa o estar configurada por el usuario de forma arbitraria.

Fusionar Leads (Lead + Lead)

Cuando encuentras dos leads que representan a la misma persona, debes fusionarlos en un solo registro. Las reglas de GitLab definen exactamente cómo elegir qué valor conservar en cada campo:

CampoRegla de conservación
Master RecordEl lead con Last Interesting Moment Date más reciente. En caso de empate, usar el que tenga Last Activity Date más reciente
Initial SourceMantener el del lead más antiguo (Created Date más temprana). El primer touchpoint es el que cuenta
First Engagement DateMantener el valor más temprano entre los dos registros
Last Login DateMantener el más reciente
Company / AddressMantener el más exacto y completo según tu investigación
EmailSi tienen emails distintos, guardar el email secundario en el campo Supplemental Email
OwnerNo reasignar a menos que sea una decisión intencional y coordinada

Por qué el Initial Source del más antiguo

El Initial Source captura cómo GitLab conoció al prospecto por primera vez. Si fusionas y conservas el source del lead más reciente, pierdes esa información histórica de atribución. Siempre gana el dato más antiguo porque refleja el origen real del contacto.

Qué hacer con los emails diferentes

Es común que el mismo prospecto use un email personal en un webinar y su email corporativo en un trial. Nunca elimines ninguno de los dos. El campo Supplemental Email existe exactamente para este caso: el email principal queda en el campo Email, el secundario en Supplemental Email, y puedes intentar contacto por ambas vías si el principal rebota.

Fusionar Lead + Contact

Este escenario es más específico y ocurre con frecuencia en cuentas de segmento SMB o Mid-Market: alguien que ya existía como Lead en Salesforce hace una compra web direct (self-serve), lo que genera automáticamente un nuevo Contact y una nueva Opportunity. El sistema no auto-fusiona el Lead preexistente con el Contact nuevo.

Si no resuelves esto, tienes dos registros del mismo prospecto en objetos distintos, con historial de actividad dividido.

Proceso de fusión Lead → Contact:

  1. Abrir el registro del Lead
  2. Presionar el botón Convert
  3. DESMARCAR “Create Opportunity” — este paso es crítico. Si no lo desmarcas, se crea una Opportunity duplicada que genera confusión en los reportes y en la atribución
  4. Adjuntar el lead a la Account existente (la que se creó con la compra web)
  5. En el campo de Contact, seleccionar el Contact existente para fusionar ambos registros
  6. Para Initial Source: conservar el más antiguo (generalmente el Lead, que fue creado antes de la compra)

Caso especial: SMB/MM customer tras compra web

Cuando el comprador es de segmento SMB o Mid-Market y la compra convierte la cuenta a Customer:

  1. Convertir el Lead solo a Contact (sin crear Opportunity)
  2. Hacer chatter al AE incluyendo:
    • El contexto del Last Interesting Moment (LIM)
    • La actividad reciente del lead
    • El link al nuevo Contact y a la Opportunity creada por la compra

El AE necesita este contexto para entender el journey del cliente antes de hacer su primer contacto post-compra.

SFDC Chatter: guía de troubleshooting

El chatter en Salesforce es el canal oficial para escalar situaciones que no puedes resolver de forma autónoma. Esta tabla cubre los escenarios más frecuentes:

SituaciónA quién hacer Chatter
SMB/MM Contact Request donde la account es CustomerAccount Owner del registro
BDR recibe un MQL que no pertenece a una AWA (Actively Working Account)@mktops
Lead que parece mal enrutado por dirección incorrecta@mktops — primero actualizar dirección con Admin Override, luego presionar “Re-route Traction”
Cuenta duplicada detectada en el sistemaSales Support — crear un Case en SFDC con los links de ambas cuentas
Opportunity en Stage 1 con datos incorrectosTu manager directo → ellos escalan a Sales Dev Ops (Ramona, Panos o Ed)
Territorio incierto entre dos regionesAE de cada territorio potencial para acordar ownership
Solicitud de crédito SAO (Sales Accepted Opportunity)Sales Dev Ops o Director de Commercial Sales Development
Cuenta en Restricted Status (segmento non-Major)El SAE — tienes 48 horas para recibir permiso antes de proceder
Cuenta en Restricted Status (segmento Major)El AE — convertir lead a Contact inmediatamente sin esperar

Nota sobre Restricted Status en cuentas Major

La distinción entre Major y non-Major en cuentas Restricted es importante porque cambia el timing de la acción:

Limpiar leads de baja calidad

La limpieza de leads es una operación irreversible. Los registros eliminados no se pueden recuperar, razón por la cual el proceso requiere una evaluación cuidadosa antes de ejecutarlo.

Criterios de eliminación

Un lead califica para eliminación si cumple alguno de estos criterios:

Proceso de eliminación

flowchart TD
    A[Identificar lead de baja calidad] --> B{¿Cumple criterios?}
    B -- No --> C[No eliminar\nDejar en base de datos]
    B -- Sí --> D{¿Tiene valor prospectivo\no historial útil?}
    D -- Sí --> C
    D -- No --> E[Agregar lead a campaña\nSPAM DELETION en Salesforce]
    E --> F[Eliminación automática diaria\n12:05 am PDT via Marketo]
    F --> G[Lead eliminado de forma permanente]
    
    H[¿Necesitas eliminación urgente?] --> I[Solicitar en canal #mktgops]
    I --> G

Pasos del proceso

  1. Confirmar que el lead cumple los criterios y que no tiene ningún valor prospectivo (sin actividad de calidad, sin historial de oportunidades, sin match con cuentas reales)
  2. Agregar el lead a la campaña SPAM DELETION dentro de Salesforce
  3. La eliminación corre automáticamente todos los días a las 12:05 am PDT mediante un proceso de Marketo. No necesitas hacer nada más una vez que el lead está en la campaña
  4. Para eliminaciones urgentes (por ejemplo, datos sensibles o solicitudes de privacidad): solicitar en el canal de Slack #mktgops para procesamiento manual inmediato

Advertencia: Los leads eliminados NO pueden recuperarse bajo ninguna circunstancia. Verifica dos veces antes de agregar un lead a la campaña SPAM DELETION. Si tienes dudas sobre si un lead tiene valor, consulta con tu manager.

Bloqueo de dominios maliciosos

Si detectas un dominio recurrente que genera leads falsos (por ejemplo, un dominio temporal que ha enviado decenas de registros inútiles), no lo bloquees tú directamente. El proceso correcto es:

  1. Crear un Issue en el repositorio correspondiente asignado a Marketing Ops
  2. Describir el dominio y adjuntar ejemplos de los leads problemáticos
  3. Marketing Ops evaluará si el dominio debe bloquearse a nivel de Marketo para que ningún registro futuro con ese dominio entre al sistema

Resumen del capítulo

La gestión de la base de datos de leads no es un proceso burocrático: es la diferencia entre trabajar con datos confiables o perder horas en registros que no van a ningún lado. Los tres pasos — buscar duplicados, evaluar los resultados con los campos correctos, y aplicar las RoE de forma precisa — protegen tanto tu tiempo como la experiencia del prospecto.

Los puntos críticos a recordar:

En el próximo capítulo abordaremos el proceso de calificación de leads y cómo estructurar las conversaciones de descubrimiento para maximizar la tasa de conversión a SAO.

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