La respuesta corta
Separe los ingresos comprometidos del proceso de renovación. Los ingresos futuros de un acuerdo plurianual firmado ya están en el sistema: un calendario de ingresos en la oportunidad existente reparte su valor en periodos con fecha (mes, trimestre o año), y cada periodo es un registro con una fecha y un importe, según lo leído del esquema; no se ha observado la generación de los periodos. No hacen falta registros de acuerdos futuros. El centro de ayuda limita Revenue Recognition al nivel Business & Enterprise.
Si el cliente renueva es una pregunta de ventas, y necesita una oportunidad real.
Una regla de recurrencia de la oportunidad las genera de forma nativa, con una
cadencia AfterNMonths o AfterNYears que corresponde a un plazo
contractual y no a una fecha del calendario.
El problema de negocio
Una empresa vende con plazos plurianuales. Alguien pregunta qué aspecto tienen los ingresos del año que viene, y la respuesta honesta requiere tres cosas distintas que normalmente se tratan como una sola:
- Ingresos ya comprometidos. Un contrato de tres años firmado el trimestre pasado obliga al cliente durante dos años más. Ese dinero no es una previsión: está contratado, y no debería aparecer en un pipeline de cosas que se están vendiendo.
- Ingresos que dependen de una decisión. Un plazo que termina en marzo puede renovarse o no, puede renovarse a otro precio, puede renovarse por un periodo más corto. Eso sí es una auténtica oportunidad de venta y pertenece a un pipeline.
- Ingresos en riesgo. Un cliente que cancela a mitad de plazo elimina ingresos comprometidos que ya se habían contado.
El requisito tal como se formula («prever renovaciones que todavía no existen») mezcla las tres cosas. Obtener una respuesta útil empieza por separarlas.
Por qué falla el enfoque obvio
Crear oportunidades de renovación inactivas
El fallo es la inactividad, no la anticipación. Una oportunidad de renovación creada para un plazo a dos años vista es un registro que está en el pipeline activo y que nadie tocará durante veinte meses. La tasa de conversión, el ciclo de venta medio, el envejecimiento por etapa y la previsión ponderada se calculan todos sobre ese pipeline: llénelo de acuerdos en los que nadie trabaja y cada una de esas cifras se degrada, no de forma visible, sino de forma constante.
Pero anticiparse está bien si algo lo impulsa. Una implementación en producción que examinamos crea la oportunidad de renovación al llegar a los 365 días y a continuación ejecuta sobre ella una cuenta atrás por etapas: una tarea de revisión trimestral de negocio a los 180 días, una invitación a una revisión con el cliente a los 90, un control de salud y valor a los 60, y después notificaciones internas y al cliente cada vez más insistentes a los 45, 30, 18 y 15. El registro nunca está inactivo, porque la cuenta atrás le da a alguien algo que hacer desde el día en que aparece.
La regla que se desprende: cree un plazo por adelantado, nunca varios, y solo junto a una cadencia que actúe sobre él. Una oportunidad de renovación sin una cuenta atrás detrás es contaminación del pipeline, esté a la distancia que esté.
Poner todo el valor del contrato en la fecha de cierre
Un acuerdo de tres años registrado como un único valor en una única fecha de cierre dice que la empresa lo ingresó todo en un mes. Cualquier vista por periodos (ingresos mensuales, ritmo trimestral, ARR) es entonces errónea durante todo el plazo, en ambas direcciones: sobrevalorada en el mes de cierre e infravalorada en todos los meses posteriores.
Hacer informes sobre «oportunidades que se cierran el año que viene»
Es el informe instintivo, y responde a la pregunta equivocada. Muestra los acuerdos que se espera que se cierren el año que viene, lo que excluye todos los contratos ya ganados que seguirán generando ingresos el año que viene. Esa suele ser la cifra mayor, y falta por completo.
Construirlo todo con automatización
Comprensible, y en su mayor parte innecesario: las dos mitades tienen mecanismos nativos. Conviene comprobarlo antes de construir, por el mismo motivo que en el Blueprint 006, donde el rodeo con automatización que se suele recomendar duplica algo que ya viene de serie como un botón de opción.
Dos mecanismos, dos preguntas
En Coevera, una oportunidad lleva ambos, y son cosas completamente distintas.
Calendario de ingresos: lo que ya está comprometido
Un calendario asociado a la oportunidad, que contiene:
| Propiedad | Significado |
|---|---|
startDate | Cuándo empiezan los ingresos, que no es la fecha de cierre. |
periodCount | En cuántos periodos se reparte el valor. |
periodType | Month, Quarter or Year. Exactamente esos tres. |
cancelationDate | La terminación anticipada del contrato. Aquí es donde se expresa el abandono. |
periods | Los registros de periodo generados. |
Cada periodo es un registro propio con una fecha y un valor. Esa es la estructura que hace posibles los informes por periodo: los ingresos de cualquier mes son la suma de las filas de periodo con fecha en ese mes, en todos los contratos, independientemente de cuándo se cerraron esos contratos.
Recurrencia: generar el siguiente acuerdo
Una regla aparte, también en la oportunidad, que produce registros de oportunidades futuras:
| Propiedad | Significado |
|---|---|
startDate / endDate | La ventana en la que se generan las ocurrencias. |
stepId | Obligatorio: el paso del pipeline en el que se colocan las oportunidades generadas. |
occurEvery / occurrencesCount | El intervalo, y cuántas producir. |
type | La cadencia; véase más abajo. |
day · dayOfWeek · week · month | Posicionamiento en el calendario, que usan los tipos absolutos y relativos. |
Las cadencias disponibles se agrupan en tres familias:
- Simples: diaria, semanal.
- Absolutas y relativas: mensual o anual, ya sea en un día fijo del calendario («el día 15») o de forma relativa («el último viernes»).
- Después de N: después de N días, semanas, meses o años. Esta es la familia de las renovaciones, porque una renovación vence un plazo después de la anterior y no en una fecha fija del calendario.
Fuentes. Centro de ayuda de Coevera, Using opportunity recurrence y Using opportunity revenue recognition: los dos mecanismos, documentados por separado, que es la distinción sobre la que se construye este blueprint.
La decisión de diseño que esto le deja. Configure la ventana de recurrencia para que la siguiente oportunidad aparezca cuando alguien vaya a trabajarla de verdad (un trimestre antes del final del plazo, no tres años) y deje que el calendario de ingresos recoja mientras tanto los ingresos comprometidos. Así el pipeline se mantiene honesto y la vista de ingresos se mantiene completa al mismo tiempo, que es para lo que sirve separar los dos mecanismos.
Distinguir la renovación del negocio nuevo
Las renovaciones suelen necesitar informes separados del negocio nuevo, lo que implica un tipo de oportunidad. Un hecho estructural que hay que tener en cuenta al planificar: los tipos de oportunidad se corresponden uno a uno con los pipelines. Un espacio con New Business, Expansion y Renewal como tipos tiene, por tanto, tres pipelines, que a menudo es lo que se quiere de todos modos, ya que una renovación pasa por pasos distintos de los de una venta nueva, pero no es una elección libre.
Lo que tiene que añadir usted
La mecánica es nativa; el vocabulario comercial de las renovaciones no lo es. Estos son campos personalizados en todas las implementaciones que hemos visto:
| Campo | Por qué hace falta |
|---|---|
| Duración del plazo | La recurrencia conoce su intervalo; el registro no indica el plazo contratado. |
| Fecha de renovación | Distinta de la fecha de cierre, que es cuando se cierra el acuerdo de renovación. |
| Incremento permitido | Un límite contractual al aumento; hace falta antes de la conversación, no después. |
| Requisitos de facturación y de orden de compra | Si este cliente necesita una orden de compra antes de facturar. Normalmente es un valor por defecto de la cuenta, que se puede anular en cada renovación. |
| Indicador de riesgo de abandono | Alimenta las acciones de recuperación y, a posteriori, se combina con la fecha de cancelación. |
El patrón de valor por defecto en la cuenta con anulación por renovación de esa cuarta fila conviene resolverlo pronto. Es una cuestión de dónde viven los datos, y resolverla tarde significa tener que moverlos.
Cómo impulsar la cuenta atrás
No existe una notificación nativa de «la renovación se acerca». Merece la pena copiar el mecanismo que usa para ello una implementación en producción, porque es más sencillo de lo que parece.
Un campo de cuenta atrás, muchos observadores
Mantenga un único valor «vence en días» en la cuenta, y haga que cada etapa de la cuenta atrás se active con los cambios en ese único campo en lugar de que cada una haga su propia aritmética de fechas. Un número va disminuyendo; la acción de los 180 días, la de los 90 días y la de los 60 días lo observan cada una de forma independiente.
La alternativa, que cada proceso calcule por su cuenta «¿está la fecha de renovación a menos de N días?», multiplica la misma lógica de fechas en una docena de sitios, y acaban divergiendo.
Haga idempotente el creador con un indicador
Una tarea programada diaria que crea registros debe poder ejecutarse sin riesgo todos los días. El patrón: filtrar por que la cuenta atrás cruce el umbral y por que el indicador «renovación ya creada» no esté activado; crear la oportunidad; activar el indicador.
Es la misma forma que la protección de un solo uso del Blueprint 001: la condición hace idempotente la escritura, así que no hace falta ningún registro aparte de «¿se ha ejecutado ya?». Sin ella, una tarea diaria produce una nueva oportunidad de renovación cada mañana durante un año.
Excluya los contratos plurianuales de la cuenta atrás anual
Un contrato de tres años no debería generar actividad de renovación al final del primer y del segundo año. La implementación en producción lo resuelve con un indicador de contrato plurianual explícito que, combinado con un indicador de gestión manual, suprime la cuenta atrás estándar y deriva esas cuentas a un circuito aparte con una fecha de renovación especial.
Conviene incluirlo en el diseño desde el principio. Añadirlo después obliga primero a encontrar todas las cuentas a mitad de contrato que han estado recibiendo correos de renovación que no les correspondían.
Cierre el plazo de forma deliberada
Cuando una suscripción termina de verdad, algo tiene que dejarlo registrado. Una tarea programada que se ejecuta el día siguiente a la fecha de fin establece la fecha de pérdida, registra la fecha del último uso y vacía los campos de renovación orientados al futuro. Sin ella, las suscripciones terminadas siguen apareciendo en los informes de renovación como si todavía estuvieran pendientes.
Dos notas sobre la forma
Un proceso programado que filtra por una fecha necesita una comparación con un periodo relativo y no con un valor fijo. Y un proceso cuyo primer nodo es una acción y no un filtro se guarda correctamente y muestra un lienzo vacío: la forma es disparador, luego filtro y luego acciones, como se explica en el Blueprint 002.
Si la oportunidad de renovación debe heredar algo de la que vence (líneas de producto, la relación con la cuenta, valores de campos personalizados), eso también es automatización. Una regla de recurrencia genera un registro en un paso; no es un mecanismo para copiar contratos.
Límites y compromisos
Los tipos de periodo son mes, trimestre o año, y nada más
Un calendario se reparte en uno de esos tres. La facturación irregular (pagos por hitos, una rampa desigual, un anticipo seguido de plazos) no se puede expresar como un calendario nativo. Ese caso necesita o bien varias oportunidades o bien una entidad hija que contenga el plan de pagos, con precios fijados como en el Blueprint 007.
Un calendario por oportunidad, en el modo basado en el valor de la oportunidad
Cuando Revenue Recognition funciona sobre el valor de la oportunidad, el calendario es un único elemento asociado, no una colección. Un acuerdo que combina, por ejemplo, una licencia anual y un servicio mensual tiene dos cadencias y, en ese modo, hay que dividirlo en dos oportunidades; una decisión de modelado que conviene tomar de forma deliberada en lugar de descubrirla cuando llega el primer contrato de ese tipo.
El artículo del centro de ayuda citado en §3 describe además un modo Product Line, en el que Revenue Recognition se configura en cada línea de producto por separado; con una configuración mensual, cada línea puede tener su propio periodo Month, Quarter o Year. Ese modo es la alternativa documentada a dividir la oportunidad; aquí no se ha probado.
La oportunidad generada se coloca en un paso fijo
La regla de recurrencia requiere un paso de destino, así que todas las ocurrencias generadas aparecen en la misma posición del pipeline. Si las renovaciones deben entrar en etapas distintas según el riesgo o el tamaño, ese enrutamiento es automatización posterior, no parte de la regla.
Los campos de año de renovación almacenados se convierten en mantenimiento anual
Una trampa que solo se ve en una implementación que lleva años en funcionamiento. Si guarda «la renovación de este año», «la renovación del año pasado» y «la renovación del año que viene» como campos en la cuenta, porque los informes los quieren uno al lado del otro, se ha comprometido con una operación anual de reenvejecimiento.
La implementación en producción que examinamos ejecuta una cadena de cuatro procesos una vez por año natural para desplazar pasado ← actual, actual ← siguiente, y avanzar el siguiente doce meses, con ramas separadas para los contratos plurianuales, y después vuelve a derivar las fechas de pérdida. Se ejecuta manualmente, por parte de la persona que recuerda que existe.
Derive estos valores de la fecha de renovación en el momento de la lectura siempre que la capa de informes lo permita. Guárdelos solo donde no quede más remedio y, si es así, deje por escrito que existe ese traspaso anual: es exactamente el tipo de tarea anual que se olvida el año en que la persona responsable cambia de puesto.
Verificado en el esquema, no en el comportamiento
Un límite honesto de este blueprint. La orquestación del §5 y los compromisos anteriores proceden de una implementación que lleva años en producción. La mitad de la entidad nativa es más débil: las formas, los nombres de las propiedades, los tipos de periodo y las cadencias de recurrencia se leyeron directamente del esquema de un espacio en producción y son exactos, pero no creamos un calendario de ingresos para ver cómo se generaban los periodos, ni ejecutamos una recurrencia hasta el final.
Hay dos comportamientos en particular que siguen sin observarse: cómo responden exactamente los registros de periodo cuando se establece una fecha de cancelación a mitad de plazo, y si la generación de recurrencias se ve afectada por que la oportunidad de origen se gane, se pierda o se archive. Ambos son relevantes para los informes. Verifíquelos en un espacio de pruebas antes de construir una previsión sobre ellos, y tenga en cuenta que el endpoint del calendario de ingresos no lleva ninguna referencia propia a la oportunidad, así que la asociación se hace desde el lado de la oportunidad.
El calendario no se puede asociar por REST
Lo intentamos y falló, para que usted no tenga que hacerlo. El endpoint del calendario de ingresos no tiene ninguna referencia propia a la oportunidad, y una creación enviada con una se rechaza. Asociarlo desde la otra dirección, actualizando la oportunidad con un payload de calendario, devuelve éxito y no crea nada. Una lectura posterior no muestra ningún calendario en el espacio.
Ese es el modo de fallo predominante de la API de esta plataforma, documentado a lo largo de toda esta biblioteca: la escritura se acepta, no se produce ningún error y no ocurre nada. Suponga que los calendarios deben crearse a través de la interfaz o de la API de administración mientras no se demuestre lo contrario, y vuelva a leer siempre después de intentarlo.
Una peculiaridad de escritura que conviene conocer
El valor de la oportunidad se lee como un compuesto de valor base, valor en moneda extranjera y moneda, pero se escribe como un número simple. Enviar la forma compuesta al crear se aceptó y produjo sin avisar un valor de cero; el mismo campo establecido como escalar funcionó. Si su previsión depende de que los valores de los acuerdos lleguen correctamente a través de una integración, compruébelos después de escribirlos.
Verificación
- Concilie el calendario con el acuerdo. La suma de los valores de los periodos debe ser igual al valor del contrato. Si no lo es, el calendario y el valor principal cuentan historias distintas y los informes no coincidirán entre sí.
- Compare una vista de ingresos por periodo con una vista por fecha de cierre y confirme que difieren de la forma que espera. Si coinciden, probablemente el calendario no se está usando.
- Establezca una fecha de cancelación en un calendario de prueba y observe qué ocurre con los periodos posteriores a esa fecha antes de fiarse de los informes de abandono.
- Deje que una recurrencia genere al menos dos ocurrencias y compruebe sus fechas frente al plazo previsto, sobre todo con una cadencia de tipo «después de N», en la que un intervalo desfasado en uno es fácil de configurar y difícil de detectar.
- Cuente los registros del pipeline activo antes y después de activar la recurrencia. Si el recuento aumenta en más que la siguiente ocurrencia, la ventana es demasiado amplia y las métricas del pipeline están a punto de desviarse.
- Verifique los valores de los acuerdos después de cualquier escritura de una integración, dado el comportamiento de compuesto frente a escalar descrito más arriba.
Qué indicaría una regresión: valores de periodo cuya suma ya no coincide con el valor del contrato; oportunidades de renovación que aparecen más lejos que la ventana prevista; un contrato cancelado que sigue aportando ingresos a periodos futuros; o un número creciente de oportunidades sin tocar en el pipeline activo, que es el síntoma de que vuelve el fallo descrito en el §2.
Preguntas frecuentes
¿Cómo se prevén en un CRM los ingresos recurrentes o de renovación antes de que la renovación exista como oportunidad?
Separando dos preguntas que suelen confundirse. Qué ingresos compromete ya un acuerdo plurianual firmado se responde con un calendario de ingresos asociado a la oportunidad existente: una fecha de inicio, un número de periodos, un tipo de periodo (mes, trimestre o año) y un conjunto de registros de periodo generados, cada uno con una fecha y un valor; una estructura leída del esquema, sin que se haya observado la generación de los periodos. Esos ingresos ya están en el sistema y no necesitan registros de acuerdos futuros. Según el centro de ayuda, Revenue Recognition está disponible en el nivel Business & Enterprise. Si el cliente renovará realmente es una pregunta de ventas distinta, que se responde generando una oportunidad futura, algo que una regla de recurrencia en la oportunidad original puede hacer automáticamente.
¿Puede un CRM crear automáticamente la siguiente oportunidad de renovación?
En Coevera, sí, de forma nativa. Una oportunidad puede llevar una regla de recurrencia con una fecha de inicio, una fecha de fin opcional, un paso de destino en el pipeline, cuántas ocurrencias generar y un tipo de recurrencia. Los tipos disponibles incluyen diario y semanal, mensual y anual tanto en forma absoluta (un día fijo del calendario) como relativa (por ejemplo, el último viernes), y después de N días, semanas, meses o años; esta última familia es la que corresponde a un plazo contractual, ya que una renovación vence N meses después de la anterior y no en una fecha fija del calendario.
¿Por qué es mala idea crear oportunidades de renovación con años de antelación?
Porque introduce en el pipeline activo acuerdos en los que nadie está trabajando. Las tasas de conversión, el ciclo de venta medio, el envejecimiento por etapa y la previsión ponderada se degradan, porque el pipeline contiene ahora registros que permanecerán sin tocar durante un año o más. Además, convierte las fechas de cierre en ficción, ya que una fecha de renovación a años vista es una conjetura. La separación más adecuada es dejar que el calendario de ingresos recoja los ingresos futuros comprometidos y generar la oportunidad de renovación solo cuando el plazo esté lo bastante cerca como para que alguien vaya a trabajarla de verdad.
¿Cómo se representa el abandono o la cancelación a mitad de plazo en un calendario de ingresos?
El calendario de ingresos lleva una fecha de cancelación junto a su fecha de inicio y su número de periodos. Ese es el campo que expresa que un contrato termina antes de tiempo, en lugar de eliminar periodos o editar el valor original del acuerdo. Tenga en cuenta que cómo responden exactamente los registros de periodo cuando se establece una fecha de cancelación es un comportamiento que hemos documentado a partir del esquema pero no hemos observado en un espacio en producción, así que verifíquelo antes de basar informes en él.