Etapas del funnel de ingresos: un mapa completo del ciclo de vida, del lead a la expansión

Las etapas del funnel de ingresos definen cómo se mueve una persona, una cuenta, una oportunidad y un cliente a través del sistema de ingresos.

Un pipeline de ventas es solo una parte de ese mapa. RevOps necesita el ciclo de vida completo: captura del lead, calificación, aceptación por ventas, creación de la oportunidad, closed-won, onboarding, renovación y expansión.

El modelo de responsabilidades de revenue operations de Forrester resulta útil aquí porque enmarca a RevOps en todo el motor comercial, no solo en el reporting de ventas. La investigación de McKinsey sobre crecimiento B2B también refuerza la necesidad de sistemas comerciales conectados a medida que el comportamiento del comprador y los motions de crecimiento se vuelven más complejos.

El mapa de etapas del funnel es el lenguaje operativo de ese sistema.

Datos operativos clave

• Las etapas del funnel de ingresos deberían cubrir todo el ciclo de vida: demanda, calificación, oportunidad, onboarding del cliente, renovación y expansión.
• Agregue una etapa solo cuando cambia la propiedad, la acción requerida, el reporting, el estado del cliente o la decisión de gestión.
• Cada etapa necesita criterios de entrada, criterios de salida, owner, antigüedad esperada, datos obligatorios y una vía de excepción.
• El nombre de la etapa importa menos que la evidencia. Una etapa es útil solo si los managers pueden inspeccionar si un registro pertenece ahí.

Un mapa de etapas práctico

Cada etapa necesita criterios de entrada, criterios de salida, owner, campos obligatorios y SLA. Sin eso, la etapa es solo una etiqueta.

Por qué importan las etapas del ciclo de vida

Las etapas del ciclo de vida no son solo estados del CRM. Definen quién es dueño del registro, qué acción debería seguir y en qué métricas pueden confiar los líderes.

Cuando las etapas del ciclo de vida son débiles:

• Marketing y ventas discuten sobre la calidad del lead.
• Los SDR no están seguros de qué registros trabajar.
• Ventas crea oportunidades demasiado pronto.
• Los reportes de forecast incluyen deals con evidencia débil.
• CS recibe clientes sin contexto sobre el resultado.
• Finanzas no puede conectar los supuestos del funnel con la planificación de ingresos.

Cuando las etapas del ciclo de vida son claras, cada equipo sabe qué significa un registro y qué debería suceder a continuación.

Principios de diseño de etapas

Use estos principios al diseñar el mapa:

El objetivo no es modelar cada matiz. El objetivo es crear etapas que sustenten decisiones.

Cuándo agregar o eliminar una etapa

No agregue etapas porque los equipos quieran más detalle de reporting. Agregue una etapa cuando el negocio necesite una acción operativa distinta.

Buenas razones para agregar una etapa:

• La propiedad cambia entre equipos.
• Cambia el SLA o la expectativa de respuesta.
• Cambian los datos obligatorios.
• Cambia el tratamiento de forecast o planificación.
• Cambia el estado del cliente.
• La inspección del manager necesita un punto de control distinto.

Razones débiles:

• Un equipo quiere ver más etiquetas de actividad.
• Una plantilla de CRM incluye la etapa.
• Un líder quiere un corte de dashboard pero ningún cambio de workflow.
• Los reps usan lenguaje informal que no afecta la propiedad.

Las etapas también deberían eliminarse. Si una etapa ya no cambia la acción, genera confusión o tiene datos de mala calidad, fusiónela en un modelo más simple. Un ciclo de vida más simple que los managers hacen cumplir es mejor que un ciclo de vida detallado en el que nadie confía.

Modelo de propiedad por etapa

Cada etapa debería tener un owner operativo principal, incluso cuando varios equipos contribuyen.

Este modelo de propiedad evita que las etapas del ciclo de vida se conviertan en etiquetas sin comportamiento. Si nadie es dueño del movimiento, los registros estancados siguen estancados. Si nadie es dueño de los criterios, los cambios de etapa se vuelven subjetivos. Si nadie es dueño del impacto en el reporting, los dashboards se desvían.

RevOps debería publicar el modelo de propiedad junto con el mapa de etapas. Los managers deberían saber qué equipo actúa, qué campos importan y qué vía de excepción aplica cuando un registro no encaja con el flujo estándar.

Etapas de lead y demanda

Las etapas de lead deberían separar la demanda bruta de la demanda calificada.

Etapas comunes:

La regla más importante es que MQL no debería significar "a marketing le gusta este lead". Debería significar que el registro cumple un umbral acordado para la revisión de ventas.

Para un diseño de traspaso más detallado, vea Lead to Opportunity Process.

Etapas del pipeline de ventas

Las etapas de oportunidad deberían describir el avance de la compra, no la actividad del vendedor.

Las etapas débiles suenan así:

• Contactado
• Seguimiento
• Demo realizada
• Propuesta enviada

Esas pueden ser actividades útiles, pero no siempre prueban la calidad del deal.

Las etapas más sólidas usan evidencia:

Cada empresa nombrará las etapas de forma distinta. Lo que importa es que el movimiento requiera evidencia.

Etapas del ciclo de vida del cliente

Las empresas de ingresos recurrentes necesitan etapas posteriores al closed-won.

Etapas de cliente comunes:

Esto conecta las etapas de ingresos con RevOps and Customer Success. Sin estas etapas, la empresa puede celebrar nuevos bookings mientras pasa por alto el riesgo dentro de la base de clientes.

Etapas de cuenta vs persona vs oportunidad

Muchos equipos confunden las etapas por objeto.

Una persona puede ser un lead. Una cuenta puede ser target, prospecto activo, cliente o perdida (churned). Una oportunidad puede estar calificada, en etapa tardía, closed-won o closed-lost. Un cliente puede estar en onboarding, activo, en riesgo de renovación o ser candidato a expansión.

RevOps debería definir qué objeto es dueño de cada etapa:

Esto importa porque el reporting se rompe cuando los equipos mezclan objetos. Un reporte de conversión de leads no debería usarse como reporte de progresión de cuentas. Un forecast de oportunidades no debería reemplazar la salud de la renovación.

Campos obligatorios por etapa

Cada etapa debería tener una pequeña cantidad de campos obligatorios.

Ejemplos:

Mantenga los campos obligatorios acotados. Demasiados campos obligatorios generan datos malos. Use Required Fields vs Useful Fields para la gobernanza de campos.

Cadencia de revisión de etapas

Revise las etapas trimestralmente o cuando cambie el motion de GTM.

Disparadores para revisar:

• Nuevo segmento o línea de producto
• Cambio de un motion liderado por ventas a uno liderado por producto
• Nuevo motion de renovación o expansión
• Cambio importante de CRM o automatización de marketing
• Disputas repetidas sobre las definiciones
• Desajuste entre el forecast y el reporting al consejo

El mapa de etapas debería ser lo bastante estable para el reporting y lo bastante flexible para ajustarse al negocio.

Checklist de preparación

Antes de publicar el mapa del ciclo de vida, confirme:

• Cada etapa tiene un owner principal.
• Cada etapa tiene criterios de entrada y salida.
• Cada etapa tiene campos obligatorios vinculados a decisiones.
• El movimiento de etapa puede auditarse.
• Las etapas post-venta están incluidas.
• Finanzas entiende qué etapas afectan la planificación.
• Los dashboards usan las mismas definiciones.
• Los managers saben cómo manejar las excepciones.

Si la respuesta es no, el mapa de etapas no está listo para la gobernanza.

Cómo implementar nuevas etapas

Cambiar las etapas del ciclo de vida es riesgoso porque afecta reportes, workflows, automatizaciones, dashboards y hábitos.

Una implementación práctica debería incluir:

1. Mapear las etapas actuales e identificar para qué se usa cada una.
2. Definir el nuevo modelo de etapas y el motivo de cada cambio.
3. Mapear las etapas antiguas a las nuevas.
4. Revisar los dashboards, workflows e integraciones que dependen de los valores de etapa.
5. Revisar el impacto con marketing, ventas, CS, finanzas y sistemas.
6. Capacitar a los managers en los criterios de entrada y salida.
7. Migrar los registros con cuidado y documentar los supuestos.
8. Monitorear el movimiento de etapa durante el primer mes.

No cambie el nombre de las etapas de forma casual. Un pequeño cambio de etiqueta puede romper el historial de reporting o confundir a los equipos.

Antigüedad por etapa

Cada etapa debería tener un rango de antigüedad esperado.

La antigüedad por etapa ayuda a los managers a ver dónde están atascados los registros:

El umbral correcto depende del motion. Un lead inbound de alta velocidad puede envejecer en horas. Una oportunidad enterprise puede envejecer en semanas. Lo importante es definir el umbral en lugar de tratar los registros estancados como algo normal.

Etapas de closed-lost y descalificado

Un mapa de ciclo de vida completo incluye los resultados negativos.

Las etapas de descalificado, rechazado, closed-lost, churned y contracción no son fracasos para esconder. Son puntos de aprendizaje.

RevOps debería estandarizar los códigos de motivo:

• Mal fit
• Sin presupuesto
• Sin autoridad
• Sin dolor claro
• Timing
• Competidor
• Falta de funcionalidad
• Duplicado
• Inalcanzable
• Riesgo de implementación

Estos motivos deberían alimentar decisiones futuras. Si el mal fit es común, cambie el targeting. Si el timing es común, mejore la nutrición. Si la falta de funcionalidad es común, envíe el insight a producto. Si la falta de autoridad es común, mejore el discovery.

Reglas de fuente de verdad

El mapa del ciclo de vida debería indicar dónde vive cada etapa.

Por ejemplo:

• El estado del lead vive en el registro de lead o contacto.
• El ciclo de vida de la cuenta vive en la cuenta.
• La etapa de ventas vive en la oportunidad.
• El ciclo de vida del cliente vive en la cuenta o el objeto de cliente.
• El estado de renovación y expansión puede vivir en la oportunidad, la cuenta o los objetos de suscripción, según el sistema.

Documéntelo. Si los equipos no saben qué objeto es la autoridad, los dashboards no coincidirán.

Para gobernanza relacionada, vea Revenue Operations System of Record.

Revisión de calidad del mapa de etapas

Revise el mapa con registros reales.

Elija diez leads recientes, diez oportunidades, cinco deals closed-won, cinco cuentas en riesgo de renovación y cinco candidatos a expansión. Pregunte si cada registro está en la etapa correcta y si la próxima acción es clara.

Si los revisores no coinciden, la definición no es lo bastante clara. Si la próxima acción no es clara, la etapa no es útil. Si los campos obligatorios están en blanco o llenos de valores sin sentido, el modelo de datos necesita trabajo.

Esta revisión a nivel de registro es mejor que debatir los nombres de etapa en abstracto.

Errores comunes

Demasiadas etapas. Si cada estado menor se convierte en una etapa del ciclo de vida, el reporting se vuelve ruidoso.

Sin criterios de salida. Una etapa sin evidencia se vuelve subjetiva.

Ciclo de vida solo de ventas. Las empresas de ingresos recurrentes también necesitan etapas de cliente y expansión.

Etapas impulsadas por la herramienta. No use una etapa solo porque la plantilla del CRM la incluyó.

Sin owner para etapas estancadas. Si un registro se queda demasiado tiempo, alguien debería saber quién actúa.

Ignorar los datos de closed-lost y churn. Los registros perdidos y con churn le dicen a la empresa qué etapas estaban mal calificadas.

Mapas de etapa distintos por equipo. Pueden existir etapas locales, pero el reporting ejecutivo necesita un solo ciclo de vida compartido.

Ejemplo de política de ciclo de vida

Una política simple puede facilitar el cumplimiento del mapa:

Una etapa del ciclo de vida solo puede agregarse cuando cambia la propiedad, la acción requerida, el reporting o el estado del cliente. Toda etapa debe tener criterios de entrada, criterios de salida, un owner, datos obligatorios, antigüedad esperada y una vía de excepción. Las etapas usadas en el reporting ejecutivo deben aprobarse mediante la gobernanza de RevOps y documentarse en el diccionario de datos.

Esa política evita la proliferación de etapas.

Checklist de cambio de etapa

Antes de cambiar una etapa, pregunte:

• ¿Qué reportes usan esta etapa?
• ¿Qué workflows o automatizaciones dependen de ella?
• ¿Qué equipos la cargan o la actualizan?
• ¿Qué comparaciones históricas se romperán?
• ¿Qué campos se vuelven obligatorios u opcionales?
• ¿Qué capacitación o inspección del manager cambia?
• ¿Qué dashboards necesitan definiciones actualizadas?

La mayoría de los cambios de etapa son más costosos de lo que parecen. RevOps debería hacer visible ese costo antes de aprobar el cambio.

Recomendación práctica

Empiece con un mapa de ciclo de vida completo pero simple, y agregue detalle solo donde las decisiones lo exijan.

Para muchas empresas B2B, la primera versión debería cubrir:

• Lead capturado
• MQL
• SQL
• Oportunidad
• Closed-won
• Onboarding
• Cliente activo
• Riesgo de renovación
• Candidato a expansión

Eso alcanza para conectar la adquisición, las ventas, el customer success y la planificación. Se pueden agregar etapas más granulares después, cuando la empresa tenga evidencia de que mejoran la gestión, y no solo el detalle del reporting.

El mejor mapa de etapas es aburrido en el buen sentido. Los líderes lo entienden, los managers pueden hacerlo cumplir, los sistemas pueden sostenerlo y los nuevos empleados pueden aprenderlo sin explicaciones privadas. Si el mapa necesita interpretación constante, no está terminado.

Paquete de revisión de gobernanza de etapas

Una revisión de etapas del ciclo de vida debería mostrar más que la lista de etapas.

Incluya:

• Nombre y definición de la etapa.
• Criterios de entrada.
• Criterios de salida.
• Owner principal.
• Campos obligatorios.
• SLA o regla de tiempo.
• Vía de excepción.
• Impacto en el dashboard.
• Impacto en el traspaso posterior.

Este paquete mantiene los cambios de etapa prácticos. Si una etapa propuesta no cambia la propiedad, la evidencia, el tiempo, el reporting o el traspaso al cliente, puede que no merezca existir. Las etapas adicionales deberían reducir la ambigüedad, no agregar etiquetas.

Preguntas frecuentes

¿Cuántas etapas del funnel de ingresos deberíamos tener?

Use las mínimas necesarias para que la propiedad y las decisiones sean claras. La mayoría de las empresas B2B pueden empezar con 8 a 10 etapas de ciclo de vida.

¿Quién es dueño de las etapas del funnel de ingresos?

RevOps debería gobernar todo el ciclo de vida, con los líderes funcionales a cargo de la ejecución en sus etapas.

Más información

• Funnel Governance
• Lead to Opportunity Process
• Opportunity to Customer Process
• Customer to Expansion Process