---
title: "¿Cómo prevé renovaciones que todavía no existen como registros?"
blueprint: 008
slug: forecasting-renewals-before-they-exist
category: Automatización
published: 2026-09-23
revised: 2026-09-23
platform: Coevera CRM (formerly Pipeliner CRM)
canonical: https://blueprints.coevera.com/es/blueprints/forecasting-renewals-before-they-exist/
language: es
translation_of: https://blueprints.coevera.com/blueprints/forecasting-renewals-before-they-exist/
author: Lucia Schmidt
publisher: Coevera
customer_data: none
---

# ¿Cómo prevé renovaciones que todavía no existen como registros?

**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.

## 01 · 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.

## 02 · 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](https://blueprints.coevera.com/es/blueprints/document-numbering-that-survives-production/),
donde el rodeo con automatización que se suele recomendar duplica algo que ya viene de serie como
un botón de opción.

## 03 · 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](https://help.coevera.com/en/articles/4190616-using-opportunity-recurrence) y [Using
opportunity revenue
recognition](https://help.coevera.com/en/articles/4293948-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.

## 04 · 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.

## 05 · 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](https://blueprints.coevera.com/es/blueprints/one-entity-five-request-types/): 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](https://blueprints.coevera.com/es/blueprints/ai-fields-read-documents/).

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.

## 06 · 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](https://blueprints.coevera.com/es/blueprints/pricing-one-product-many-prices/).

### 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.

## 07 · 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.

## Blueprints relacionados

- [Blueprint 014 — ¿Cómo detecta a los clientes en riesgo de abandono antes de la
  renovación?](https://blueprints.coevera.com/es/blueprints/customer-health-score-churn-risk/) —
  la señal de riesgo de abandono que, según este blueprint, necesita una renovación, construida a
  partir de la puntuación de salud nativa.
- [Blueprint 007 — ¿Cómo fija precios distintos para un mismo producto por región, segmento o
  contrato?](https://blueprints.coevera.com/es/blueprints/pricing-one-product-many-prices/) — de
  dónde salen el precio de una renovación y su incremento permitido.
- [Blueprint 010 — ¿Cómo entrega una oportunidad ganada al equipo que la
  ejecuta?](https://blueprints.coevera.com/es/blueprints/handover-from-sales-to-delivery/) — un
  segundo pipeline para el trabajo que sigue a un acuerdo ganado, con la misma restricción de un
  tipo, un pipeline.

## 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.

---

Publicado por Coevera. Abstraído al patrón reutilizable: sin nombres de clientes, sin datos
de clientes, sin datos personales.