Charter de RevOps: Cómo Definir el Mandato, el Alcance y los Derechos de Decisión
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
Un charter de RevOps es el documento que evita que Revenue Operations se vuelva responsable de todo y con autoridad para cambiar nada.
Sin un charter, RevOps se convierte en lo que necesite el stakeholder más ruidoso esa semana: un equipo de dashboards, una cola de administración del CRM, una función de limpieza del forecast o una vía de escalamiento para la frustración interfuncional.
Un charter le da a la función un mandato.
La investigación de Forrester sobre el modelo operativo de RevOps deja claro el problema central: el éxito de RevOps depende del diseño operativo, no solo del nombre del equipo. La guía de Gartner sobre cómo reducir la complejidad del revenue enablement apunta al mismo problema desde el lado de ventas: las iniciativas desconectadas generan ruido a menos que alguien gestione el modelo compartido.
Un charter traduce ese modelo a lenguaje simple. Les dice a los líderes qué posee RevOps, qué influye, qué no posee y cómo se toman las decisiones.
Hechos operativos clave
- Un charter de RevOps define el mandato, el alcance, los derechos de decisión, la cadencia de gobernanza, la autoridad sobre los sistemas, las métricas y las vías de escalamiento.
- El charter debe proteger a RevOps de ser responsable de todo y, al mismo tiempo, no tener autoridad para cambiar nada.
- Un charter sólido separa la propiedad del desempeño funcional de la propiedad del sistema operativo compartido.
- El charter debe revisarse cuando la empresa cambia de motion de GTM, de sistemas, de liderazgo, de necesidades de reporting o de estructura de RevOps.
Qué debe incluir un charter de RevOps
| Sección | Propósito |
|---|---|
| Misión | Por qué existe RevOps |
| Alcance | Qué posee RevOps y qué no posee |
| Derechos de decisión | Qué puede cambiar o aprobar RevOps |
| Cadencia operativa | Qué reuniones y revisiones dirige o apoya RevOps |
| Gobernanza de sistemas | Cómo se cambian las herramientas, los campos y los workflows de ingresos |
| Métricas | Cómo se mide el éxito de RevOps |
| Escalamiento | Cómo se resuelven las disputas |
El charter debe ser lo suficientemente breve para que los líderes lo lean y lo suficientemente específico para zanjar discusiones.
Por qué RevOps necesita un charter
RevOps generalmente comienza porque una persona es buena para encontrar orden en sistemas desordenados. Limpia reportes, corrige campos, traduce entre marketing y ventas, y ayuda a finanzas a entender qué está pasando en el funnel.
Esa utilidad genera demanda. Pronto todos quieren algo de RevOps.
Marketing quiere limpieza de atribución. Ventas quiere cambios de territorio. CS quiere mejores campos de handoff. Finanzas quiere confianza en el forecast. Liderazgo quiere un dashboard. Sistemas quiere menos solicitudes urgentes de workflows. Cada solicitud puede ser razonable, pero la carga combinada puede convertir a RevOps en una simple cola de tickets.
Un charter evita esa deriva.
Responde cinco preguntas prácticas:
- ¿Qué vino a mejorar RevOps aquí?
- ¿Qué partes del sistema de ingresos posee?
- ¿Qué decisiones puede tomar?
- ¿Qué decisiones requieren aprobación ejecutiva?
- ¿Cómo sabrán los líderes si RevOps está funcionando?
Sin esas respuestas, RevOps obtiene responsabilidad sin autoridad. Esa es una de las razones por las que la función fracasa incluso cuando el equipo es talentoso.
Tabla de decisiones del charter
El charter debe facilitar las decisiones comunes.
| Decisión | El charter debe aclarar |
|---|---|
| Nuevo campo obligatorio en el CRM | Quién aprueba, a quién se consulta y qué evidencia se necesita |
| Cambio en la definición del forecast | Quién posee las reglas de categoría y la revisión de finanzas |
| Disputa sobre la fuente de verdad del dashboard | Qué sistema y qué responsable decide |
| Cambio en el enrutamiento de leads | Quién posee la lógica de enrutamiento, la capacidad y las reglas de excepción |
| Requisito de handoff en closed-won | Quién posee la completitud del handoff y el escalamiento |
| Prioridad del roadmap de RevOps | Cómo se pondera el impacto a nivel empresa frente a la urgencia local |
Aquí es donde el charter se vuelve práctico. No debe limitarse a describir a RevOps en términos generales. Debe ayudar a los líderes a resolver las decisiones que suelen generar fricción.
Declaración de misión
Una declaración de misión útil para RevOps suena así:
RevOps posee el sistema operativo que hace que los ingresos sean predecibles en marketing, ventas, customer success, finanzas, datos y sistemas.
Esa misión se conecta directamente con ¿Qué es Revenue Operations?. Posiciona a RevOps como propietario de un sistema, no como una cola de tareas.
Alcance
RevOps debe poseer:
- Definiciones del ciclo de vida de ingresos
- Handoffs interfuncionales
- Dashboards de ingresos compartidos
- Gobernanza del CRM y de los datos de ingresos
- Gobernanza del proceso de forecast
- Cadencia operativa de ingresos
- Control de cambios de sistemas para workflows de ingresos
RevOps no debe poseer:
- La estrategia de marketing
- El coaching de ventas y la ejecución de deals
- La gestión de relaciones de customer success
- La propiedad del plan de finanzas
- Las decisiones del roadmap de producto
El charter debe hacer esto explícito. RevOps operacionaliza la estrategia. No reemplaza al liderazgo funcional.
Límites del alcance
La parte más difícil de escribir un charter es decidir qué NO hará RevOps.
Un charter que dice que RevOps posee "el crecimiento de ingresos" es demasiado amplio. El crecimiento de ingresos es el resultado de la estrategia, la demanda de mercado, el producto, el pricing, la ejecución de ventas, customer success y la planificación financiera. RevOps puede mejorar el sistema detrás de ese resultado, pero no debe ser responsabilizado por cada resultado comercial.
Un límite más claro se ve así:
| Función | Posee | RevOps apoya con |
|---|---|---|
| Marketing | Estrategia de demanda, ejecución de campañas, decisiones de audiencia | Definiciones del ciclo de vida, gobernanza de fuentes, reporting de conversión |
| Ventas | Creación de pipeline, ejecución de deals, coaching de managers | Reglas de etapa, proceso de forecast, higiene del CRM, inspección del pipeline |
| Customer Success | Adopción, conversaciones de renovación, resultados del cliente | Proceso de handoff, modelo de datos de salud, visibilidad de renovación |
| Finanzas | Plan, presupuesto, reporting al board, controles financieros | Datos operativos, supuestos del funnel, inputs del forecast |
| Sistemas o TI | Seguridad, estándares de integración, administración de plataformas | Requisitos de workflows de ingresos y gobernanza del cambio |
Este límite protege a ambas partes. Los líderes funcionales conservan la propiedad del desempeño. RevOps obtiene autoridad sobre la capa operativa compartida.
Derechos de decisión
Los derechos de decisión son la parte más importante del charter.
Defina quién puede aprobar:
- Nuevas etapas del ciclo de vida
- Cambios de campos en el CRM
- Definiciones de métricas del dashboard
- Cambios en las reglas de enrutamiento
- Reglas de categoría del forecast
- Requisitos de handoff
- Nuevas herramientas o integraciones de ingresos
Para un diseño detallado de propiedad, vea RevOps RACI.
Plantilla de derechos de decisión
Los derechos de decisión deben escribirse como una tabla, no quedar enterrados en un párrafo.
| Decisión | Rol de RevOps | Aprobador final | Cadencia de revisión |
|---|---|---|---|
| Definiciones de etapas del ciclo de vida | Redacta, gobierna, audita | CRO o equipo de liderazgo de GTM | Trimestral |
| Nuevo campo obligatorio en el CRM | Evalúa el impacto y recomienda | RevOps más el líder afectado | Mensual o según necesidad |
| Regla de enrutamiento de leads | Diseña y monitorea | RevOps o CRO, según el impacto | Mensual |
| Definición de la categoría de forecast | Gobierna el proceso y las reglas de datos | CRO con aporte de finanzas | Trimestral |
| Métrica del dashboard ejecutivo | Posee la definición y la fuente de datos | RevOps con aprobación de finanzas | Trimestral |
| Nueva herramienta de ingresos | Revisa el workflow y el impacto en los datos | Sponsor ejecutivo más responsable de sistemas | Según necesidad |
Los nombres exactos pueden cambiar, pero el principio no. RevOps solo puede garantizar la calidad del sistema si tiene derecho de aprobación sobre los cambios que afectan esa calidad.
Cadencia operativa
Un charter también debe definir las reuniones que RevOps dirige o apoya.
Las cadencias más comunes incluyen:
- Inspección semanal del pipeline
- Revisión semanal o quincenal del forecast
- Revisión mensual del funnel
- Revisión mensual de calidad de datos
- Revisión mensual de cambios de sistemas
- Revisión trimestral de definiciones del ciclo de vida y del dashboard
- Revisión trimestral del roadmap de RevOps
El objetivo no es tener más reuniones. El objetivo es tener menos escalamientos ad hoc.
Cuando falta una cadencia, cada desacuerdo se convierte en una reunión especial. Cuando existe una cadencia, los líderes saben dónde plantear problemas, cómo se tomarán las decisiones y cuándo se revisarán los cambios.
Para conocer el ritmo operativo más amplio, vea Cadencia de Ingresos.
Gobernanza de sistemas
La mayoría de los charters de RevOps fallan porque subespecifican la gobernanza de sistemas.
Si el CRM es el núcleo operativo, entonces los cambios de campos, workflows, integraciones, datos requeridos, enrutamiento de leads, reglas de etapa y definiciones de dashboard no pueden cambiarse a la ligera. Los cambios pequeños generan efectos en cadena.
Un charter debe definir:
- Quién puede solicitar un cambio
- Qué información debe incluir la solicitud
- Cómo evalúa RevOps el impacto
- Quién aprueba los cambios de alto riesgo
- Cómo se documentan los cambios
- Cómo se notifica a los usuarios
- Cómo se verifica la adopción después del lanzamiento
Esto es especialmente importante cuando varios equipos comparten los mismos objetos. Un campo que ayuda a la segmentación de marketing podría ralentizar la carga de datos en ventas. Un workflow que ayuda al enrutamiento de ventas podría afectar el handoff a CS. Una definición de dashboard que ayuda al CRO podría entrar en conflicto con el reporting de finanzas.
RevOps no necesita bloquear el cambio. Necesita hacer visible el cambio antes de que rompa algo.
Implementación del charter
No publique el charter como un documento terminado y espere que se adopte sin más.
La implementación debe ser un proceso de alineación con el liderazgo:
- RevOps redacta el charter a partir de los puntos de dolor actuales.
- Los líderes funcionales revisan el alcance y los derechos de decisión.
- Finanzas revisa las definiciones de métricas y los puntos de contacto de planificación.
- Sistemas o TI revisa la gobernanza de la plataforma.
- El sponsor ejecutivo resuelve los conflictos.
- El charter final se comparte con los managers de ingresos.
- RevOps usa el charter en el intake, la priorización y las revisiones del roadmap.
El charter debe ser lo suficientemente breve como para usarse en decisiones reales. Si nadie lo abre después del lanzamiento, es demasiado teórico.
Ejemplo de lenguaje del charter
Use un lenguaje simple:
RevOps posee el sistema operativo de ingresos compartido en marketing, ventas, customer success, finanzas y sistemas. RevOps gobierna las definiciones del ciclo de vida, los handoffs, la calidad de datos del CRM, el reporting de la fuente de verdad, el proceso de forecast, la cadencia de ingresos y el impacto de los cambios de sistemas. Los líderes funcionales poseen el desempeño del equipo, la estrategia, el coaching y la ejecución con el cliente. RevOps tiene autoridad para aprobar o rechazar cambios que afecten los datos, workflows, dashboards y handoffs de ingresos compartidos, con escalamiento ejecutivo cuando las decisiones afectan prioridades a nivel empresa.
Ese párrafo no resuelve todas las disputas, pero le da a la empresa un punto de partida. También hace que la función sea concreta. RevOps no es "alineación". Es el propietario de una capa operativa definida.
Métricas
RevOps debe medirse por la salud del sistema, no por el volumen de tickets.
Las buenas métricas incluyen:
- Precisión del forecast
- Cumplimiento del SLA
- Completitud del handoff
- Completitud de campos obligatorios
- Visibilidad de source-to-revenue
- Confianza en el dashboard
- Reducción del reporting manual
- Reducción del envejecimiento de etapas
Use Métricas de RevOps como base de métricas.
Flujo de aprobación del charter
Un charter de RevOps debe aprobarse a través del mismo lente interfuncional que va a gobernar.
| Paso | Responsable | Resultado |
|---|---|---|
| Redactar los puntos de dolor | RevOps | Problemas operativos actuales y alcance propuesto |
| Revisar los límites funcionales | Marketing, ventas, CS, finanzas | Qué posee cada función y qué gobierna RevOps |
| Revisar la autoridad sobre sistemas | RevOps, sistemas, TI, seguridad si aplica | Reglas de campos, workflows, integraciones y permisos |
| Revisar las definiciones de métricas | RevOps y finanzas | Fuente de verdad para el reporting ejecutivo |
| Resolver conflictos | Sponsor ejecutivo | Derechos de decisión finales y vía de escalamiento |
| Publicar la versión de trabajo | RevOps | Charter, reglas de intake, proceso de roadmap, fecha de revisión |
El proceso de aprobación importa porque el charter es un documento de poder. Define quién puede aprobar o rechazar cambios que afectan la verdad compartida de ingresos. Si solo RevOps lo aprueba, otros equipos pueden tratarlo como una preferencia interna en lugar de una política operativa de la empresa.
Cómo usar el charter en solicitudes reales
El charter debe cambiar el comportamiento cotidiano.
| Solicitud | Respuesta del charter |
|---|---|
| "Agrega este campo obligatorio al CRM." | ¿Qué decisión necesita el campo, qué equipos se ven afectados y quién posee la calidad de los datos? |
| "Crea un nuevo dashboard para mi equipo." | ¿Es un reporting local o una definición de métrica compartida? |
| "Cambia el umbral de MQL." | ¿Qué pasa con el enrutamiento, la aceptación, el reporting de conversión y la capacidad de ventas? |
| "Deja que ventas se salte este campo de handoff." | ¿Qué decisión posterior de CS o finanzas depende de ese campo? |
| "Crea una nueva etapa de oportunidad." | ¿Qué evidencia define la etapa y cómo afecta al forecast? |
| "Extrae un número manualmente para el board." | ¿Debería esa métrica pasar a formar parte de la capa de reporting gobernada? |
Si el charter no puede responder estas solicitudes comunes, es demasiado vago. Ajuste los derechos de decisión antes de agregar más proceso.
Cómo mantener el charter vigente
Un charter de RevOps debe cambiar cuando la empresa cambia.
Revíselo cuando:
- La empresa agrega un nuevo motion de GTM
- Marketing, ventas o CS se reorganizan
- Cambia la línea de reporte de RevOps
- Se introduce un nuevo CRM o un sistema de ingresos importante
- Finanzas cambia el modelo de planificación
- La empresa pasa de enfocarse en nuevo negocio a enfocarse en renovación y expansión
- El liderazgo empieza a escalar repetidamente el mismo conflicto de propiedad
No reescriba el charter cada mes. Pero tampoco deje que se convierta en un artefacto de un modelo operativo antiguo. Un charter obsoleto es peor que no tener charter, porque le da a la gente una falsa sensación de claridad.
Los mejores charters son herramientas vivas: se referencian en las revisiones del roadmap, en la gobernanza de sistemas, en las decisiones de intake y en las disputas interfuncionales.
Reglas de intake
El charter debe cambiar cómo RevOps recibe el trabajo.
Sin reglas de intake, todas las solicitudes parecen igual de urgentes:
- "¿Puedes agregar este campo?"
- "¿Puedes construir este dashboard?"
- "¿Puedes arreglar el enrutamiento?"
- "¿Puedes sacar este reporte para la reunión del board?"
- "¿Puedes automatizar este seguimiento?"
RevOps necesita una forma de separar las tareas de soporte de las decisiones operativas.
Un formulario de intake simple debe preguntar:
| Pregunta | Por qué importa |
|---|---|
| ¿Qué decisión o workflow afecta esto? | Evita solicitudes de reporting de bajo valor |
| ¿Qué equipos se ven afectados? | Muestra si el cambio es local o compartido |
| ¿Qué métrica, campo, etapa o handoff cambia? | Revela el impacto posterior |
| ¿Qué pasa si no hacemos nada? | Pone a prueba la urgencia |
| ¿Quién va a usar el resultado? | Pone a prueba la adopción |
| ¿Quién aprueba el cambio? | Conecta la solicitud con los derechos de decisión |
El charter debe permitir que RevOps rechace o posponga el trabajo cuando la solicitud carece de un responsable claro, una decisión o una vía de adopción. Eso no significa que RevOps deje de ser útil. Significa que la función protege al sistema de cambios de baja calidad.
Antipatrones
Preste atención a estos errores del charter.
El charter es solo una declaración de misión. Una declaración de misión es útil, pero no define autoridad. El charter necesita alcance, decisiones, métricas y escalamiento.
RevOps posee cada problema de ingresos. Esto genera resentimiento y fracaso. Los líderes funcionales siguen siendo dueños de la estrategia y la ejecución.
Los derechos de decisión son vagos. Si el charter dice que RevOps "colabora en" todo, nadie sabe cuándo RevOps puede decir que no.
Falta la gobernanza de sistemas. Los cambios de campos, workflows y dashboards son donde la calidad operativa suele romperse.
El charter lo aprueba solo RevOps. Un charter necesita el respaldo ejecutivo. De lo contrario, es una lista de deseos.
El charter nunca se usa en las decisiones del roadmap. Si los líderes aprueban un charter pero siguen escalando cada solicitud a su alrededor, el charter no tiene poder real.
Un primer charter práctico
El primer charter de RevOps no necesita cubrir todos los casos límite.
Para una empresa en etapa de crecimiento, la primera versión puede ser un acuerdo operativo de dos páginas:
- Misión
- Sistemas y procesos que se poseen
- Responsabilidades que no se poseen
- Tabla de derechos de decisión
- Reglas de intake
- Vía de escalamiento
- Cinco métricas de salud principales
- Fecha de revisión trimestral
Con eso alcanza para empezar. El documento debe mejorar a medida que RevOps aprende dónde están los conflictos reales.
El punto no es tener una gobernanza perfecta desde el primer día. El punto es dejar de fingir que el trabajo interfuncional de ingresos puede funcionar para siempre con buena voluntad informal.
Lista de verificación de preparación del charter
Antes de dar el charter por terminado, verifique si puede responder disputas operativas reales:
- ¿Puede RevOps decir que no a una solicitud de campo que perjudica la calidad de los datos?
- ¿Pueden los líderes identificar cuál dashboard es la fuente de verdad?
- ¿Puede finanzas ver de dónde vienen las métricas de planificación?
- ¿Pueden ventas y marketing resolver disputas de definición del ciclo de vida sin un escalamiento especial?
- ¿Puede CS exigir datos de handoff sin negociarlo deal por deal?
- ¿Pueden los equipos de sistemas ver qué cambios de workflow de ingresos necesitan revisión?
Si la respuesta es no, el charter probablemente todavía es demasiado laxo. Ajuste la tabla de derechos de decisión antes de la implementación.
Preguntas frecuentes
¿Quién redacta el charter de RevOps?
RevOps debe redactarlo, pero el CRO, el CEO, finanzas y los líderes de marketing, ventas y CS deben revisarlo y aprobarlo.
¿Qué tan largo debe ser un charter de RevOps?
Generalmente entre dos y cuatro páginas. Debe ser específico, no legalista.
¿Con qué frecuencia debe actualizarse?
Revíselo trimestralmente o cada vez que la empresa cambie de motion de GTM, línea de reporte, sistemas o proceso de ingresos importante.
Más información
Senior Operations & Growth Strategist
On this page
- Qué debe incluir un charter de RevOps
- Por qué RevOps necesita un charter
- Tabla de decisiones del charter
- Declaración de misión
- Alcance
- Límites del alcance
- Derechos de decisión
- Plantilla de derechos de decisión
- Cadencia operativa
- Gobernanza de sistemas
- Implementación del charter
- Ejemplo de lenguaje del charter
- Métricas
- Flujo de aprobación del charter
- Cómo usar el charter en solicitudes reales
- Cómo mantener el charter vigente
- Reglas de intake
- Antipatrones
- Un primer charter práctico
- Lista de verificación de preparación del charter
- Preguntas frecuentes
- ¿Quién redacta el charter de RevOps?
- ¿Qué tan largo debe ser un charter de RevOps?
- ¿Con qué frecuencia debe actualizarse?
- Más información