Saltar al contenido
Volver a la lista de artículos
Developer Tools15分

Stack de RevOps 2026: Clari, Gong, lakehouse e IA para forecasting

RevOps Tooling Stack 2026: Clari, Gong, Lakehouse and AI Forecasting

岡田 玲奈Head of Revenue Operations
2026-04-2315分
RevOpsClariGongSalesforce EinsteinLakehouseNet Retention

RevOps se convirtió en una función de ingeniería de datos en 2026

Hasta la primera mitad de la década de 2020, Revenue Operations (RevOps) se definía a lo sumo como "las operaciones que unifican ventas y marketing en un mismo eje". Sin embargo, el RevOps de 2026 es esencialmente una organización de ingeniería de datos. Salesforce, HubSpot, Gong, Outreach, Clari, Stripe, NetSuite, Snowflake: dominar los esquemas de todos los sistemas vinculados a los ingresos, diseñar pipelines de eventos y llevar modelos de IA a producción. Este cambio impacta directamente en la precisión de las decisiones de negocio en las empresas SaaS.

En la gran encuesta realizada por Forrester en la segunda mitad de 2025, las organizaciones donde "el equipo de RevOps tiene al menos un data engineer" superaron en 18 puntos promedio a las que no lo tienen en precisión de forecast (desviación entre la predicción de cierre trimestral y el resultado real). Si el valor central de RevOps se resume en "Forecast Accuracy", esto significa que la capacidad de ingeniería se convirtió en el factor de competitividad de la predicción de ingresos.

La capa de integración entre Clari, Gong y Salesforce Einstein

En el centro del stack de RevOps de 2026 están tres plataformas: Clari (Forecast), Gong (Conversation Intelligence) y Salesforce Einstein (IA nativa del CRM). Cada una tiene sus áreas de especialización y zonas de solapamiento; cómo se integran define la estrategia ganadora de RevOps.

Clari, con tres capas —Opportunity, Account y Forecast Submission—, proporciona el roll-up de predicciones entre managers de ventas y la estimación automática por IA de Commit, Upside y Best Case. En 2026, el Clari RevAI evolucionó de la simple predicción de transición de etapas a un modelo multimodal que integra el puntaje de sentimiento de correos, invitaciones de calendario y audio de reuniones comerciales. Según datos internos de la compañía, la corrección de forecast por RevAI reduce el error promedio un 22%.

Gong analiza el audio de las reuniones grabadas y vincula a cada Opportunity el Talk Ratio, las menciones de competidores, la aparición de discusiones de precio y el volumen de participación de los tomadores de decisión. En la versión 2026, Gong Deal Flow pasó a estar en disponibilidad general (GA), y los "signals de riesgo" por oportunidad —menciones de competidores, ausencia de tomadores de decisión, manejo fallido de objeciones de precio— se escriben de vuelta al CRM de forma diaria. Al diseñar el flujo de datos de Gong a Salesforce, el equipo de RevOps puede acumular los patrones de comportamiento de los Account Executives como datos estructurados.

Salesforce Einstein aprovecha su ventaja de ser nativo de la plataforma y, además de los datos de las dos herramientas anteriores, presenta directamente en el CRM Lead Scoring, Opportunity Scoring y Next Best Action. El Einstein Revenue Cloud de 2026, a través de Einstein 1 Studio, permite hospedar modelos de IA propios de la empresa cliente e incluso hacer predicciones de ensamble combinando los modelos de Clari y Gong con modelos desarrollados internamente.

El desafío de implementación de RevOps es el problema de "los tres puntajes de predicción que no coinciden". Cuando el AI Forecast de Clari, el Deal Risk de Gong y el Opportunity Score de Einstein se contradicen, el equipo de ventas se desorienta. La mejor práctica de 2026 es agregar cada puntaje como dato crudo en el Lakehouse de Snowflake o Databricks, construir un meta-modelo (ensamble) desde RevOps para calcular un único "Deal Health Score" y escribirlo de vuelta en Salesforce como la única fuente de verdad.

Centralización en el Lakehouse: única fuente de verdad para datos contractuales

Si los datos de contratos, utilización, facturación, oportunidades y health scores de customer success están dispersos en SaaS distintos, RevOps no puede funcionar. La arquitectura estándar de 2026 centraliza todos los datos relacionados con ingresos en un Lakehouse —Snowflake o Databricks.

La configuración de pipeline recomendada es la siguiente: Salesforce y HubSpot se ingieren con Fivetran o Airbyte; Gong y Clari usan sus respectivas APIs de exportación de datos; Stripe, NetSuite y Sage Intacct se conectan con Fivetran o ETL propio; los eventos del producto (Mixpanel, Amplitude, Snowplow) pasan por un CDP compatible con Reverse ETL (Segment, RudderStack). Se normaliza con dbt y se construyen Core Models por contrato, por cuenta y por ARR.

Este diseño de Lakehouse tiene tres ventajas. Primera: funciona como Single Source of Truth y los dashboards de gestión (Tableau, Hex, Mode, Sigma) pueden consultarlo directamente. Segunda: los datos con un esquema integrado y legible por máquina quedan disponibles como datos de entrenamiento para modelos de IA. Tercera: ante auditorías, controles internos o requisitos SOX, la consistencia de los datos de ingresos se puede explicar de forma centralizada.

Los Core Models más importantes del lado de dbt son la tabla "ARR Snapshot" y la tabla "Contract Lifecycle". ARR Snapshot almacena el ARR de todos los clientes al cierre de mes, junto con las diferencias de New, Expansion, Contraction y Churn. Contract Lifecycle incluye, por contrato, la fecha de firma, fecha de inicio, fecha de renovación, flag de auto-renovación y notas de negociación, y sirve como tabla base del modelo de predicción de renovaciones. Gestionar todo esto junto con tests, documentación y linaje de dbt hace que el origen de cada cifra sea completamente rastreable.

Predicción de net retention con IA

Net Revenue Retention (NRR) es en 2026 el indicador de negocio más importante en SaaS y, al mismo tiempo, el más difícil de predecir. El motivo es que NRR es la combinación de Expansion (upsell, cross-sell, incremento de asientos), Contraction (downgrade, reducción de asientos) y Churn, cada uno con una estructura causal distinta.

El enfoque práctico de 2026 consiste en construir tres submodelos separados por contrato y hacer un ensamble al final. El primero es el Churn Probability Model: usando Gradient Boosting (XGBoost, LightGBM), estima la probabilidad de churn en los próximos seis meses, con variables como tendencia de utilización en los últimos 24 meses, frecuencia de tickets de soporte, puntaje NPS, número de pagos atrasados y señales negativas de Gong.

El segundo es el Expansion Probability Model: también con Gradient Boosting, pero sus variables son la profundidad de uso de funcionalidades, tasa de crecimiento del tamaño del equipo, acceso a funcionalidades Enterprise y señales de expansión hacia múltiples departamentos. El tercero es el Contraction Magnitude Model: estima con un modelo de regresión el impacto económico si ocurre un downgrade.

Los outputs de estos tres modelos se combinan por contrato y el NRR del trimestre siguiente se agrega a nivel de portafolio de clientes. La validación de precisión se hace rastreando el MAPE (Mean Absolute Percentage Error) en un conjunto de holdout de los últimos cuatro trimestres. Las empresas que implementaron esta configuración en serio (Snowflake, Datadog, HubSpot, Atlassian) muestran en 2026 un MAPE de entre 3 y 5%, que es el nivel suficiente para tomar decisiones de negocio.

Lo fundamental es diseñar la integración de las predicciones de IA en las operaciones de los Customer Success Managers (CSM). Para los clientes del 10% superior en Churn Probability, se envía automáticamente una alerta al CSM; para los del 10% superior en Expansion Probability, se programa una llamada conjunta con el Account Executive. Establecer la disciplina operativa de no "solo ver" las predicciones es el único camino para que el NRR se mueva realmente.

Integración con el área contable: la trinidad facturación × ERP × CPM

Donde más sufre RevOps en 2026 es en la integración con el área contable. Cómo los datos facturados en Stripe Billing, Chargebee, Zuora o m3ter se vinculan a ERPs como NetSuite, Sage Intacct, freee o Oracle Fusion; y cómo herramientas de Corporate Performance Management (CPM) como Anaplan, Pigment o Workday Adaptive Planning gestionan el presupuesto, los resultados reales y los planes futuros. Si estos elementos no están integrados de forma orgánica, el valor de NRR predicho y el resultado contable real divergen, y aparecen números que no se pueden explicar ante la junta directiva.

La configuración recomendada de 2026 es la siguiente: el sistema de facturación (por ejemplo, Stripe Billing) genera los eventos de cobro, y el reconocimiento de ingresos se automatiza conforme a ASC 606/IFRS 15. Para empresas japonesas también se requiere el tratamiento de diferencias con las normas contables locales. La integración de facturación al ERP sincroniza facturas, pagos y notas de crédito en lotes diarios. Los asientos del ERP se generan automáticamente, pero para contratos complejos (plurianuales, Ramp Deals, Usage Overage), RevOps define previamente los calendarios de reconocimiento de ingresos.

Al lado de CPM, se conecta diariamente desde el Lakehouse: ARR Snapshot, Pipeline, Forecast y resultados reales. Anaplan y Pigment han reforzado sus conectores directos a Snowflake desde 2025, y las vistas del Lakehouse pueden referenciarse directamente como inputs para los cálculos del modelo. El equipo de Finanzas hace la comparación entre presupuesto y resultados en CPM, y refleja esos resultados en reuniones de gestión y materiales de IR.

Para mantener la consistencia entre estos tres niveles (facturación, ERP, CPM), RevOps debe defender a toda costa la "unicidad de los valores monetarios". Es normal que el mismo contrato tenga un valor de ARR en facturación, un valor de Recognized Revenue en el ERP y un valor de Forecast en CPM; la condición es que esas diferencias sean definibles y rastreables. Las organizaciones de RevOps maduras en 2026 distribuyen mensualmente un reporte de esas diferencias (ARR vs. Revenue vs. Forecast Walk) a los responsables de contabilidad, FP&A y ventas.

Conclusión: RevOps es una organización de ingeniería

El equipo de RevOps de 2026 tiende a estar compuesto por 2 data engineers, 2 analytics engineers, 3 analistas de RevOps y 1 administrador de herramientas. El perfil de "admin de SFDC" que solo gestiona la configuración de Salesforce ya está quedando fuera de la corriente principal.

Diseñar, implementar y operar la integración de Clari, Gong y Salesforce Einstein; el modelo de datos contractuales sobre el Lakehouse; la predicción de NRR con IA; y la trinidad facturación × ERP × CPM requiere personas con capacidad de ingeniería y comprensión de contabilidad financiera al mismo tiempo. Para que las empresas SaaS japonesas compitan tanto local como globalmente, es necesario reposicionar RevOps no como un centro de costos, sino como una organización estratégica de ingeniería que determina la precisión de las predicciones de ingresos y la eficiencia del capital. Los números no mienten, pero si el sistema que los genera es descuidado, se vuelven indistinguibles de una mentira. Afinar ese sistema es la misión de RevOps en 2026.

Resolvamos juntos sus desafíos técnicos.

KGA IT Solutions reúne equipos especializados en IA, nube y DevOps para entregar la solución ideal a sus retos.

Contáctanos