Errores comunes de RevOps: 7 muros con los que chocará entre los 6 y 18 meses (y cómo atravesarlos)

Ya pasó la luna de miel del nuevo fichaje. El CRO sabe su nombre. Su cola está llena. Pero algo no encaja. Ventas está molesto por algo que no logra nombrar. Sus dashboards no se están abriendo. El VP sigue haciendo la misma pregunta de forecast en tres QBRs seguidos, y usted sigue dando una respuesta en la que no acaban de confiar.

Bienvenido al muro. Toda persona de RevOps choca con él en algún punto entre el mes 6 y el mes 18. El trabajo que le contrató (limpiar desórdenes obvios, lanzar las primeras victorias rápidas) no le lleva a Senior. La siguiente marcha es distinta, y nadie le entrega el playbook.

Así que aquí está. Siete muros, en el orden en que suelen aparecer, con el síntoma, el número real que prueba que está pasando, y qué hacer esta semana.

Error 1: construir informes de Salesforce que nadie lee

Síntoma. Lanza un dashboard. El VP le da un emoji de pulgar arriba en Slack. Se siente bien durante unas 48 horas. Luego revisa el recuento de vistas y está planchado en 3: usted, su manager y el trabajo de auto-refresco.

El número real. Ejecute un informe de Lightning Usage (o el equivalente de su CRM) y saque los recuentos de vistas de cada dashboard que ha construido en los últimos 90 días. El corte honesto: menos de 5 espectadores únicos al mes después de la semana 2 significa que está muerto. La mayoría de los dashboards construidos por ops aterrizan ahí. He auditado organizaciones con más de 80 dashboards donde los 5 principales representaban el 92% de todas las vistas.

Qué decir de verdad. La próxima vez que alguien diga "¿puedes construirme un dashboard para X?", pregunte: "Explícame la reunión en la que lo abrirías. ¿Quién más está en la sala? ¿Qué decisión cambia según lo que diga?". Si no pueden responder en 30 segundos, el dashboard aún no existe porque la decisión aún no existe.

El arreglo. Deje de construir hasta que alguien lo pida dos veces. El primer pedido es un "feeling". El segundo pedido, dos semanas después, es una necesidad real. Reemplace 3 informes no leídos por 1 resumen semanal en Slack atado a una decisión específica: "La cobertura del pipeline es 2,8x entrando en el Q3, la necesitamos en 3,5x, aquí están los 4 segmentos donde estamos cortos". Eso se lee. Eso se reenvía. Eso le mete en la diapositiva del QBR.

Error 2: sobre-personalizar el CRM (la deuda técnica se acumula rápido)

Síntoma. Abra el objeto Opportunity en su configuración de Salesforce o HubSpot. Cuente los campos personalizados. Si su reacción visceral es "uf", ya lo sabe. Hay 47 campos personalizados, 12 record types y una validation rule de 2024 que nadie recuerda haber escrito ni pedido.

El número real. Dos cortes. Si tiene más de 30 campos personalizados por objeto, está en deuda. Si más del 15% de esos campos tienen menos del 5% de uso a través de los registros, está pagando los intereses de la deuda en lugar de amortizar el capital. Saque un informe de utilización de campos (Salesforce Optimizer lo hace gratis; HubSpot tiene Field Insights). El número le dice todo.

Por qué importa. Cada campo muerto es un impuesto sobre cada informe, cada page layout, cada onboarding de un nuevo rep y cada integración que tiene que mapear el esquema. Un CRM inflado no solo se siente lento: es la razón por la que su modelo de forecast no puede confiar en los datos que entran.

El arreglo. Ritual trimestral de limpieza de campos. Saque el informe de utilización. Cualquier cosa por debajo del 10% de uso por registro que no se haya editado en 90 días va a la lista de eliminación. Anúncielo en #revops-changes durante dos semanas. Desactive, no elimine, y documente la deprecación en un CHANGELOG continuo que mantenga en una página compartida de Confluence. Después de tres trimestres de esto, la organización se vuelve más limpia en lugar de más sucia, lo que por sí solo le pone por delante del 80% de la gente de RevOps.

Error 3: saltarse la ceremonia de despedida de las automatizaciones muertas

Síntoma. Process Builders, Flows, recetas de Workato y Zaps de 2023 siguen disparándose en cada registro. Abrió uno ayer y el campo de descripción decía "TODO: escribir descripción". Nadie sabe qué hace la mitad de ellos. Nadie quiere apagarlos porque nadie quiere ser el que rompa algo.

El número real. Cuente los flujos activos en su organización. Luego cuente los flujos que se han tocado (editado, depurado o incluso abierto) en los últimos 90 días. La brecha suele ser del 40-60%. Esa es su superficie de automatizaciones muertas, y cada una es un futuro incidente Sev 1 esperando el caso límite adecuado.

Por qué es difícil. Matar automatizaciones se siente más arriesgado que construirlas. Construir = victoria visible. Matar = victoria invisible a menos que algo se rompa, en cuyo caso es una pérdida visible. Así que la organización acumula flujos como un disco duro acumula archivos.

El arreglo. Revisión mensual de la lista de eliminación, en el calendario, tratada como una reunión real. Tres reglas:

Sin propietario activo (la persona ya no está en la empresa, sin reemplazo asignado) → candidato a eliminación.
Sin ediciones en 12 meses Y sin documentación → candidato a eliminación.
Los logs muestran menos de 1 ejecución al mes → candidato a eliminación.

Desactive primero, no elimine. Espere 30 días. Si nadie grita, elimine y escriba el funeral en su CHANGELOG: qué hacía, por qué murió, qué lo reemplazó (si algo lo hizo). El funeral es el punto. Le enseña a la organización que matar cosas es normal, que es cómo detiene el inflado de raíz.

Error 4: perseguir la precisión del forecast sin arreglar la higiene del pipeline

Síntoma. El CRO quiere ±5% de precisión del forecast. Usted está construyendo modelos de pipeline ponderado, incorporando sentiment de las llamadas de los reps, quizá incluso pilotando una herramienta de forecast con IA. Mientras tanto, el 38% de las opps abiertas en el sistema tienen una fecha de cierre en el pasado. Está resolviendo el problema equivocado.

El número real. Saque el porcentaje de pipeline abierto donde la fecha de cierre está más de 14 días en el pasado respecto a hoy. Las organizaciones sanas están por debajo del 10%. Las organizaciones no sanas están en el 30-45%. Un modelo de forecast alimentado por fechas inactivas es una calculadora con entradas aleatorias, y ninguna sofisticación de modelo lo salvará.

La conversación honesta con el CRO. "No podemos llegar a ±5% de precisión sobre un pipeline donde el 38% de las opps están inactivas. La matemática literalmente no funcionará. Dame 6 semanas de higiene, luego 6 semanas en el modelo. Si nos saltamos el paso de higiene, simplemente nos equivocaremos con más confianza."

El arreglo. Higiene primero, modelo segundo. Lance un informe semanal de datos inactivos atado a los scorecards de los reps: número de opps inactivas, valor en USD de las opps inactivas, días desde la última actividad. Hágalo visible en el canal del liderazgo de ventas. Átelo a la responsabilidad de la forecast call: si un rep mete una opp en commit y la fecha de cierre lleva 3 semanas en el pasado, esa opp no puede estar en commit. Una vez que la tasa de inactividad baje del 12%, entonces hable de modelos. Una cobertura del pipeline en la que confía le gana a una metodología de forecast en la que no.

Error 5: convertirse en el "recibe-tickets" en lugar del estratega

Síntoma. Abre Jira el lunes. Cuarenta y tres tickets. "Añadir valor al picklist." "Nuevo informe para la región 4." "Corregir error tipográfico en la definición de etapa." Ahora es viernes. Ha lanzado 41 de ellos. No ha movido un proyecto real hacia adelante en seis semanas. Está agotado y de algún modo también avergonzado.

El número real. Rastree su tiempo durante dos semanas (Toggl, Clockify, hasta una hoja de cálculo sirve). Si menos del 20% va a trabajo de proyecto y más del 80% va a tickets, ha sido absorbido. Ya no es RevOps, es helpdesk del CRM. El impacto en la carrera es brutal: los roles Senior de RevOps los ocupan personas que lanzaron proyectos, no personas que cerraron tickets.

Por qué pasa. Los tickets se sienten productivos. Cada uno se cierra con un tilde verde. También son infinitos, porque cada equipo trata a RevOps como su admin personal en cuanto una persona dice que sí a una cosa.

El arreglo. Modelo de horario de atención. Bloquee su calendario. Los tickets se triajan dos veces por semana, en dos ventanas de 2 horas (digamos martes de 1 a 3 p.m. y jueves de 1 a 3 p.m.). Fuera de esas ventanas, la cola está cerrada a menos que algo esté de verdad en llamas (producción caída, con impacto en comp, bloqueando un deal). Proteja 2 días completos para trabajo de proyecto. Dígale a su manager exactamente esto: "Si quiero lanzar el modelo de territorios y la reconstrucción del forecast este trimestre, necesito 2 días protegidos a la semana. Aquí está lo que no se lanzará si no los consigo."

La primera semana se siente incómoda. La cuarta semana, la organización se adapta. La octava semana, los solicitantes empiezan a resolver el 30% de sus propios tickets porque la fricción les hizo pensar primero. Ese es todo el punto.

Error 6: re-cortar territorios demasiado rápido

Síntoma. Re-cortó los territorios en el Q2 porque "los datos lo decían". Los reps se rebelan. Tres top performers amenazan con irse. El CRO revierte el cambio en el Q3. Ahora ha pasado seis meses ejecutando un cambio que produjo pipeline negativo y quemó capital político que no puede recuperar fácilmente.

El número real. Los benchmarks internos de organizaciones de ventas de mid-market lo sitúan en una destrucción del 15-25% de la cobertura del pipeline durante una transición de territorios, recuperada en 6-9 meses si el corte fue bueno y en más de 12 meses si fue malo. Ese costo es invisible en una hoja de cálculo pero catastrófico en una presentación al board.

Por qué pasa. La gente de RevOps ve el desequilibrio en los datos (el Rep A tiene 2,3x las cuentas asignadas del Rep B), y el cerebro de la optimización dice "arréglalo". El cerebro de la optimización olvida que los territorios son también relaciones, conversaciones en curso, deals medio cerrados y el modelo mental de un rep sobre con quién está trabajando. No solo está moviendo cuentas en una hoja de cálculo, está cortando a través de diez meses de contexto.

El arreglo. Tres reglas.

Mínimo de doce meses entre re-cortes significativos. Si necesita re-cortar más a menudo, la lógica de segmentación subyacente está mal, no los territorios.
Pilote antes del despliegue global. Pruebe la nueva lógica en un segmento (una geografía, un vertical de industria) durante un trimestre completo. Mida la cobertura del pipeline, la velocidad de los deals y la satisfacción de los reps antes de propagarla.
Reps en la sala. Recorra el corte propuesto con los 3 mejores reps de cada segmento antes de bloquearlo. Captarán los problemas de "la Cuenta X está en negociación activa, no la muevas" que una hoja de cálculo no verá.

Un plan de territorios más lento que se sostiene durante 18 meses le gana a uno rápido que se revierte en 6.

Error 7: no asociarse con finanzas en la atribución

Síntoma. Marketing afirma que originó el 60% del pipeline. Finanzas cierra los libros y reporta el 22%. El CRO está en una reunión del board intentando explicar ambos números. Usted es la persona que tiene que entrar a limpiar. Tanto Marketing como Finanzas tienen técnicamente "razón" porque están usando definiciones distintas, rangos de fechas distintos y ventanas de atribución distintas.

El número real. Si el número de pipeline originado de su CRM no se reconcilia con los bookings de Finanzas dentro de un 10%, tiene un problema de credibilidad y aún no lo sabe. El board sí lo sabe, sin embargo, y aparece como "no confiamos en el número de marketing" en conversaciones en las que usted no está.

Por qué esto importa más de lo que parece. Los desacuerdos de atribución son un sustituto de la confianza entre Marketing y Finanzas, y RevOps se sienta exactamente en el medio. La persona de RevOps que arregla esto se convierte en el operador de mayor confianza de la empresa en un trimestre, porque cada ejecutivo del edificio lleva años calladamente molesto por ello.

El arreglo. Sincronización mensual de atribución con FP&A. Una hora, en el calendario, despiadada. La agenda es siempre la misma:

Reconcilie el número de pipeline originado del mes pasado con los bookings. Muestre la matemática.
Bloquee las definiciones para el mes que viene: qué cuenta como marketing-sourced, qué cuenta como influenciado, qué rango de fechas, qué ventana de atribución.
Firmen juntos la diapositiva del QBR. Mismo número, mismas definiciones, ambos lados de acuerdo antes de que cualquiera de los dos lados vea al CRO.

En dos ciclos, la brecha se reduce del 38% al 8%. En tres ciclos, Finanzas empieza a ponerle en copia en la preparación del board. Ese es el momento en que deja de ser un RevOps Manager y empieza a ser un operador con vía a Director.

Qué le están diciendo de verdad estos muros

Chocar con estos muros no significa que sea malo en el trabajo. Significa que lleva el tiempo suficiente como para ver la forma del rol.

Los primeros seis meses recompensan a las personas que pueden lanzar: limpiar el desorden obvio, construir los dashboards obvios, cerrar los tickets obvios. Los siguientes doce meses recompensan a las personas que pueden elegir: elegir qué no construir, qué matar, qué conversaciones liderar, qué número defender en una sala con el CRO y el CFO.

Los que atraviesan el muro dejan de optimizar para la actividad y empiezan a optimizar para las dos preguntas que un CRO de verdad hace: "¿Cuál va a ser el número?" y "¿Qué cambió?". Cada dashboard, cada flujo, cada corte de territorios, cada discusión de atribución o le ayuda a responder esas dos preguntas o no. Si no, es ruido, y la cola está llena de ruido.

Elija el muro al que esté más cerca ahora mismo. Ejecute el diagnóstico esta semana. Lance el arreglo la próxima semana. Luego vuelva y lea el siguiente.

Playbooks de RevOps