SOP: Cómo construir un agente GTM de outbound con Hermes Agent

Un agente GTM (go-to-market) es un sistema donde un agente de IA maneja casi todo el flujo de ventas outbound: encuentra cuentas, investiga, puntúa, espera la señal de compra correcta, redacta el mensaje, te lo manda a aprobar por Telegram, ejecuta el envío y pausa todo cuando alguien responde.

El resultado: en vez de arrancar el día con otra lista de prospección, abrís Telegram y tenés una cola de cuentas investigadas, scoreadas y listas para accionar. Aprobás las que te gustan y el sistema corre el outreach, sigue cada respuesta, actualiza el CRM y se detiene en el momento exacto en que un prospecto contesta.

Tiempo de setup: 1-2 días (con stack ya existente) Costo: el de tus herramientas (Apollo, Clay, HubSpot, Smartlead/Unipile) Métrica clave: % de decisiones que aprobás sin cambios (cuenta, buyer, timing, evidencia)

• Cuenta de Hermes Agent funcionando (local o worker)
• Acceso a una fuente de datos de cuentas (Apollo, por ejemplo)
• Una herramienta de enriquecimiento (Clay o similar)
• Una fuente de señales frescas (Crustdata o similar)
• Un CRM (HubSpot recomendado)
• Telegram como interfaz de revisión
• Una herramienta de envío de email (Smartlead) y una de LinkedIn (Unipile)

Regla clave: ninguna herramienta es obligatoria. Podés reemplazar cualquiera por lo que ya usás en tu stack. Lo importante es el workflow que las conecta, con Hermes tomando decisiones entre cada paso.

` target → find → research → wait → write → approve → send → stop → learn `

El loop completo que reemplaza la cadena de handoffs manuales:

` market → research → signal → message → approval → action → CRM `

Qué desaparece: el traspaso manual entre cada etapa. Qué no desaparece: tu juicio sobre el mercado, la oferta y qué acciones merecen aprobación.

Hermes no reemplaza tus herramientas de ventas. Las conecta en un solo workflow.

Para la primera versión: dejá Smartlead y Unipile apagados. Dejá que Hermes arme la cola de investigación y revisión antes de darle permiso de contactar a nadie.

"Buscá SaaS en crecimiento que necesiten más pipeline" no sirve. Ese pedido deja que el agente decida qué significa crecimiento, qué empresas cuentan como SaaS, quién es dueño del embudo de ventas, qué países están permitidos y qué evidencia prueba una necesidad.

Definí cuatro cosas:

1. Las empresas que querés (industrias, rango de empleados, países, etapa de funding)
2. Los buyers que querés dentro de esas empresas (funciones, títulos)
3. Las cuentas que Hermes debe excluir siempre (clientes existentes, oportunidades activas, competidores, agencias, contactos suprimidos)
4. La información mínima requerida antes de que una cuenta avance

Ejemplo de configuración:

`yaml account: industries: [b2b_saas, developer_tools] employee_range: [50, 500] countries: [United States, United Kingdom, Ireland, Norway, Sweden, Denmark] funding_stages: [series_a, series_b, series_c, bootstrapped_profitable] buyer: functions: [sales, revenue_operations, growth] titles: [VP Sales, Head of Sales, Chief Revenue Officer, VP Revenue Operations] exclude: - existing_customer - active_opportunity - direct_competitor - agency - suppressed_contact required_before_outreach: - company_domain - named_buyer - current_signal - source - retrieval_date `

Regla de exclusión primero: un cliente existente o una oportunidad activa nunca deben reingresar a cold outbound solo porque el resto de la cuenta parece atractiva. Lo mismo con competidores, contactos suprimidos y mercados excluidos.

Requisito extra de email: una dirección verificada. Una cuenta puede calificar para investigación o LinkedIn sin email verificado, pero no puede entrar a una secuencia de email.

El primer trabajo real del agente: convertir un mercado grande en una lista corta de cuentas que valga la pena revisar.

Workflow:

> Apollo encuentra el mercado → Clay completa los datos faltantes → Crustdata trae evidencia fresca → Hermes investiga y puntúa → HubSpot guarda el resultado para revisión

1. Apollo hace la búsqueda amplia: usá los filtros de tamaño, industria, ubicación, tecnología, título y seniority de tu ICP
2. Separá descubrimiento de contacto: encontrar al Head of Sales correcto no significa tener su email verificado
3. Clay enriquece en tabla: puede probar providers en orden y saltar chequeos caros cuando la cuenta ya falló uno barato
4. Crustdata hace el pase de frescura: datos recientes de empresa, contratación, empleos, web y social — no un perfil viejo
5. Hermes convierte todo en un registro de revisión

Cada cuenta debe responder 5 preguntas:

1. ¿Por qué esta empresa encaja?
2. ¿Quién es el buyer probable?
3. ¿Qué cambió recientemente?
4. ¿Qué afirmaciones podemos sostener?
5. ¿Qué debería hacer Hermes después?

Si falta una respuesta, la cuenta no sale a outreach.

Scoring de 100 puntos:

Cada punto necesita una razón. Cada razón necesita fuente y fecha de recuperación.

Formato de registro de evidencia:

`yaml claim: Linear lanzó Loops para clientes Business y Enterprise. source: anuncio de producto de la empresa retrieved_at: 2026-08-09 confidence: high `

Regla de honestidad: el agente debe poder decir "no sabemos" en vez de convertir cada evento público en un dolor inventado. Si el score del problema observable queda bajo porque un lanzamiento público no prueba un problema privado de embudo de ventas, eso es exactamente lo que querés.

Encontrar la empresa correcta es la mitad. El agente también necesita saber por qué esta semana es mejor que dentro de seis meses.

Las cuentas calificadas no van directo a outreach. Entran en monitoreo y esperan a que pase algo que haga tu oferta genuinamente relevante.

Señales buenas:

• Ronda de funding
• Nuevo ejecutivo en la función de compra
• Lanzamiento de producto o segmento
• Expansión geográfica
• Contratación relevante
• Cambio tecnológico
• Prioridad pública de la empresa
• Cambio de competidor
• Nuevo requisito de compliance
• Integración relevante

Cada señal necesita 5 campos:

`yaml event: qué pasó date: cuándo pasó relevance: por qué importa para tu oferta source: de dónde salió la información expiry: cuándo la razón se vuelve vieja `

Ejemplo con Linear: la señal es el lanzamiento de Loops. Es reciente, relevante para la oferta de ejemplo y atada a clientes Business y Enterprise. Eso suma los 20 puntos de timing y mueve la cuenta de 64 a 84.

Cron de monitoreo: Hermes cron puede chequear cuentas monitoreadas en un schedule. Crustdata (o tu fuente de datos actual) provee los eventos. Si hay una señal aprobada, la cuenta avanza. Si no cambió nada, espera.

El expiry importa: un lanzamiento del mes pasado puede seguir siendo relevante. El mismo anuncio el año que viene probablemente no.

Loop de monitoreo:

` find → qualify → monitor → signal → research → review `

Cuando la cuenta pasa la investigación, Hermes prepara el mensaje.

Regla: no le des al paso de escritura todo el texto de la investigación. Dale el registro aprobado de la cuenta y hacé que cada oración se gane su lugar.

Las 4 tipos de oraciones:

1. Hecho: una fuente lo sostiene directamente
2. Inferencia: interpretación cautelosa usando palabras como "puede" o "quizás"
3. Afirmación de la oferta: algo que tu empresa puede sostener genuinamente
4. Pregunta: un CTA simple que no asume interés

Ejemplo MALO:

> Tu equipo de ventas probablemente está corriendo para convertir Loops en pipeline enterprise.

La información pública dice que Linear lanzó Loops. No dice que el equipo esté corriendo, que el pipeline sea el problema, ni que alguien quiera ayuda externa.

Ejemplo BUENO:

> Asunto: 10 cuentas para el lanzamiento de Loops > > Casey, el lanzamiento de Loops crea un ángulo de outbound muy específico: equipos enterprise que ya hablan públicamente de workflows de agentes gobernados o programados. > > Vengo construyendo un sistema que encuentra esas cuentas, mapea al buyer correcto y prepara el outreach alrededor de la señal. > > ¿Te sirve si mapeo las primeras 10 para Linear?

La primera oración es un hecho. La segunda es una inferencia. La tercera es la oferta. La última es la pregunta.

Regla de oro: si Hermes no puede clasificar una oración en uno de los 4 tipos, la elimina. Esa única regla elimina una cantidad enorme de personalización falsa.

Arrancá con Hermes enviando cada acción propuesta a Telegram.

La tarjeta de revisión debe mostrar:

• La empresa y el buyer
• El score y la señal actual
• La evidencia detrás de la investigación
• El borrador de email y el destino
• El borrador de LinkedIn y el perfil
• Controles separados para cada canal

Email y LinkedIn son dos switches separados. Aprobar email desbloquea Smartlead. Aprobar LinkedIn desbloquea Unipile. Si cualquiera de los mensajes cambia, ese canal se bloquea de nuevo hasta que aprobés la versión nueva.

Cómo sumar autonomía, una capa a la vez:

1. Dejá que la investigación corra sola cuando la selección de cuentas sea confiable
2. Dejá que el monitoreo corra solo cuando las señales viejas expiren consistentemente
3. Dejá que las acciones de bajo riesgo corran solas cuando las reglas de revisión sobrevivan suficientes ejemplos reales
4. Mantené las acciones de alto riesgo o externas detrás de permiso explícito

No automatices la capa siguiente hasta que confíes en la que está debajo.

Cuando confiás en lo que aparece en la cola de revisión, el sistema se siente como una máquina GTM real.

Aprobás el email y Smartlead lo lanza. Aprobás LinkedIn y Unipile toma el control. Cada entrega, bounce, reply y stop event vuelve a HubSpot.

Las herramientas de envío ejecutan. HubSpot controla lo que sigue.

Secuencia de estados de la cuenta:

` discovered → qualified → monitoring → signal found → researched → pending review → approved → active → replied → resolved `

Cada evento de provider necesita un resultado claro:

• Una secuencia aprobada arranca → marcá el canal como activo
• Llega un reply → pausá todos los canales activos
• Llega un unsubscribe → suprimí el contacto
• El mismo evento llega dos veces → ignorá el duplicado
• Un provider falla seguido → creá una tarea y dejá el estado actual sin cambios

Esto previene que una herramienta de envío reviva un prospecto que el CRM ya detuvo.

• Si Smartlead dice activo pero HubSpot dice replied → detené
• Si Unipile dice conectado pero HubSpot dice suppressed → detené

Antes de habilitar acciones reales:

• Daily caps
• Destination checks
• Prevención de duplicados
• Expiry de señales
• Deduplicación de webhooks
• Manejo global de unsubscribes

⚠️ Riesgo de LinkedIn: LinkedIn tiene reglas de plataforma. Usar una integración no elimina sus términos. Revisá las condiciones vigentes antes de habilitar acciones automatizadas.

La regla más importante del outbound es también la más simple:

> Cualquier reply pausa todos los canales activos ANTES de clasificar.

Primero detené. No dejés que un modelo decida si un reply es lo suficientemente importante como para frenar follow-ups mientras otra herramienta sigue enviando.

Una vez que la secuencia está pausada, Hermes clasifica la respuesta:

• Positiva
• Objeción
• Referencia
• No ahora
• No interesado
• Unsubscribe
• Respuesta automática
• Persona equivocada
• Ambiguo

Luego puede actualizar HubSpot, notificar al owner, crear una tarea y preparar una respuesta sugerida.

No debe enviar la respuesta de ventas sustantiva automáticamente. Eso queda para una persona.

El momento en que el prospecto se involucra, el agente de outbound cumplió su trabajo. La conversación ahora pertenece a un humano.

Acá el sistema empieza a componerse.

Cada semana, Hermes desglosa lo que pasó por:

• Segmento
• Señal
• Buyer
• Canal
• Ángulo de mensaje

Muestra:

• Qué cuentas se aprobaron
• Qué mensajes se reescribieron
• Qué señales produjeron conversaciones reales

También trackea los números menos glamorosos que protegen el sistema:

• Bounces
• Unsubscribes
• Contactos duplicados
• Secuencias detenidas después de replies

Cada tasa necesita su denominador. Cada recomendación necesita las cuentas y mensajes que la sostienen.

Hermes puede proponer un cambio de:

• Ventana de señal
• Peso de score
• Exclusión
• Buyer
• Ángulo de mensaje
• Experimento

Cada propuesta debe incluir:

`yaml what_happened: qué pasó records: qué registros sostienen el cambio expected_effect: qué efecto esperás risks: qué podría salir mal test: cómo lo vas a testear rollback: cuándo lo vas a revertir `

Después una persona decide si el playbook cambia.

Loop de mejora:

` results → proposal → test → approval → new rule `

Cómo poner el sistema completo en línea sin crear un desastre:

1. Instalá el skill de Hermes y mantené toda herramienta de ejecución en modo test
2. Escribí el ICP, buyers, exclusiones, registro mínimo de cuenta y afirmaciones de la oferta
3. Conectá tus fuentes de descubrimiento y enriquecimiento
4. Creá las reglas de scoring y la lista de señales aprobadas
5. Creá los campos de HubSpot para investigación, aprobación, secuencia, reply y supresión
6. Conectá Telegram u otra interfaz de revisión
7. Pedile a Hermes que produzca una cola de revisión para UN mercado chico
8. Revisá cada cuenta, score, señal y mensaje del primer batch
9. Agregá el monitoreo de señales y verificá que los eventos viejos expiren correctamente
10. Conectá email y LinkedIn en modo test
11. Dispará los escenarios de reply, bounce, unsubscribe, duplicado, señal vieja y falla de provider
12. Salí en vivo con un daily cap chico y mantené la cola de aprobación

Arrancá con 20-25 cuentas de UN segmento.

Cómo medir el sistema: no lo juzgues por cuántos mensajes produce. Juzgalo por cuán seguido coincidís con la cuenta, el buyer, el timing, la evidencia y la acción propuesta. Cuando esas decisiones sean consistentemente buenas, aumentá la autonomía O el volumen. Nunca los dos al mismo tiempo.

• [ ] ICP definido con 4 componentes (empresas, buyers, exclusiones, información mínima)
• [ ] Fuentes de datos conectadas (descubrimiento + enriquecimiento + señales)
• [ ] Reglas de scoring configuradas (100 puntos con fuente y fecha por claim)
• [ ] Lista de señales aprobadas con campo expiry
• [ ] Herramientas de envío en modo test
• [ ] Campos de HubSpot creados (research, approval, sequence, reply, suppression)
• [ ] Telegram conectado como interfaz de revisión
• [ ] Primer batch de 20-25 cuentas revisado manualmente
• [ ] Escenarios de reply/bounce/unsubscribe/duplicado/expiry testeados
• [ ] Daily cap configurado antes de salir en vivo
• [ ] Regla "reply pausa todo" verificada