Revenue Operations (RevOps) es la función que es dueña de los sistemas, los datos y el proceso detrás de cada equipo que genera revenue. En una empresa B2B eso significa la capa operacional debajo de sales, marketing y customer success. RevOps es dueño del CRM, los datos que fluyen por él, la lógica de automatización que lo conecta con herramientas adyacentes, y las métricas que la organización GTM usa para tomar decisiones.
Qué hace realmente un equipo de RevOps
El día a día se divide en cuatro bloques:
- Sistemas. Elegir, configurar y mantener el stack de herramientas GTM: CRM (HubSpot, Salesforce), sequencer (Outreach, Salesloft, Apollo), enriquecimiento de datos (Clay, ZoomInfo), conversation intelligence (Gong), automatización (n8n, Zapier), orquestación de IA (Claude + MCP).
- Datos. Asegurarse de que los datos correctos fluyan entre sistemas, que los registros estén limpios, que los campos signifiquen lo que los reps creen que significan, y que el reporting refleje la realidad.
- Proceso. Diseñar cómo se rutean los leads, cómo progresan los deals, cómo se trackean las renovaciones, cómo ocurren los handoffs entre equipos, y cómo se manejan las excepciones.
- Insight. Construir reportes y forecasts que el CRO confíe. Velocidad de pipeline, conversion rates por segmento, forecast vs actual, drivers de churn.
RevOps vs Sales Ops
Sales Ops es la función predecesora — la misma idea pero acotada solo al equipo de sales. RevOps emergió en 2018-2020 cuando las empresas B2B SaaS se dieron cuenta de que sales, marketing y customer success operaban todos contra el mismo buyer journey pero en sistemas desconectados. Tratar esos equipos como dominios de ops separados creaba drift de datos, guerras de atribución y desacuerdos de forecast que el CRO no podía resolver.
La consolidación de RevOps pone a un solo equipo a cargo del ciclo de revenue completo — lead → opportunity → customer → renewal/expansion — con un único modelo de datos y un conjunto unificado de métricas.
¿Cuándo necesita una empresa RevOps?
El trigger normalmente no es el tamaño; es la complejidad. Una B2B SaaS de 30 personas con un solo motion (inbound demo, cierre por AE) todavía no necesita RevOps. Una B2B SaaS de 30 personas con tres motions (inbound + outbound + product-led) y tres personas absolutamente sí, porque el modelo de datos y el tooling tienen que manejar las variaciones.
Para los $10M ARR la mayoría de las empresas B2B SaaS tienen una función dedicada de RevOps. Para los $25M ARR típicamente es un equipo de 2-5 con un Head of RevOps o VP RevOps reportando al CRO.
Qué cambió con la IA
Antes de 2024, RevOps era en gran parte plomería — cómo se mueven los datos, cómo se conectan los sistemas, cómo los dashboards reflejan la realidad. Después de 2024, las herramientas AI-native (las columnas de IA de Clay, conversation intelligence de Gong, Claude + MCP para workflows agénticos) cambiaron la pregunta. Ahora el leverage no es “cómo movemos los datos”, es “qué workflow de IA podemos correr sobre los datos que tenemos”.
Un equipo de RevOps moderno escribe Claude Skills, construye agentes en n8n que triagean el inbound, despliega Cursor rules para los tipos data-engineer, y trata el stack de herramientas de IA como un dominio de primera clase — no como un experimento lateral.
Funciones adyacentes
- Marketing Ops — la misma idea, acotada a las herramientas de marketing (HubSpot Marketing Hub, Marketo, Pardot, Customer.io)
- Sales Ops — solo sales, la predecesora de RevOps
- CS Ops / Customer Success Ops — solo customer success, enfocada en Gainsight, Catalyst, Vitally
- GTM Engineering — título emergente para el lado técnico de RevOps (escribe código, construye agentes, es dueño de la infraestructura)
En una empresa chica todos estos son la misma persona. En una empresa grande son funciones distintas reportando a través del mismo líder de operaciones.