El equipo GTM de 2 personas: GTM Engineer y Content Engineer

Lo que antes hacían 10 SDRs hoy lo llevan dos personas: un GTM engineer, que lleva cada cuenta de la señal al pipeline, y un Content Engineer, que la calienta antes de que llegue el primer mensaje. No funciona porque trabajen más, sino porque los dos roles se alimentan: el contenido genera señales que el outbound aprovecha, y el outbound llega a gente que ya ha visto tu nombre.

1. 01CaptarCada señal, en el mismo sitioLos dos
2. 02EnriquecerDatos en cascada, verificadosGTM Engineer
3. 03DecidirEncaje, intención y jugadaGTM Engineer
4. 04ActuarOutbound y contenidoLos dos
5. 05AprenderCada semana, de vuelta al CRMLos dos

Por qué dos personas pueden hacer el trabajo de un equipo de SDRs

Porque la mayor parte del trabajo de un SDR clásico era manual y repetible: buscar cuentas, encontrar contactos, verificar emails, copiar datos al CRM, escribir el mismo mensaje con tres palabras cambiadas. Ese trabajo hoy lo hace un sistema, y lo que queda es diseñarlo, operarlo y mejorarlo.

Un equipo de SDRs escala por volumen: más personas, más cuentas tocadas, más mensajes. Un equipo GTM de dos personas escala por criterio: menos cuentas, mejor elegidas, contactadas en el momento en que hay una razón para hacerlo. La diferencia no está en cuántos emails salen, sino en cuántos llegan a alguien que tenía motivos para responder.

El segundo cambio es el orden. En el modelo clásico el outbound abre la relación en frío y el marketing va por otro carril. En este modelo el contenido llega primero, y el outbound entra cuando la cuenta ya ha visto la marca.

Qué hace el GTM Engineer y qué hace el Content Engineer

El GTM Engineer es dueño del camino de la señal al pipeline; el Content Engineer es dueño del motor que calienta las cuentas antes de que empiece el outbound. Cada uno trabaja para el otro.

El GTM Engineer construye y opera la máquina: de dónde salen las señales, cómo se enriquecen los datos, cómo se decide a quién escribir y con qué, y cómo vuelve todo al CRM. Es un perfil técnico y comercial a la vez, más cerca de RevOps que de un SDR. Si quieres el detalle de qué construye, lo contamos en qué es RevOps y en la página de herramientas GTM.

El Content Engineer hace que, cuando llega ese primer mensaje, no sea el primer contacto. Crea las piezas, las distribuye, conversa con la audiencia cada día y, lo más importante, devuelve al GTM Engineer quién ha interactuado: cada comentario o reacción de una cuenta objetivo es una señal caliente.

Dónde encaja RevOps en un equipo GTM de dos personas

Los dos roles no trabajan sueltos: necesitan a alguien que sea dueño del CRM, de los datos y del proceso comercial. Eso es RevOps, y en un equipo con más volumen, un RevOps manager. En un equipo pequeño, el GTM Engineer y el Content Engineer cuelgan de RevOps, la dirección fija el objetivo y el ICP, y ventas (un AE o, al principio, el propio fundador) convierte en clientes las conversaciones que le llegan con contexto.

RevOps no tiene por qué ser una persona a tiempo completo. Lo que no puede faltar es alguien que decida qué se cambia con lo que el sistema aprende. Si hoy no lo hace nadie, es el hueco que cubre Fractional Revenue Operations.

Fase 1: captar señales

Todas las señales que dicen que una cuenta se está moviendo entran en un mismo sitio, para que nadie tenga que buscarlas a mano. Es la única fase que alimentan los dos roles.

Las señales vienen de cuatro fuentes:

• El propio CRM. Actividad reciente, oportunidades perdidas que vuelven a moverse, clientes que crecen.
• Intención. Cuentas que investigan tu categoría antes de levantar la mano.
• Cambios en las personas. Un decisor nuevo en una cuenta objetivo, alguien que cambia de empresa y ya te conocía.
• El contenido. Quién de tu lista de cuentas reacciona, comenta o comparte tus publicaciones. Esta es la que aporta el Content Engineer.

El tamaño y el sector dicen quién podría comprarte algún día. Una señal dice quién puede comprar ahora. Si tu ICP todavía está parcialmente identificado y no documentado, empieza por ahí: lo explicamos en cómo calcular tu ICP real.

Fase 2: enriquecer en cascada

Antes de que nadie escriba, cada cuenta y cada contacto se completan con datos verificados, tirando de varias fuentes una detrás de otra hasta rellenar lo que falta.

El enriquecimiento en cascada consiste en preguntar a un proveedor; si no tiene el dato, al siguiente; y así hasta encontrarlo o descartarlo. Así se consiguen emails verificados, datos de empresa normalizados y campos que una sola base de datos dejaría vacíos.

Es la fase que más horas de SDR se comía y la que mejor se automatiza. También es la que más daño hace si se hace mal: un email sin verificar quema el dominio, y un campo mal normalizado rompe la segmentación de todo lo que viene después.

Fase 3: decidir la siguiente jugada

Con los datos completos, cada cuenta se puntúa por encaje con el ICP y por intención, y sale de esta fase con una razón concreta para escribirle hoy y la jugada que toca.

La IA hace aquí dos trabajos: clasificar cuentas contra criterios escritos, y leer la señal para proponer el ángulo del mensaje. La automatización hace el resto: si la cuenta encaja y hay señal, entra en la secuencia correspondiente; si encaja pero no hay señal, espera; si no encaja, sale.

Esta fase es la que convierte una lista en un sistema. Una lista dice a quién escribir. Un sistema dice a quién, cuándo, por qué y con qué mensaje.

Fase 4: dos motores sobre la misma cuenta

El outbound y el contenido trabajan las mismas cuentas a la vez: el outbound lidera la conversación y el contenido la calienta.

El outbound del GTM Engineer combina email y LinkedIn, y cada toque tiene una razón que sale de la señal, no de una plantilla. Cómo se construye esa secuencia lo contamos en cadencias multicanal.

El contenido del Content Engineer no es una campaña aparte: está pensado para las mismas personas que va a contactar el outbound. Cuando el primer email llega, la cuenta ya conoce tu nombre, y eso cambia cómo se lee. Por eso responde más gente, y las conversaciones empiezan un paso más adelante.

Fase 5: aprender cada semana

Cada resultado vuelve al CRM con su fuente, y una revisión semanal ajusta el ICP, los mensajes y las señales que se vigilan.

Las respuestas, las reuniones y lo que se dice en las llamadas se convierten en datos: qué señal llevó a cada conversación, qué mensaje funcionó con qué perfil, qué cuentas no responden nunca. Sin esta fase el sistema no mejora; solo repite.

La revisión es semanal porque las señales caducan. Una cuenta que investigaba tu categoría hace un mes puede haber comprado ya.

Lo que no cambia: sin ICP ni CRM fiable, dos personas automatizan el desorden

Este modelo multiplica lo que ya tienes. Si el ICP no está escrito o el CRM no es fiable, dos personas con buenas herramientas solo llegan más rápido a las cuentas equivocadas.

Antes de montar la máquina conviene comprobar tres cosas: que el ICP está escrito con criterios que otra persona pueda aplicar, que el CRM refleja lo que de verdad pasa en el proceso comercial, y que hay alguien que decide qué se hace con lo que el sistema aprende. Si dudas de la segunda, estas son las señales de que tu CRM necesita una auditoría.

Cómo empezar si no tienes ninguno de los dos roles

La mayoría de equipos B2B no tiene ni un GTM Engineer ni un Content Engineer, y no necesita contratar a los dos el primer día. Si estás dentro de uno de esos equipos y quieres ser tú quien lo monte, lo contamos en cómo convertirte en GTM engineer. Hay tres caminos, según dónde estés:

1. Si no sabes qué está fallando, empieza por el Diagnóstico RevOps y GTM: tres semanas para confirmar qué se rompe en tu proceso comercial y en qué orden arreglarlo.
2. Si quieres que el sistema sea tuyo y lo opere tu equipo, el Sistema de outbound lo diseña y lo construye en tu stack y se lo entrega a tu equipo.
3. Si quieres que alguien lo opere por ti, el primer rol es lo que hacemos como Fractional GTM Engineer: montamos el sistema en tu propio stack y lo operamos contigo, con un objetivo mensual que revisamos juntos.

En los tres casos el orden es el mismo que en este artículo: primero las señales y los datos, después la decisión, y solo entonces los mensajes.