--- title: "¿Cómo detecta a los clientes en riesgo de abandono antes de la renovación?" blueprint: 014 slug: customer-health-score-churn-risk category: Éxito del cliente published: 2026-09-23 revised: 2026-09-23 platform: Coevera CRM (formerly Pipeliner CRM) canonical: https://blueprints.coevera.com/es/blueprints/customer-health-score-churn-risk/ language: es translation_of: https://blueprints.coevera.com/blueprints/customer-health-score-churn-risk/ author: Lucia Schmidt publisher: Coevera customer_data: none --- # ¿Cómo detecta a los clientes en riesgo de abandono antes de la renovación? **Respuesta corta.** Coevera tiene un **motor de salud nativo**, así que la puntuación es configuración y no un campo que alguien mantiene. Se configura **por subtipo de registro**: una lista de **reglas de indicadores** (cada una, un campo, un operador y una puntuación en puntos) se resuelve en una puntuación numérica, una de cuatro **bandas** y una **tendencia**. Un conjunto aparte de **indicadores críticos** puntúa `-1`, y como la banda Critical también es `-1`, una sola regla crítica que coincida, según los valores guardados, fuerza la peor banda por bien que haya puntuado todo lo demás; se deduce, no se observó en un recálculo. La banda de salud es un disparador de procesos legítimo, verificado en producción. Pero la regla de diseño que hace que esto funcione es: **deje que la puntuación dirija la atención, y que una persona se comprometa.** Los cambios de salud avisan al responsable de la relación; el responsable registra un veredicto en un campo propio; y **el campo de veredicto** es lo que dispara el contacto con el cliente. La salvedad: la puntuación se **recalcula, no está en vivo**. La automatización se ejecuta cuando se produce el recálculo, no cuando se movió el campo subyacente. ## 01 · El 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. ## 02 · Por 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. ## 03 · Modelo 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](https://help.coevera.com/en/articles/5609036-account-management-using-account-health-in-coevera), para la funcionalidad tal como la configura un administrador. > **Este es el dato que sorprende.** Activar la salud es una decisión por subtipo, y los subtipos > que usted no puntúa siguen llevando una configuración completa. Puntuar a un cliente de forma > distinta que a un prospecto es precisamente el objetivo, pero también hay que contar con la > consecuencia de mantenimiento del §6. ### Lo que contiene una configuración | Propiedad | Qué es | |---|---| | `categories` | Las bandas. Cada una tiene una etiqueta, un umbral entero y un color. Cuatro por defecto: Critical, Poor, Neutral, Good | | `calculationType` | `Manual` (cada regla lleva puntos que se suman) o `Priority` (las reglas están ordenadas y no llevan puntos) | | `healthIndicators` | Las reglas de puntuación | | `criticalHealthIndicators` | Un conjunto de reglas **aparte** para condiciones descalificantes | | `isEnabled`, `lastRecalculation`, `calculationProgress` | Si se ejecuta, cuándo se ejecutó por última vez y cuánto ha avanzado un recálculo en curso | ### Lo que recibe cada registro | En el registro | Tipo | Notas | |---|---|---| | `healthStatus` | entero | La puntuación. **Solo lectura**: la controla el motor | | `healthCategory` | id | La banda resultante. **Editable**, lo que importa en dos sentidos; véanse §5 y §6 | | `health` | objeto | `score`, `trend`, resultados por indicador, `lastCalculation` | 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](https://blueprints.coevera.com/es/blueprints/where-should-this-data-live/). ## 04 · Configuración a nivel de campo ### La anatomía de una regla de indicador | Propiedad | Finalidad | |---|---| | `field` | El id del campo que se evalúa | | `operator` | Uno de 23: `Is`, `IsNot`, `IsEmpty`, `IsNotEmpty`, `Less`, `LessOrEqual`, `More`, `MoreOrEqual`, `Between`, `BetweenNot`, `Contains`, `ContainsNot`, `Has`, `HasNot`, `RelativePeriod`, `RelativePeriodNot`, `In`, `InNot`, `StartsWith`, `EndsWith`, `IsActive`, `IsNotActive`, `Nop` | | `values` | Contra qué se evalúa | | `score` | Puntos otorgados cuando la regla coincide | | `description` | **La regla en palabras.** Opcional, y el §6 trata de lo que ocurre cuando se deja vacía | `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». > **Esta es la codificación, no una regla rota.** La misma convención aparece en los filtros de > procesos, donde las condiciones de supresión almacenan `null` con `"0"` para «es falso». La > consecuencia práctica: **nunca lea un operador sin su valor**; en una regla booleana, el valor > *es* la condición, y una revisión que solo recorra los operadores verá un aparente vacío justo > donde vive la lógica. ### 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: | Dimensión | Indicador | Operador | Puntos | |---|---|---|---| | ¿Lo están usando? | Porcentaje de uso de licencias | `More` | 25 | | ¿Sigue conectado? | Fecha de la última sincronización de telemetría | `RelativePeriod` | 25 | | ¿Trabajan con él? | Fecha en que el cliente creó un registro por última vez | `RelativePeriod` | 25 | | ¿Tiene dificultades el equipo de soporte? | Rollup de tickets abiertos durante más de dos semanas | `Is` | 20 | | **Indicadores críticos, cada uno puntúa `-1`** | | | | | ¿Relación comercial intacta? | Estado de la cuenta | `IsNot` | `-1` | | Uso desplomado | Porcentaje de uso de licencias por debajo de un mínimo | `Less` | `-1` | | ¿Paga? | Indicador de enviado a cobro | — | `-1` | 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: | Banda | Configuración ponderada | Configuración por prioridad | |---|---|---| | Critical | `-1` | `-1` | | Poor | 35 | 30 | | Neutral | 75 | 80 | | Good | 100 | 100 | 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 | `calculationType` | Cómo se resuelve | Úselo cuando | |---|---|---| | `Manual` | Cada regla lleva puntos; los puntos de las reglas que coinciden se suman en la puntuación | Varias señales parciales deben acumularse: el caso habitual para un cliente | | `Priority` | Las reglas están ordenadas y llevan `0` puntos; la posición decide el resultado | Una señal dominante debe zanjarlo, con el resto como alternativas | 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. ## 05 · Automatizació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 | | Capa 1: la máquina detecta | Capa 2: una persona se compromete | |---|---|---| | Disparador | Cambia la categoría de salud | Cambia un **campo de veredicto** | | Lo escribe | El motor de salud | El responsable de la relación, a mano | | Acción | Avisar al responsable. Nada más | La cadena completa de contacto | | Significado | «Merece un vistazo» | «He juzgado que esta cuenta está en riesgo» | 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](https://blueprints.coevera.com/es/blueprints/keeping-hundreds-of-automations-maintainable/) trata la restricción y la disciplina de nombres que mantiene legible una cadena así. > **Por qué merece la pena la indirección.** El campo de veredicto es constancia de que una > persona concreta evaluó esta cuenta en esta fecha y llegó a una conclusión. Eso es auditable, > sirve para informes y se puede revisar cuando la cuenta se pierde de todos modos, y nada de eso > vale para un cruce de umbral. También significa que una integración en pausa degrada la > *puntuación* sin generar una sola acción de cara al cliente. ### 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ó. ## 06 · Límites y compromisos > **La puntuación no puede explicarse a sí misma a menos que usted lo haga posible.** Cada regla > de indicador tiene un campo `description`, y en la configuración examinada **todas las > descripciones de todas las reglas en las quince configuraciones estaban vacías**. El aparato > para responder «¿por qué esta cuenta está en Poor?» viene con el producto y queda en blanco por > defecto, de modo que la respuesta solo se alcanza abriendo la configuración y resolviendo a mano > los identificadores de campo. Rellénelo al escribir cada regla; nada se lo va a pedir nunca. - **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](https://blueprints.coevera.com/es/blueprints/automating-on-integration-owned-fields/) 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. ## 07 · Verificació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?](https://blueprints.coevera.com/es/blueprints/automating-on-integration-owned-fields/) — lectura imprescindible si algún indicador lee un campo replicado. - [Blueprint 008 — ¿Cómo prevé renovaciones que todavía no existen como registros?](https://blueprints.coevera.com/es/blueprints/forecasting-renewals-before-they-exist/) — 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?](https://blueprints.coevera.com/es/blueprints/keeping-hundreds-of-automations-maintainable/) — 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?](https://blueprints.coevera.com/es/blueprints/customer-survey-answers-onto-the-record/) — 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?](https://blueprints.coevera.com/es/blueprints/where-should-this-data-live/) — decidir entre una señal permanente y un registro de evaluación revisable. ## Preguntas frecuentes ### ¿Cómo detecta a los clientes en riesgo de abandono antes de la renovación? Use el motor nativo de salud de entidades en lugar de un campo de puntuación mantenido a mano. La salud se configura por subtipo de registro: un conjunto de reglas de indicadores, cada una con un campo, un operador y una puntuación en puntos, se resuelve en una puntuación numérica, una de cuatro bandas y una tendencia. Un conjunto aparte de indicadores críticos se guarda con una puntuación de menos uno, y una banda Critical está en menos uno, así que un indicador crítico que coincida debería forzar la peor banda con independencia de lo que hayan puntuado las demás reglas; se deduce de esos valores guardados, no se observó en un recálculo. Entonces cambia la banda de salud de la cuenta, y un proceso puede dispararse con ese cambio. ### ¿Debe una puntuación de salud en descenso disparar directamente la intervención con el cliente? No. Una puntuación es una señal probabilística y una intervención es un compromiso, así que no deben conectarse entre sí. Deje que el cambio de salud avise a la persona responsable de la relación, y haga que esa persona registre un veredicto en un campo propio. El cambio del campo de veredicto es lo que dispara la cadena de contacto. Así se evita que un problema de calidad de datos o una integración en pausa generen acciones de cara al cliente. ### ¿Se calcula en tiempo real la puntuación de salud de un CRM? No. La puntuación se recalcula en lugar de estar en vivo: la configuración de salud registra una marca de tiempo del último recálculo y un porcentaje de progreso del cálculo, y el recálculo puede lanzarse para un solo registro o para todos. Así que un proceso que se dispara con un cambio de salud se ejecuta cuando se produce el recálculo, no en el momento en que cambió el campo subyacente. ### ¿Qué campos son buenos indicadores de la salud del cliente? Señales operativas que genera el cliente, no opiniones que alguien registra. Un conjunto que funciona cubre cuatro cosas: si se usa el producto, si sigue conectado, si el equipo de soporte tiene dificultades y si la relación comercial está intacta; por ejemplo, el uso de licencias, la fecha de la última sincronización de telemetría, la fecha en que el cliente creó un registro por última vez, un rollup de tickets de soporte con más de dos semanas, el estado de la cuenta y un indicador de enviado a cobro. ### ¿Por qué dos cuentas con la misma puntuación de salud pueden estar en bandas distintas? Porque las bandas se configuran por subtipo de registro, y cada subtipo lleva sus propios umbrales. En un espacio real, las configuraciones ponderadas fijan las bandas en 35 y 75, mientras que las basadas en prioridad las fijan en 30 y 80, así que la misma puntuación se lee como Poor en un subtipo y como Neutral en otro. La configuración de salud no es global. --- Publicado por Coevera. Abstraído al patrón reutilizable: sin nombres de clientes, sin datos de clientes, sin datos personales.