Este error tiene un momento exacto, y es un momento feliz. El proyecto de implementación cierra, la plataforma quedó impecable —el modelo de datos ordenado, cada etapa con su nombre, los tableros armados— y alguien de la dirección dice, con motivos para decirlo, que la empresa ya tiene Revenue Operations. Esa frase es el error. Lo vi repetirse lo suficiente como para reconocerlo antes de que ocurra.
La confusión tiene un origen razonable. Para la mayoría de las empresas, «RevOps» entró por la puerta de un proyecto de implementación: lo escucharon de un proveedor o de un vendedor de software, siempre pegado a una plataforma que había que comprar y configurar. El concepto quedó asociado al entregable de ese proyecto, y de ahí la deducción: si el entregable está listo, el asunto está resuelto. Es un razonamiento impecable a partir de una premisa falsa.
Conviene ser concreto. Una configuración entrega un lugar único donde registrar, reglas que se ejecutan siempre igual y horas devueltas al equipo: no es poco, y una plataforma bien implementada vale lo que cuesta. Lo que no entrega es lo otro: definiciones que signifiquen lo mismo en marketing, en ventas y en servicio; un solo tablero de ingresos que las tres áreas acepten como propio; reglas de traspaso con dueño y con plazo; incentivos que no premien a un área por lo que le complica el trimestre a la otra; y una cadencia fija donde eso se mire y se decida. Nada de esa lista se configura. Toda esa lista se acuerda.
Una plataforma impecable sobre áreas que no acordaron nada entrega tres versiones del trimestre, las tres bien documentadas.
El síntoma aparece rápido y es fácil de reconocer: cada área llega a la reunión con un número distinto y ninguna se equivoca. Marketing cuenta los contactos calificados que entregó; ventas, las oportunidades que aceptó como válidas; servicio, lo que se puso en marcha y se renovó. Los tres salen del mismo sistema, los tres están bien calculados y los tres miden cosas distintas, porque nadie definió cuál manda cuando se contradicen. Ahí la reunión deja de ser sobre el negocio y pasa a ser sobre los datos, que es la discusión más larga y menos productiva que hay.
Donde más se ve que el trabajo no terminó es en el traspaso. La configuración mueve el registro de un equipo a otro; no mueve la responsabilidad. Un contacto pasa a ventas sin que esté escrito en cuánto tiempo hay que atenderlo ni quién revisa lo que ventas devuelve, así que se acumula. Un contrato firmado pasa a implementación con un alcance que se prometió durante la venta y que nadie del otro lado validó; eso explota a los tres meses, cuando la comisión ya se pagó. El sistema registró los dos traspasos con fecha y hora exactas. Lo que no hizo, porque no puede, es decidir quién responde en el medio.
La reacción típica es crear un rol. Se incorpora a alguien para «hacerse cargo de RevOps» y se lo cuelga de una de las tres áreas, casi siempre de la que pagó la plataforma. Un rol sin autoridad sobre los incentivos no cambia el comportamiento de nadie. Puede armar el tablero, limpiar los datos y explicar por qué las áreas no coinciden, pero si el plan de comisiones premia cerrar rápido y el objetivo de servicio es la renovación, no tiene con qué. El problema no es el puesto: es de dónde cuelga y qué le está permitido tocar. Si no puede intervenir en cómo se mide y cómo se paga, lo único que produce es un registro cada vez más prolijo del desacuerdo.
Lo que sí funciona es más aburrido y no se compra: cuatro o cinco definiciones que las tres áreas acepten, un único tablero de ingresos, un dueño para cada traspaso y una reunión fija donde se mire eso y se decida algo. Es trabajo de dirección, no de administración de sistemas, y no tiene fecha de finalización: mientras el negocio cambie, esas definiciones se revisan.
Por eso desconfío cuando escucho «ya tenemos RevOps» tres meses después de una implementación. No es mentira: describe la parte más fácil, la única que tiene proyecto, presupuesto y fecha de cierre. La plataforma ordenada es la condición previa, no el resultado: te deja en condiciones de dar la discusión que venías postergando, con datos decentes para darla.
Una implementación termina. Un sistema de ingresos no termina: se sostiene o se desarma. Lo primero se entrega con fecha; lo segundo se revisa cada trimestre.
El día que la plataforma queda impecable no terminó el trabajo. Recién ahí se ve cuál era.