No cuentes cada intento fallido como una baja. Define el periodo, identifica clientes únicos, separa abandonos voluntarios y sigue las incidencias hasta su resolución. Calcula la pérdida sobre una base comparable y mantén aparte el dinero pendiente, los ingresos recuperados y el número de reintentos.
1. Distingue pérdida de cliente e incidencia de pago
Un pago fallido no demuestra que el cliente quiera irse. Puede requerir una actualización del método, una comprobación del comercio o una actuación posterior. Mientras la incidencia sigue abierta y la relación no se ha dado por terminada conforme al procedimiento aplicable, no conviene etiquetarla como una baja definitiva.
La expresión churn involuntario se utiliza para la pérdida asociada a problemas de pago. La documentación de recuperación de ingresos de Stripe distingue este ámbito de la cancelación voluntaria. Esa distinción conceptual no significa que cualquier herramienta use los mismos estados o incluya las funciones de Stripe Billing.
Define para tu negocio qué evento confirma la pérdida y qué periodo de observación utilizarás. Puede existir una diferencia entre el momento del fallo, la interrupción operativa y el cierre definitivo de la relación. Si no explicas ese criterio, dos personas pueden calcular cifras distintas usando exactamente los mismos movimientos.
2. Separa tres grupos antes de calcular
Clasifica por separado a quienes han pedido una baja voluntaria, quienes tienen una incidencia recuperable abierta y quienes finalmente se han perdido por un problema de pago. Añade una categoría de resultado incierto cuando falte evidencia. Forzar todos los casos a pagado o perdido oculta trabajo pendiente y exagera la precisión del informe.
| Grupo | Evidencia que necesitas | Qué no contar todavía |
|---|---|---|
| Baja voluntaria | Solicitud o terminación documentada por esa causa | Un simple fallo de tarjeta |
| Incidencia abierta | Obligación y resultado pendiente de resolver | Una pérdida definitiva |
| Recuperado | Pago confirmado y situación de la relación revisada | Solo un enlace enviado |
| Perdido por pago | Cierre conforme al criterio definido | Cada intento anterior por separado |
La categoría debe describir lo que sabes, no lo que supones. Si el cliente pidió la baja y después se produjo un fallo, revisa la causa principal según tu definición. No conviertas automáticamente el último evento técnico en el motivo del abandono.
3. Cuenta clientes únicos y define la base
Si quieres medir pérdida de clientes, usa un identificador único de cliente. Una persona con tres intentos fallidos sigue siendo una persona. Si además tiene dos suscripciones, debes decidir si estás midiendo clientes o suscripciones y mantener esa elección tanto en el numerador como en el denominador.
Para una tasa sencilla de pérdida en una base inicial, divide los clientes de esa base finalmente perdidos por pago entre los clientes elegibles al inicio del periodo, y multiplica por 100. Indica las fechas y las reglas de inclusión. No mezcles en el numerador altas posteriores que no estaban en el denominador inicial.
Si necesitas estudiar las altas del propio mes, puedes analizarlas como una cohorte separada: un grupo con la misma ventana de observación. Lo importante no es elegir la fórmula más compleja, sino mantener comparables las poblaciones. Publicar una tasa sin explicar a quién incluye dificulta saber si una mejora es real o solo un cambio de criterio.
4. Ejemplo ficticio con 200 clientes iniciales
Un servicio ficticio empieza septiembre con 200 clientes elegibles y sigue exclusivamente a ese grupo. Durante el mes, 12 clientes presentan al menos un fallo de pago. Se registran 25 intentos fallidos porque algunos tienen varios. Al cerrar la ventana de observación acordada, ocho se han recuperado, dos siguen en revisión y dos se consideran perdidos por pago.
La tasa de pérdida por pago de esa base es 2 ÷ 200 × 100 = 1 %. No es 25 ÷ 200, porque 25 representa intentos, ni 12 ÷ 200, porque 12 representa clientes con incidencia. Los dos casos abiertos permanecen visibles y pueden cambiar la lectura cuando se resuelvan.
| Medida ficticia | Cálculo | Resultado |
|---|---|---|
| Clientes con incidencia en la base | 12 ÷ 200 × 100 | 6 % |
| Clientes perdidos por pago | 2 ÷ 200 × 100 | 1 % |
| Recuperados entre clientes con incidencia | 8 ÷ 12 × 100 | 66,67 % provisional |
| Casos todavía abiertos | Conteo de clientes únicos | 2 |
Son datos inventados para explicar el cálculo, no resultados de PagosRecurrentes. La recuperación es provisional mientras queden casos abiertos y no debe compararse con otra cohorte que haya tenido más tiempo para resolverse.
5. Mantén los importes en un análisis separado
La tasa de clientes no cuenta cuánto dinero está en juego. Perder dos clientes con cuotas diferentes produce la misma pérdida de dos personas, pero no necesariamente el mismo efecto económico. Por eso conviene acompañar el análisis con deuda pendiente, importes recuperados y valor recurrente perdido, cada uno con su propia definición.
No sumes el importe de cada intento para calcular deuda. Si una cuota de 50 € falla tres veces, la obligación sigue siendo de 50 €, salvo otros conceptos válidos que deban analizarse aparte. Los intentos describen actividad operativa; multiplicarlos por el precio de la cuota inflaría artificialmente los impagos.
Tampoco llames ingreso recuperado a un método de pago actualizado si todavía no se ha confirmado el cargo pendiente. Conserva la referencia de la obligación y del resultado. Si después hay una devolución, refleja su efecto según el criterio de tu informe en lugar de dejar dos versiones incompatibles de la misma recuperación.
6. Investiga causas sin culpar al cliente
Agrupa las incidencias según la evidencia disponible: método que requiere actualización, fallo ordinario de pago, problema del comercio, resultado incierto u otra causa revisada. No atribuyas todos los fallos a falta de fondos. Una configuración del comercio puede impedir la operación aunque el cliente quiera seguir y su tarjeta sea válida.
Revisa si el aviso llegó al contacto adecuado, si el enlace seguía vigente y si existía una acción concreta para resolver la incidencia. Distingue el envío de la entrega del mensaje. Que tu sistema haya iniciado una comunicación no demuestra que el cliente haya podido leerla y actuar.
Las mejoras deben corresponder a las causas: corregir configuración, facilitar actualización segura o aclarar el procedimiento. Aumentar indiscriminadamente los reintentos no resuelve todos los problemas. Observa resultados por cohortes comparables y registra los cambios de operativa para no atribuir a una única acción una variación que puede tener varias explicaciones.
7. Relaciona el cobro con la prestación del servicio
En un SaaS o una membresía, el estado económico y el acceso al servicio deben coordinarse mediante reglas claras. PagosRecurrentes es una herramienta de cobro; la página de SaaS y membresías permite valorar ese encaje. No supone control automático de acceso, licencias o permisos.
Un estado técnico de fallo no debe convertirse por sí solo en una clasificación analítica de cliente perdido. Revisa el acuerdo, la comunicación y la situación real de la relación. Si tu negocio concede una ventana de resolución, debe ser coherente con las condiciones aplicables y con el tratamiento operativo de los casos abiertos.
El registro puede empezar con pocos campos: cliente único, cohorte, primera incidencia, causa revisada, estado final y fecha. Después añade los importes en columnas separadas. No prometas un porcentaje de recuperación sin evidencia propia: el valor del procedimiento está en conocer qué sucede y actuar con información, no en garantizar una cifra universal.
8. Checklist para un informe que puedas comparar
- Se indica si la unidad es cliente o suscripción.
- La base inicial y la ventana de observación están documentadas.
- Los intentos múltiples se agrupan por cliente y obligación.
- Las bajas voluntarias no se mezclan con pérdidas por pago.
- Los casos abiertos e inciertos siguen visibles.
- Numerador y denominador pertenecen a la misma población.
- Los importes se calculan sin multiplicar deuda por intentos.
- Se registran cambios de criterio y de procedimiento.
Repite el informe con la misma definición y revisa los casos que cambian de estado. Si corriges una clasificación, conserva la razón y la fecha. La comparación gana utilidad cuando puedes explicar no solo que una tasa subió o bajó, sino qué clientes y qué hechos están detrás de ese movimiento.
Preguntas frecuentes
¿Un pago fallido ya cuenta como churn involuntario?
No necesariamente. Puede ser una incidencia recuperable o un resultado pendiente de aclarar. Define qué confirma la pérdida de la relación y mantén los casos abiertos separados hasta que exista evidencia suficiente para clasificarlos.
¿Tres intentos fallidos son tres clientes perdidos?
No. Si pertenecen al mismo cliente, se cuenta una sola persona en una métrica de clientes. Los intentos pueden medirse aparte para analizar trabajo operativo, pero no deben sustituir la unidad de la tasa de pérdida.
¿Cómo trato a un cliente con varias suscripciones?
Decide si el informe mide clientes o suscripciones. Si mide clientes, usa su identificador único y define cuándo consideras terminada la relación. Mantén la misma unidad en el numerador, el denominador y las comparaciones posteriores.
¿Puedo asegurar que recuperaré un porcentaje concreto?
No sin evidencia suficiente de tu operativa y una definición comparable. Los ejemplos de esta guía son ficticios. La recuperación depende de las causas, de las acciones y del tiempo de observación, entre otros factores.
¿Actualizar la tarjeta equivale a recuperar ingresos?
No. Debes comprobar el cobro pendiente y su resultado. Preparar un método válido es un paso operativo; recuperar dinero exige una operación confirmada y correctamente relacionada con la obligación, considerando después posibles devoluciones.
Revisa dónde se interrumpe tu cobro recurrente
Examina cómo registras fallos, actualizaciones y resultados antes de interpretar tus bajas. Podemos revisar el encaje de PagosRecurrentes con tu operativa de suscripciones y membresías digitales.