¿Cómo detecta a los clientes en riesgo de abandono antes de la renovación?

01El problema de negocio

Un cliente no abandona el día de la renovación. Abandona a lo largo de los meses anteriores, en silencio, y la conversación de renovación es donde usted se entera. Para entonces, las intervenciones útiles (arreglar lo que se rompió, formar al equipo que nunca completó el onboarding, llegar al patrocinador que se marchó) llegan todas demasiado tarde para importar.

Así que el requisito es una alerta temprana que realmente llegue a alguien:

• una lectura permanente de cada cliente, actualizada sin que nadie la mantenga;
• construida a partir de señales que genera el cliente, no de opiniones que alguien se acuerda de registrar;
• expresada de forma que «¿por qué esta cuenta está en ámbar?» tenga respuesta;
• que llegue a la persona responsable de la relación, no a un dashboard;
• y que conduzca a una acción concreta y comprometida, con constancia de que se realizó.

El punto intermedio es donde muere la mayoría de las puntuaciones de salud. Un número que nadie sabe explicar se discute y después se ignora. El último es donde muere el resto: una señal que no genera ninguna obligación no genera ningún resultado.

02Por qué falla el enfoque obvio

Un campo de salud que alguien mantiene

El primer instinto es un desplegable (verde, ámbar, rojo) que fija el gestor de cuenta. Describe el estado de ánimo del gestor de cuenta, se degrada en cuanto la atención se va a otra parte y siempre está más desactualizado justo en las cuentas que nadie vigila. Que son las cuentas en riesgo.

Un campo calculado o de rollup

El mejor instinto es calcularla: un campo de fórmula o de rollup que produce un número. Así obtiene la aritmética y nada del aparato. No hay historial, así que no puede ver un declive; no hay tendencia, así que un 60 que cae desde 90 parece idéntico a un 60 que sube desde 30; no hay atribución, así que no puede decir qué dato de entrada se movió; y no hay bandas, así que cada consumidor del número reinventa los umbrales. Acaba reconstruyendo mal el motor de salud, dentro de un campo.

Conectar la intervención directamente a la puntuación

El error de mayores consecuencias es de arquitectura, no de mecánica: lanzar el contacto con el cliente directamente cuando la puntuación cruza un umbral. Está a un nodo de proceso de distancia y es un error, porque una puntuación es una señal probabilística y el contacto con el cliente es un compromiso. Conectarlos tiene tres consecuencias:

• Los problemas de datos se convierten en contactos con clientes. Una integración se pausa, un indicador se degrada en todas las cuentas, y el CRM envía un email a la mitad de su base de clientes sobre un problema que no existe.
• Nadie asume la valoración. Cuando un umbral de puntuación envía el email, ningún humano ha decidido nunca que esta cuenta estuviera en riesgo, así que ningún humano responde de lo que ocurra después.
• La banda oscila. Un recálculo mueve una cuenta a través de un umbral y de vuelta, y cada cruce es otro disparo.

Un dashboard

Una lista ordenada de cuentas en riesgo es realmente útil y del todo insuficiente, porque depende de que alguien decida mirarla. La puntuación de salud justifica su coste cuando interrumpe a la persona adecuada; un dashboard no interrumpe a nadie.

03Modelo de datos

Una configuración de salud por subtipo de registro

La salud no es un ajuste de todo el espacio. Un registro de configuración indica un entityType y un typeId (un subtipo de registro concreto), así que un tipo de cuenta que representa a un cliente de pago se puntúa con reglas y bandas distintas de las de uno que representa a un prospecto. En un espacio real hay quince configuraciones en Account, una por tipo de cuenta, y exactamente una está activada.

Fuente. Centro de ayuda de Coevera, Account management — using account health in Coevera, para la funcionalidad tal como la configura un administrador.

Lo que contiene una configuración

Lo que recibe cada registro

La tendencia es un enum real (Increasing, Decreasing, NoChange, Critical), no algo que usted deduzca. Y cada indicador informa de Ok, Error o Critical individualmente, con la fecha en que cambió por última vez, así que «esta cuenta no supera esta comprobación desde marzo» se puede responder desde el registro.

El historial es lo que merece la pena conocer

La salud guarda un historial día a día. Cada entrada lleva la fecha, la puntuación, la tendencia y una lista de cambios, y cada cambio indica un scoreDifference, el ruleId y el fieldId que se movió.

Eso es atribución diaria. Es la diferencia entre «esta cuenta está en 55» y «esta cuenta cayó 25 puntos el día catorce, cuando la regla de uso de licencias dejó de coincidir». También es la respuesta al requisito más difícil del §1, y es la razón más sólida para usar el motor en lugar de calcular un número en un campo.

La alternativa descartada

Modelar la salud como campos personalizados (un campo de puntuación, un desplegable de banda, una fecha de última puntuación) es el reflejo. Reproduce la puntuación y nada más: sin historial, sin tendencia, sin estado por indicador, sin atribución y sin recálculo. Donde una estructura realmente distinta sí está justificada es cuando cada evaluación de salud debe ser un registro revisable con su propio responsable y ciclo de vida: una revisión periódica documentada en lugar de una señal permanente. Eso es un registro hijo relacionado, y el marco para tomar esa decisión es el Blueprint 003.

04Configuración a nivel de campo

La anatomía de una regla de indicador

RelativePeriod es el operador al que conviene recurrir con más frecuencia: evalúa una fecha frente a una ventana móvil, que es como se expresa «ha sincronizado en los últimos N días» o «ha creado un registro este trimestre» sin que un trabajo programado mantenga un indicador. Su valor es una lista de cuatro partes (un modo, una dirección, una unidad y una cantidad), como en ["Custom", "Last", "Day", "14"] para «en los últimos catorce días».

Las reglas booleanas no tienen operador

Una condición sobre una casilla de verificación no almacena ningún operador: operator: null, y el valor lleva el sentido: "1" para verdadero, "0" para falso. Un indicador crítico que vigila un indicador de enviado a cobro es, por tanto, null más "1", que significa «esta casilla está marcada».

Elegir indicadores: señales, no opiniones

La regla práctica que resiste el contacto con la realidad es que un indicador debe ser algo que hace el cliente, no algo que registra un compañero. Una configuración real tiene siete reglas: cuatro indicadores ponderados, uno por dimensión, y tres críticos:

Fíjese en la forma más que en los detalles. Cada indicador ponderado es un hecho sobre el uso del producto o la calidad del servicio; cada indicador crítico es un hecho sobre la relación comercial. Observe también que un mismo campo aparece en ambos conjuntos con operadores distintos: el uso de licencias por encima de un objetivo suma 25 puntos, y por debajo de un mínimo descalifica. Esa es la forma prevista de expresar una métrica que tiene tanto un rango sano como uno fatal.

También plantea una decisión que conviene tomar deliberadamente: el mínimo sano y el techo crítico no tienen por qué coincidir. Donde no coinciden, las cuentas en el hueco no suman puntos por ese indicador y tampoco son críticas, lo que a menudo es exactamente lo correcto, ya que es la franja en la que una métrica es simplemente mediocre. Pero es una elección, y dejarla implícita significa que nadie puede decir qué se pretendía que significara el hueco.

Las bandas, y cómo lo crítico las cortocircuita

Las categorías llevan un umbral entero, que se lee como el techo de la banda:

Lo elegante es que la banda Critical esté en -1. Según los valores guardados, un indicador crítico no resta puntos: fija la puntuación en -1, que está por debajo del techo de cualquier otra banda, así que una sola regla crítica que coincida lleva la cuenta a Critical por bien que hayan puntuado las reglas ponderadas. Una cuenta puede estar usando todas las licencias, sincronizando a diario y sin abrir tickets, y aun así ser Critical porque se envió a cobro. Eso es correcto, y se obtiene sin una sola línea de automatización. Esto se deduce de las puntuaciones guardadas de las reglas y de los umbrales de las bandas; no se observó en un recálculo.

Observe también que esas dos configuraciones reales fijan las bandas en umbrales distintos: 35/75 frente a 30/80. La misma puntuación es Poor en un subtipo y Neutral en otro, lo que es una característica de la configuración por subtipo y una trampa para quien compare puntuaciones entre tipos.

Ponderado o por prioridad

En el uso real, las configuraciones ponderadas llevan puntos explícitos en cada regla y las de prioridad llevan cero en todas; así se distingue a simple vista qué modo usa realmente una configuración.

05Automatización y lógica

La salud es una superficie de disparo

Para la automatización, healthCategory es un campo corriente, así que un proceso disparado por cambios puede vigilarlo. Verificado en producción: un proceso se dispara con la actualización de Account con exactamente un campo vigilado, la categoría de salud, filtra por la proximidad de la renovación y envía un email al responsable de la relación.

Ese proceso hace una sola cosa: avisa a un humano. No envía ningún mensaje de cara al cliente ni crea ninguna tarea en nombre del cliente. Ese es todo el diseño.

Las dos capas

El campo de veredicto es un botón de opción personalizado corriente: un pequeño conjunto de resultados explícitos como probable renovación, en riesgo, pérdida prevista. Es lo que rellena el responsable de la cuenta después de mirar de verdad. Un proceso en producción vigila ese único campo y, cuando cambia, envía un email al responsable y al gestor de la relación y después pasa el testigo a tres subprocesos que crean el trabajo de seguimiento.

Ese patrón de traspaso no es decorativo: un proceso lleva un filtro cuyas ramas se rigen por la primera coincidencia, así que las consecuencias independientes de un veredicto tienen que ser procesos separados. El Blueprint 011 trata la restricción y la disciplina de nombres que mantiene legible una cadena así.

La red de seguridad

La capa 1 solo se dispara cuando la banda cambia. Una cuenta que lleva cuatro meses en Poor nunca vuelve a dispararla, y es justo la cuenta que usted más necesita revisar. Así que el patrón necesita una tercera pieza: un barrido programado que encuentre las cuentas próximas a la renovación cuya banda sea cualquier cosa menos Good, o cuyo campo de veredicto no se haya tocado en noventa días, y cree una tarea de revisión. La automatización disparada por cambios detecta el deterioro; la automatización programada detecta la desatención. Necesita ambas, y fallan de formas distintas.

El recálculo, y lo que significa para los tiempos

La puntuación no está en vivo. Una configuración registra lastRecalculation y un porcentaje calculationProgress, y el recálculo puede lanzarse para un registro o para todos. Así que la cadena causal es:

field changes → recalculation runs → score and band change → process fires

Todas las suposiciones de tiempos deben basarse en la segunda flecha, no en la primera. En el espacio real, la configuración activada se había recalculado la misma mañana en que se leyó.

06Límites y compromisos

• La puntuación se recalcula, no está en vivo. La automatización se ejecuta con el recálculo, así que «inmediatamente cuando cae el uso» no es posible, y una interpretación en el mismo día de un cambio de banda solo es tan buena como la cadencia de recálculo.
• Un indicador sobre un campo replicado convierte una caída en una señal de abandono. Cuando un indicador lee un campo que controla otro sistema (una fecha de sincronización de telemetría, un estado de suscripción), una integración detenida degrada ese indicador en todas las cuentas a la vez, y el motor no puede distinguir entre «el cliente dejó de usarlo» y «la tubería dejó de entregar datos». Esto es una consecuencia razonada de dos hechos verificados, no un incidente observado: los indicadores reales sí leen campos de fecha replicados, y el Blueprint 009 documenta lo que provocó en producción una caída de la replicación de varios días. La mitigación es la misma que prescribe ese blueprint (una comprobación de la frescura de la sincronización, independiente de los datos sincronizados) más la regla del §5 de que una puntuación nunca dispara por sí sola un contacto con el cliente.
• La categoría de salud es editable. Es útil, porque una persona puede corregir una banda que el motor calculó mal, y peligroso, porque una banda fijada a mano no se distingue de una calculada, y el siguiente recálculo puede sobrescribirla. Si las correcciones importan, regístrelas en un campo propio.
• La configuración se multiplica por subtipo. Quince tipos de cuenta significaban quince configuraciones, cada una con sus propias bandas y reglas, todas menos una desactivadas. Añadir un indicador al «modelo de salud del cliente» significa editar la que está activada y recordar que las demás han divergido; en el espacio real, las configuraciones ponderadas y por prioridad ya fijan las bandas en umbrales distintos. No hay herencia.
• Una regla booleana no lleva operador, y el valor contiene el sentido. Una condición sobre una casilla de verificación almacena operator: null con un valor de "1" para verdadero o "0" para falso. Así que un indicador crítico que lee un indicador de enviado a cobro es null más "1": «esta casilla está marcada». Es la codificación normal de la plataforma, no una regla rota, y significa que un operador nulo no se puede leer por sí solo: el valor es toda la condición. Cualquier auditoría de una configuración tiene que leer ambos, y un diff que solo muestra el operador no muestra nada.
• Las puntuaciones no tienen por qué llegar al techo de la banda. En la configuración ponderada real, los cuatro indicadores suman 95 frente a un techo de Good de 100, así que una cuenta perfecta puntúa 95. Eso es inofensivo (la banda es un techo, no un objetivo), pero hace que la puntuación bruta sea algo poco útil para mostrar a nadie, y aún peor para comparar entre subtipos.
• Los indicadores de registros relacionados no están probados. La configuración admite reglas de indicadores tomadas de una entidad relacionada a través de un lookup, y en el espacio examinado esa capacidad no se usaba: todas las reglas reales leían los propios campos de la cuenta. Verificado en el esquema, no verificado en su comportamiento. Cuando necesite «sin actividad en 90 días», un campo de rollup en la cuenta es la vía que se sabe que funciona.
• Solo se observó salud en Account. La propiedad del tipo de entidad admite otros; todas las configuraciones reales estaban en Account. No se ha probado en otras.

El compromiso que conviene decir claramente

El motor le da historial, tendencia, estado por indicador, atribución diaria y una banda que la automatización puede vigilar; nada de eso lo construiría correctamente a mano, y todo llega solo con configuración. Lo que no le da es una predicción. No hay modelo, ni ponderación sugerida, ni aprendizaje a partir de las cuentas que realmente abandonaron; las reglas y los puntos son su hipótesis sobre por qué se van los clientes, y el motor solo los aplica de forma coherente. Es un trato justo, siempre que la hipótesis se revise cuando sea errónea, que es para lo que sirve el historial, y la razón por la que el §5 insiste en que lo que entra en el registro como decisión es el veredicto de una persona, no la puntuación.

07Verificación

Leído el 2026-09-10 en un espacio de producción real: el conjunto completo de configuraciones de salud, los campos de indicadores resueltos y los procesos que consumen el resultado.

• Quince configuraciones de salud en Account, una por tipo de cuenta, con exactamente una activada y con una marca de tiempo de recálculo de la mañana de la lectura. Las otras catorce estaban configuradas y desactivadas.
• Se encontraron ambos modos de cálculo en uso real (configuraciones ponderadas con puntos explícitos en cada regla, configuraciones por prioridad con cero en todas) y fijan las bandas en umbrales distintos, 35/75 frente a 30/80.
• El mecanismo crítico se confirmó a partir de los datos: cada regla crítica de cada configuración lleva score: -1, y cada configuración define una banda Critical en -1. Según esos valores guardados, un indicador crítico domina la puntuación; no se observó en un recálculo.
• Cada id de campo de indicador se resolvió a su campo, que es de donde proceden las cuatro dimensiones del §4: uso, recencia de la telemetría, registros generados por el cliente, tickets de soporte envejecidos, más el estado de la cuenta y un indicador de cobro como reglas críticas. Un mismo campo aparece en ambos conjuntos con operadores opuestos.
• La salud como disparador se verificó, no se supuso. Un proceso real y activado se dispara con la actualización de Account con un único campo vigilado, y ese id de campo se resuelve a la categoría de salud nativa. Un segundo proceso real vigila un único campo personalizado de botón de opción (el veredicto) y pasa el testigo a tres subprocesos.
• Los 23 operadores y los cuatro valores de tendencia se leyeron del esquema, al igual que la puntuación, la banda y el estado por indicador de cada registro, y la estructura del historial con su atribución de diferencia de puntuación, regla y campo.
• Todas las descripciones de reglas estaban vacías en las quince configuraciones.
• Los valores de las reglas se leyeron junto con los operadores, que es lo que establece la codificación booleana del §4: la única regla que no lleva operador lo empareja con un valor de "1". La misma convención operator: null aparece en los filtros de procesos con un valor de "0" para una evaluación falsa, así que la codificación es coherente en dos subsistemas independientes y es el valor lo que distingue los dos sentidos.
• La gramática del valor de periodo relativo se leyó de reglas reales: una lista de cuatro partes con un modo, una dirección, una unidad y una cantidad, que es la forma que se da en el §4.

No observado, y se indica como tal:

• Un recálculo en curso, ni la cadencia con la que se ejecuta. Solo que se había ejecutado, y que existe un porcentaje de progreso.
• Indicadores tomados de una entidad relacionada a través de un lookup: verificado en el esquema, no verificado en su comportamiento.
• La salud en cualquier entidad distinta de Account.
• Si una categoría de salud escrita a mano sobrevive al siguiente recálculo.
• Un indicador crítico que coincida fijando la puntuación en -1 durante un recálculo. Ese comportamiento se deduce de las puntuaciones guardadas de las reglas y del umbral de la banda Critical.
• El orden exacto de resolución en el modo por prioridad, más allá de que lo determina el orden de las reglas y los puntos son cero.

Qué indicaría una regresión

• Muchas cuentas que cambian de banda el mismo día. El deterioro real no está sincronizado. Un movimiento en todas las cuentas significa que se rompió el dato de entrada de un indicador (lo más habitual, un campo replicado) y parecerá una oleada de abandonos.
• Una marca de tiempo de recálculo que deja de avanzar. La puntuación simplemente se congela; nada falla, y cada banda de cada registro se convierte en silencio en una afirmación sobre el pasado.
• Cambios de banda que se disparan mientras los campos de veredicto siguen sin tocarse. La capa 1 funciona y la capa 2 no: se avisa a la gente y nadie decide. Es el modo de fallo que parece más sano desde el lado de la automatización.
• Cuentas que llevan meses en Poor sin una tarea de revisión. El barrido programado se ha detenido, y la automatización disparada por cambios nunca las detectará, porque su banda no cambia.

Blueprints relacionados

• Blueprint 009 — ¿Cómo automatiza sobre campos del CRM que pertenecen a otro sistema? — lectura imprescindible si algún indicador lee un campo replicado.
• Blueprint 008 — ¿Cómo prevé renovaciones que todavía no existen como registros? — el lado de los ingresos de la misma renovación; la salud es el lado del riesgo.
• Blueprint 011 — ¿Cómo mantiene cientos de automatizaciones del CRM de forma sostenible? — por qué un veredicto se ramifica en varios procesos.
• Blueprint 012 — ¿Cómo lanza una encuesta a clientes desde su CRM y recupera las respuestas en el registro? — cómo llevar una pregunta respondida al registro para que una regla de salud pueda leerla.
• Blueprint 003 — ¿Cómo modela algo para lo que su CRM no tiene un objeto? — decidir entre una señal permanente y un registro de evaluación revisable.