Un segmento sin proceso. Un cupo sin equipo.
Me incorporé a la empresa como Ejecutivo de Cuentas Empresariales. Una vez que Enterprise estuvo en funcionamiento, me hice cargo del segmento de PYMES, un área en la que nunca antes se había trabajado activamente. No hubo juicio. Sin SDR asociados. Los ingresos de las PYMES provinieron de las inbound y de las referencias cuando llegaron. La decisión estratégica estaba tomada: activar SMB. La realidad operativa era clara: sin nuevas contrataciones.
Estaba en un ciclo completo en el segmento. Prospección, acercamiento, qualification, demostración, negociación, cierre: una persona, cada paso. La respuesta estándar habría sido: crear listas manualmente, enviar 50 plantillas al día, espero. Este proyecto de ley no puede durar doce meses y sin cuota. Y no resiste en absoluto la personalización a la que responde este segmento.
Por qué construí en lugar de comprar o contratar.
Había tres opciones sobre la mesa. Establecer SDR. Obtenga una licencia de una stack de herramientas como Apollo o Outreach.io. O cree el flujo de trabajo tú mismo. La primera opción no existía: no había presupuesto para la plantilla. E incluso si lo hubiera habido, ningún SDR escribe 2.000 mensajes claramente personalizados al mes con la profundidad que este segmento necesita. La segunda opción era tentadora, pero demasiado superficial: las herramientas estándar a menudo reducen la personalización a nombres y variables de la industria. Esto es exactamente lo que se ignora. Entonces construí.
Condiciones marco que obligaron al diseño
- Inclinarse. Sin impuestos innecesarios sobre herramientas. No hay proveedor que no pueda ser reemplazado en una semana.
- Específico. La personalización tenía que estar ligada a personas reales: publicaciones, empresas, recomendaciones, contexto, no a variables de plantilla.
- Propiedad. El proceso tenía que ser propiedad de la empresa. Sin agencia de caja negra, sin lógica de asiento. Flujo de trabajo en n8n, datos en hojas, creación de mensajes usando sus propios mensajes, envío a través de PhantomBuster.
- Transferible. La arquitectura tenía que sobrevivir a una sola persona. Quien asuma el cargo más tarde debería heredar un proceso continuo, no un espectáculo de personalidad.
Cuatro bloques. Un proceso. Construido ligero.
La arquitectura fue deliberadamente mínima. Cuatro bloques de construcción, cada uno con una tarea clara, conectados a través de un flujo de trabajo. El mismo formulario básico ahora está documentado paso a paso en el Manual de estrategias Outreach Agent. Este caso fue el origen.
01 · Señales de tracción (n8n)
La lógica de raspado se ejecutó en n8n. Para cada contacto objetivo, el flujo de trabajo extrajo información LinkedIn públicamente visible: perfil, función, empresa, publicaciones recientes, actividades, recomendaciones, contactos compartidos y descripciones de perfil. Si la empresa tenía un sitio web público, se agregaban la misión, las noticias y las señales visibles de la stack tecnológica. Todo terminó en una hoja de Google, una línea por lead.
02 · Preparar mensajes (Claude API)
Cada línea fue al Claude API con un mensaje. El mensaje combinó tres puntos de referencia concretos: una actividad actual, una señal común y un punto débil específico de la industria. El resultado fue un mensaje inicial que se leyó de persona a persona, no como una plantilla. Un ajuste manual antes del envío detectó cualquier cosa que no aterrizara limpiamente.
03 Envío (PhantomBuster)
PhantomBuster adoptó las acciones de LinkedIn: solicitudes de contacto con mensaje personalizado, envío de secuencias dentro de los límites de la plataforma y reconocimiento de respuestas. El mecanismo de envío era la única parte que no quería construir yo mismo. PhantomBuster lo resolvió bastante bien, así que compré esta capa en lugar de desarrollarla.
04 · La sábana como verdad
Cada lead, cada promoción, cada respuesta vivía en una hoja de Google. El estado cambiaba con cada paso: retirado, preparado, enviado, aceptado, respondido, calificado, demostración reservada. La hoja fue a la vez una señal y una prueba. Nada importante estaba sólo en la cabeza de una persona o en una herramienta que no era exportable.
Un proceso que comenzó. Y un pipeline que seguía funcionando.
Los primeros leads calificados llegaron dentro de la primera semana después de la puesta en marcha. Después de cuatro a seis semanas, el proceso estaba funcionando a un ritmo en el que podía trabajar sin interrumpir las demostraciones y las terminaciones. Las cifras sobre la colaboración: 2198 solicitudes de contacto personalizadas enviadas, 903 aceptadas, tasa de respuesta del 40% en la cohorte conectada, alrededor de 55 horas de tiempo ahorradas por ola de outreach en comparación con el trabajo manual.
Un sistema observado desde una perspectiva de liderazgo.
El trabajo no ocurrió en el vacío. El RVP de Ventas que me contrató y fue mi gerente directo durante ese tiempo describió más tarde la estructura del segmento con sus propias palabras. Los nombres se anonimizan a petición de la empresa:
Este caso es el prototipo del Outreach Agent. Antes tenía nombre.
Todo lo documentado hoy en el Outreach Agent Playbook (la forma de cuatro ladrillos, la lógica de personalización, la stack ajustada, la idea de “personas, no títulos”) se puso en práctica por primera vez aquí. No concebido en el taller. No diseñado teóricamente. Construido porque de lo contrario el proyecto de ley no habría funcionado.
Este es el núcleo de la lógica MSA: primero comstackr como operador, luego documentar, nunca al revés. La arquitectura debe sobrevivir al contacto con un segmento real, una cuota real y una responsabilidad real antes de poder venderse como un sistema.
