Español

Un día en la vida de un RevOps Manager: lo que la descripción de puesto no le cuenta

La descripción de puesto de su rol de RevOps Manager probablemente abre con algo como "ser dueño de la precisión del forecast, asociarse con el liderazgo de ventas, impulsar la alineación interfuncional". Real, técnicamente cierto, inútil. Nada de eso le prepara para el DM de Slack de las 7:42 a.m. de su CRO que dice: "Oye, ¿puedes revisar por qué el ACV cayó un 18% en el dashboard? Pregunto antes del standup."

Ese DM es el trabajo de verdad. Traducir un pánico en un número, un número en una causa raíz, una causa raíz en una respuesta de una sola frase que su CRO pueda repetir en el standup sin sonar como si estuviera improvisando a la desesperada, todo en los diecisiete minutos antes de que empiece el standup. La descripción de puesto no le contará nada de ese DM. Así que aquí tiene un martes que tuve hace poco, hora por hora, con los nombres cambiados y los problemas de calidad de datos reales.

Si usted es un candidato evaluando el rol, esto es a lo que se está apuntando. Si lleva seis meses y se pregunta si es normal, lo es. Si usted es un hiring manager definiendo el alcance del puesto, lea esto y revise la descripción.

7:42 a.m.: el DM de Slack antes del café

Vibra el teléfono. CRO. Pregunta sobre el ACV. Abro Looker en el teléfono, echo un vistazo a la cohorte, e inmediatamente noto que no es una caída real del ACV. Es una caída de definición. Alguien cambió hace dos días cómo se consolida el Annual Contract Value en el modelo dbt, y ahora los deals plurianuales se están promediando entre años en lugar de tomar el valor de contrato del primer año. El número no se movió; el cálculo sí.

Respondo escribiendo: "No es real. Cambio en el modelo dbt el viernes, los deals plurianuales se están promediando. Lo tendré parcheado para las 9. Usa el número de la semana pasada en el standup." Crisis desactivada en un mensaje. Hora de empezar de verdad el día.

8:00 a.m.: escaneo del pipeline

Café, segundo monitor, dos pestañas: Salesforce y Clari. No estoy mirando el pipeline. Estoy mirando qué se movió en el pipeline durante la noche.

Este es el músculo que nadie le dice que desarrolle. El pipeline en reposo no significa nada. El pipeline en movimiento (qué cambió de etapa, qué empujó su fecha de cierre, qué tuvo el importe editado) es donde vive la verdad. Ejecuto un informe guardado: Oportunidades modificadas en las últimas 24 horas, agrupadas por Cambio de Etapa. Sesenta y tres filas.

La mayoría es ruido. Tres no lo son.

La primera es un deal de 180K USD que acaba de empujar su fecha de cierre por tercera vez. Del Q3 al Q4, del Q4 al Q1, del Q1 al Q2. Ese es el patrón del tercer aplazamiento, y en mi experiencia significa que el deal está muerto y el AE aún no lo sabe, o lo sabe y no quiere asumir el golpe. Lo marco en mi cuaderno para sacarlo en la forecast call.

El segundo es un deal que retrocedió en silencio de Negotiation a Proposal. Los retrocesos de etapa casi siempre son o una señal real (cambio de champion, refresco de presupuesto) o un problema de higiene del CRM (un AE que pulsó el desplegable equivocado). Reviso el registro de actividad. El champion dejó la empresa el lunes. Retroceso real. El AE no ha actualizado la descripción del deal, así que esto habría sido invisible en la forecast call. Lo añado a mi lista.

El tercero es un deal de 40K USD donde el AE subió el importe un 20% sin actividad en la cuenta en once días. Sospechoso. Las ediciones de importe sin actividad son un indicio de sandbagging o de estiramiento. Preguntaré por ello en el 1:1 de mañana, no en la forecast call. Señalar a un AE delante del CRO es cómo se pierden AEs.

9:30 a.m.: preparación de la forecast call

La forecast call de las 10 a.m. es donde mi trabajo es más visible y más frágil. Tengo treinta minutos para reconciliar tres números que deberían coincidir pero que nunca lo hacen:

  1. Lo que dirá el CRO, basado en su lectura de los AEs en sus 1:1 de ayer.
  2. Lo que muestra Clari, basado en el commit y el best case introducidos por los reps, ponderado por el modelo de IA.
  3. Lo que muestra la consolidación AE por AE en Salesforce, basado en lo que realmente hay en el CRM ahora mismo.

Estos tres números suelen diferir entre sí en un 8-15%. El número del CRO suele ser el más alto (sesgo de recencia por los 1:1). El de Clari suele estar en medio. La consolidación de Salesforce suele ser la más baja porque la mitad de los AEs no ha actualizado sus deals desde el jueves pasado.

Mi trabajo en esos treinta minutos es identificar los tres deals por los que cuestionarán al CRO, pre-redactar las respuestas y decidir si marcar hoy el problema subyacente de calidad de datos o esperar. Hoy el problema es que un flujo de Zapier que alguien montó en 2024 está reescribiendo en silencio los valores de Stage en los leads entrantes. Hay cuarenta y dos oportunidades actualmente en Stage = Discovery que deberían estar en Stage = Qualification porque el Zap se dispara con el trigger equivocado. Encuentro esto cada par de meses. Lo registro, lo arreglo después de la llamada, y no lo menciono en la llamada. El CRO no necesita un diagnóstico de Zapier a las 10 a.m.

11:00 a.m.: la solicitud de arreglo de sistema

Forecast call terminada. Bandeja de entrada abierta. Cuatro Slacks. El que importa es de un AE: "Outreach no está registrando las tareas de vuelta en SF para la nueva secuencia. ¿Es un bug?"

No es un bug. Nunca es un bug. Es que Marketing renombró la campaña hace dos semanas, el mapeo de campaña a secuencia en Outreach se rompió en silencio, y ahora el registro de tareas está fallando para cualquier deal proveniente de esa campaña. Cuarenta minutos para diagnosticar (leer los logs de la API de Outreach, cruzar referencias con el historial de campañas de SF, encontrar el renombrado). Diez minutos para arreglarlo (actualizar el mapeo, publicar el cambio, validar que tres tareas de prueba se registren correctamente). Cero agradecimientos, porque para el AE simplemente era "Outreach roto otra vez".

Esta es la parte del trabajo que se acumula. Cada sistema que opera está a un renombrado de Marketing, un cambio de secuencia de Salesloft, una deprecación de campo de Salesforce de romperse. Los buenos RevOps Managers que conozco mantienen todos una wiki privada: qué integraciones se rompen cuando cambia qué cosa aguas arriba. La mía tiene 31 entradas. Es el documento más valioso que poseo.

1:00 p.m.: la pelea asíncrona sobre la calidad de datos

Almuerzo en mi escritorio. Hilo de Slack con tres SDRs y dos AEs sobre el Lead Source quedándose en blanco. Esta es la pelea recurrente, y he aprendido que la única forma de ganarla es hacer que el costo sea su problema, no el mío.

Publico en el canal: "Saqué los datos: el trimestre pasado, el 31% de los deals closed-won no tenían atribución de fuente. Por eso a Marketing le están recortando el crédito en el plan de comp. Si quieren que el comp pondere bien el inbound, necesitamos la fuente rellenada en cada lead. No les pido que les guste el campo. Les digo que es por qué su cálculo de spiff está mal."

Tres respuestas en cinco minutos. Dos AEs discuten. Un SDR dice "justo, lo arreglo". Esa es la victoria. No necesita que todos estén de acuerdo; necesita que el cálculo sea lo bastante visible como para que nadie pueda fingir que no existe. Las peleas de calidad de datos se ganan con impacto en el comp, no con sermones.

3:00 p.m.: tres stakeholders, un solo conjunto de datos

La media tarde es cuando las solicitudes se acumulan. Hoy:

  • El CFO quiere la retención neta de ingresos por segmento para la presentación del board. La necesita el viernes.
  • El CMO quiere la atribución por canal para un post-mortem de campaña. La quiere para mañana.
  • El CRO quiere la cobertura del pipeline por rep para un 1:1 con el COO. La quiere en dos horas.

Los mismos datos de origen. Tres cortes diferentes. Tres plazos diferentes. Puedo entregar uno hoy.

Entrego el del CRO. No porque sea el más importante, sino porque su plazo es el más corto y el corte es el más simple. La cobertura del pipeline por rep es un filtro de explore de Looker de 90 segundos. Le envío al CFO un email de espera: "Trabajando en la NRR por segmento. Tendré un borrador para ti el jueves a final del día para que tengamos el viernes para revisiones." Le escribo por Slack al CMO: "El post-mortem de atribución por canal llega el miércoles por la tarde. ¿Quieres definir los canales conmigo primero o uso por defecto tu último brief?"

El truco para no quedar enterrado es convertir cada solicitud en un artefacto entregado o en un compromiso acotado con una fecha. Las solicitudes abiertas se pudren. Las acotadas no.

5:30 p.m.: reconciliación de Commit vs. Best Case

La mayoría del equipo cierra sesión. Abro Salesforce y vuelco el movimiento de pipeline del día en una Google Sheet de una sola pestaña. Tres columnas: AE, cambio en Commit, cambio en Best Case.

Busco dos patrones. Los AEs cuyo Commit apenas se mueve pero cuyo Best Case sigue inflándose están sobre-comprometiendo: están acolchando para la llamada pero metiendo deals optimistas en Best Case para verse bien en cobertura. Los AEs cuyo Commit baja pero cuyo Best Case se mantiene plano están haciendo sandbagging, bajando el piso en silencio mientras mantienen el techo sin cambios. Ambos patrones mienten en direcciones distintas. Ambos importan para la planificación de quota del próximo mes.

Hoy hay uno de cada. Escribo un resumen de dos líneas en mis notas: "Sara: sobre-comprometiendo en Best Case, tres deals se ven estirados. Marcus: el Commit cayó 90K USD sin actividad que lo justifique, candidato a sandbag." Eso es todo. Esas dos líneas se convierten en la agenda de la forecast call de mañana.

9:00 p.m.: cena. Luego el modelo dbt.

Mi esposa pregunta qué tal mi día. Digo "normal". Ella sabe lo que eso significa. Logro pasar la cena.

A las 9:00 p.m. estoy de vuelta en mi escritorio porque el dashboard de Looker que el CRO abre a las 8 a.m. de mañana está tirando de un modelo dbt que ahora sé que está roto. El problema del ACV de la mañana era el síntoma; la causa es un renombrado de columna en el modelo opportunities_enriched aguas arriba para el que mi modelo revenue_metrics aguas abajo no se actualizó.

Abro el proyecto dbt. Encuentro la columna culpable. El nombre antiguo era acv_first_year, el nuevo es acv_year_one. Quien hizo el cambio aguas arriba no lo propagó. Arreglo el SQL aguas abajo en tres referencias en dos modelos. Ejecuto dbt test en local. Dos aserciones fallan por un problema de nulos no relacionado que no tengo tiempo de perseguir esta noche, así que arreglo de forma acotada el problema original, publico el PR, le hago ping a nuestro analytics engineer para que lo revise mañana por la mañana, y valido que el modelo se reconstruyó limpiamente en producción.

11:14 p.m. Abro Looker, refresco el dashboard. El ACV vuelve a estar en el número correcto. Cierro mi portátil. La forecast call es a las 8 a.m.

Lo que la descripción de puesto no dice

La descripción de puesto describe el título. Dice que será dueño de la precisión del forecast e impulsará la alineación interfuncional. No dice lo que esas frases significan de verdad.

Usted es un traductor. El CRO habla pipeline. El CFO habla margen. El CMO habla MQLs y CAC. Los AEs hablan comisión. Su trabajo es hacer que los cuatro números se reconcilien con la misma verdad subyacente, cada día, a tiempo para la siguiente reunión. La mayoría de los días nadie se da cuenta. El día que lo hacen, es porque algo se rompió y usted es el único que puede ver por qué.

También es un depurador de sistemas en los que nadie más piensa. Renombrados de campos de Salesforce, flujos de Zapier, deriva de columnas de dbt, mapeos de campañas de Outreach, cachés de explore de Looker: ese es su clima. Los AEs ven el clima como bugs. Usted lo ve como un martes.

Y es un político sin cartera. Media desacuerdos entre ejecutivos que están por encima de usted en el organigrama, usando datos que ellos no pidieron y en los que no confían del todo, con plazos que no son suyos.

Cómo se ve lo bueno a los 6 meses

Si es nuevo en el asiento, estos son los indicadores adelantados de que va a lograrlo:

  1. Puede nombrar las tres mayores fugas de calidad de datos de la organización. En voz alta, sin notas, en el orden de su impacto en los ingresos.
  2. Ha matado al menos un informe recurrente que nadie leía. Puntos extra si era un favorito del CRO que resultó ser vanidad.
  3. La forecast call dura 15 minutos menos que cuando empezó. Porque las preguntas se responden antes de la llamada, no durante.
  4. Al menos un AE ha dejado de escribirle por Slack por cosas que puede autoservirse. Aprendieron porque usted construyó un informe guardado y dejó de responder DMs que el informe respondería.
  5. Finanzas confía en su número de cobertura del pipeline. Confianza aquí significa que dejan de preguntar "¿esto es real?" y empiezan a preguntar "¿qué implica?".

Si está cumpliendo tres de esos cinco a los seis meses, va por buen camino. Si está cumpliendo cero, el rol no está roto; su alcance lo está. Hable con su manager sobre qué le han contratado de verdad para arreglar frente a qué ha estado apagando incendios.

El stack que tocará cada día

Las herramientas cambian cada dos años. Las categorías no. Esto es lo que típicamente lleva en el cinturón un RevOps Manager de un B2B SaaS de 5M-200M USD en ARR:

  • CRM: Salesforce o HubSpot. Sistema de registro de cuentas, contactos, oportunidades. Salesforce gana en personalización y lógica de etapas; HubSpot gana en rapidez de configuración e integración con Marketing. De cualquier forma, es donde ocurre el 60% de sus peleas de calidad de datos.
  • Capa de forecasting: Clari o BoostUp. Se sienta encima del CRM, pondera deals con señales de IA, saca a la luz el riesgo. Pasará más tiempo validando sus números que confiando en ellos. Trátelos como un motor de hipótesis, no como una fuente de verdad.
  • Sales engagement: Outreach o Salesloft. Secuencias, marcador, registro de tareas. El primer lugar que se rompe cuando Marketing renombra una campaña. Mantenga fijado el dashboard de salud de la integración.
  • Ejecución entre equipos: Rework. Para equipos de B2B SaaS que necesitan la capa de deals/tareas/proyectos que une la actividad del CRM con la entrega real (implementación, onboarding, success). Encaja bien cuando Ventas hace el traspaso a un equipo de CS o de Servicios y el trabajo necesita vivir en algún lugar fuera del CRM. Útil cuando su equipo es de tamaño medio (20-500) y necesita ops interfuncional sin coser tres herramientas entre sí.
  • Transformaciones: dbt. Es dueño de la capa de modelado entre el warehouse en bruto y el BI. Si no sabe dbt, apréndalo. Si sí sabe, ya está de guardia a las 11 de la noche.
  • BI: Looker o Tableau. Lo que los ejecutivos realmente abren. Looker para autoservicio impulsado por explore, Tableau para dashboards ejecutivos. Cualquiera de los dos está aguas abajo de dbt; si dbt está roto, el BI está roto.
  • Slack: donde ocurre la mayor parte del trabajo de verdad. Los DMs, los hilos, las peleas asíncronas. Si su higiene de Slack es mala, su día es malo.

También tocará Excel y Google Sheets más de lo que querría admitir. A veces la forma más rápida de reconciliar tres números es volcarlos en una hoja, mirar las diferencias de un vistazo y seguir adelante. No se disculpe por ello.

Cierre

Si este martes (el diagnóstico, la mediación, el SQL de las 11 de la noche, el email de espera al CFO, el argumento de impacto en el comp con los SDRs) le suena estimulante, está hecho para el rol. El trabajo no es fácil, pero es coherente. Hay una razón para cada parte del día, y las partes se acumulan.

Si suena como un castigo, la descripción de puesto le mintió. No hay vergüenza en salirse antes de la próxima forecast call. RevOps no necesita mártires; necesita traductores que puedan dormir.

Para la descripción de puesto que este artículo desenmascara, vea la Descripción de puesto de Revenue Operations Manager que la acompaña. La brecha entre la descripción de puesto y este martes es donde la mayoría de las contrataciones de RevOps fracasan en sus primeros 90 días. Lea ambas. Decida.

Saber más