Dunning: cómo recuperar pagos fallidos (la palanca olvidada de revenue)

En cualquier SaaS con cobro recurrente, entre 5% y 10% de los pagos mensuales fallan. Las razones son siempre las mismas:

• Tarjeta de crédito expirada.
• Límite de tarjeta alcanzado.
• Fraude detectado por banco emisor (especialmente en pagos internacionales).
• Insuficiencia de fondos.
• Tarjeta cancelada o reportada como robada.

Sin dunning (proceso sistemático de recuperación), el 40-60% de esos pagos nunca se recuperan. El cliente queda inactivo, te culpa a ti ("se les rompió el cobro"), nunca vuelve y deja review negativo. Pérdida silenciosa de revenue + churn involuntario.

Cuantificación de impacto:

SaaS con MRR USD 50.000 y 5% de pagos que fallan = USD 2.500/mes en pagos fallidos. Sin dunning: USD 1.000-1.500/mes perdidos para siempre. Sumando 12 meses: USD 12.000-18.000/año de revenue perdido evitable.

Con dunning bien implementado: recuperar 70-85% de pagos fallidos. Solo 15-30% se pierde. Diferencia anual para el mismo SaaS: USD 8.000-12.000/año adicionales en revenue recuperado.

Es una de las palancas con mejor ROI en SaaS y la más infrautilizada. La mayoría de las PYMEs simplemente no tiene dunning serio.

1. Tarjeta expirada (40-50% de los fallos).

La razón más común. El cliente actualizó la tarjeta pero no la reportó al SaaS.

Manejo: - Stripe Adaptive Acceptance: pasa los detalles al banco emisor que puede actualizar automáticamente la tarjeta. Recupera 30-50% de estos casos sin intervención. - Para los que no se recuperan: email automatizado al cliente con CTA directo para actualizar tarjeta. Tasa de respuesta típica: 60-80%.

2. Límite alcanzado (15-25% de los fallos).

Más común a fin de mes. La tarjeta tiene fondos pero ya alcanzó límite mensual.

Manejo: - Smart retry: reintentar 3-7 días después (no inmediatamente). El límite probablemente se reseteó. - Si falla 2 veces más: email al cliente sugiriendo tarjeta alternativa.

3. Fraude detectado por banco (15-20% de los fallos).

Especialmente en pagos internacionales. El banco bloquea por seguridad.

Manejo: - Email al cliente avisando que el banco bloqueó el pago y que debe contactarlos. - Reintentar después de 24-48h por si el cliente desbloqueó. - En pagos cross-border, considerar opciones locales de pago (Mercado Pago, ePay) para evitar este problema sistémicamente.

4. Fondos insuficientes (10-15% de los fallos).

Debito o tarjeta prepaga sin fondos.

Manejo: - Smart retry 3-5 días después (típicamente coincide con día de pago del cliente). - Si falla 2-3 veces: email ofreciendo plan de menor precio (downsell) en lugar de churn.

5. Tarjeta cancelada/robada (5-10% de los fallos).

El cliente reportó la tarjeta pero no actualizó su SaaS.

Manejo: - Email inmediato al cliente avisando que la tarjeta no responde. - Idealmente con link directo al portal de billing para actualizar. - Si no responde en 7 días: pausa temporal de servicio + comunicación más urgente.

Stack típico de manejo: - Stripe Smart Retries (gratis, incluido en Stripe) maneja el 60-70% de los casos automáticamente. - Herramienta dedicada de dunning (Churnkey, Stunning, Recover) maneja el otro 30-40% con personalización avanzada.

El timing de los reintentos es la palanca más importante en recuperación automática. Reintentar en momento equivocado significa quemar oportunidades y posiblemente reactivar bloqueos del banco.

Pattern de retry recomendado (probado en data agregada de Stripe y Churnkey):

Día 0: intento original. Falla. NO reintentar inmediatamente.

Día 1-3: reintento 1. - Mejor día: día siguiente al payday del cliente (típicamente día 1-5 o 15-20 del mes). - Stripe Smart Retries hace esto automáticamente, ajustando según historial.

Día 5-7: reintento 2 si falló el 1. - Día de la semana óptimo: martes/miércoles (mejor approval rates en data agregada). - Hora óptima: 10am-2pm hora local del cliente.

Día 10-14: reintento 3 si falló el 2. - Considerar bajar el monto si es un descuento prorrateado o si tiene sentido.

Día 15-21: último reintento + comunicación intensiva al cliente. - Email, SMS, push notification, todos los canales. - Si falla: cliente se baja del servicio (con email final de win-back).

Por qué este timing funciona:

• No reintentar inmediatamente evita re-trigger del bloqueo del banco.
• Esperar 1-3 días permite que el cliente solucione automáticamente (paga otra cuenta, recibe sueldo).
• Distribuir intentos en 21 días maximiza chances de coincidir con un día donde el pago pasa.
• Día de la semana y hora importan estadísticamente: mejor de martes a jueves, peor sábado y domingo.

Cómo implementarlo:

• Stripe Smart Retries (gratis con Stripe): activado por default, ajusta automáticamente.
• Para control más fino: Churnkey (USD 49+/mes), Stunning (USD 30+/mes), o Recover (USD 79+/mes). Tienen UI para configurar exact retry timing.
• Para desarrollo custom: webhook de invoice.payment_failed + scheduler que dispara retries según pattern.

Cuando el pago falla, el email genérico tipo "hubo un problema, actualiza tu tarjeta" tiene tasa de click de 15-25%. Email personalizado según razón probable del fallo: 40-60%. Diferencia enorme con poco esfuerzo.

Personalización por razón de fallo:

Si falló por tarjeta expirada: ``` Asunto: Tu tarjeta probablemente venció

Hola [Nombre],

Intentamos procesar tu pago de [Producto] hoy y el banco no lo aceptó. Es probable que tu tarjeta haya vencido este mes.

Actualiza tu método de pago en 1 clic: [Link directo al portal de billing]

Mientras tanto, tu cuenta sigue activa por 7 días. ```

Si falló por fondos insuficientes: ``` Asunto: No pudimos procesar tu pago hoy

Hola [Nombre],

Intentamos cobrar [monto] hoy y el banco indicó que no había fondos disponibles. Reintentaremos automáticamente en 3 días.

Si prefieres usar otra tarjeta, actualiza acá: [Link] O si quieres pasar a un plan menor temporalmente: [Link al downgrade] ```

Si falló por fraude detectado: ``` Asunto: Tu banco bloqueó el pago a [Producto]

Hola [Nombre],

Intentamos procesar tu pago y tu banco lo marcó como inusual y lo bloqueó. Esto pasa a veces con pagos internacionales o recurrentes.

Qué hacer: 1. Contactá a tu banco y autorizá pagos a [Producto/Stripe]. 2. Una vez autorizado, reintentaremos en 24h automáticamente.

Tu cuenta sigue activa mientras resuelves esto. ```

Elementos clave de la comunicación:

1. Subject específico, no genérico. "Tu tarjeta probablemente venció" gana sobre "Problema con tu pago". 2. Razón específica del fallo, no abstracta. Reduce ansiedad del cliente y le dice qué hacer. 3. Link directo al portal de billing. Un solo clic para resolver, no 5 navegaciones. 4. Información de qué pasa con el servicio. ¿Sigue activo? ¿Cuándo se pausa? Sin esto, el cliente se enoja. 5. Tono empático, no acusatorio. El cliente no tiene culpa de que la tarjeta venciera; tratarlo como negligencia genera bronca.

Multi-canal cuando el email no funciona:

• SMS para clientes B2C (tasa de open 95% vs email 30%).
• WhatsApp en LATAM (especialmente Brasil, México, Argentina).
• Notification dentro del producto (in-app banner).
• Llamada para clientes B2B de alto ticket (manual, solo para tickets >USD 500/mes).

Herramientas como Churnkey y Stunning automatizan multi-canal sin código adicional.

Email 1 - Día del fallo:

Subject: Tu pago no se procesó hoy. Objetivo: alertar sin asustar. Comunicar que se reintentará automáticamente. CTA: actualizar método de pago si saben que tiene problema. Mensaje clave: "Tu cuenta sigue activa, vamos a reintentar automáticamente".

Tasa típica de click + resolución: 20-30% recupera en este email.

Email 2 - Día 3 después del fallo:

Subject: Pagos sigue pendiente — necesitamos tu ayuda. Objetivo: tono más activo. El cliente debe hacer algo. CTA: actualizar tarjeta + opción de usar otro método. Mensaje clave: "Tu servicio se pausará en X días si no se resuelve".

Tasa típica: 15-25% adicional.

Email 3 - Día 7:

Subject: Tu servicio se pausará el [fecha]. Objetivo: urgencia real. Última chance antes de pausar. CTA: actualizar tarjeta + soporte humano disponible. Mensaje clave: contacto directo a soporte si hay problema, no quedarse callado.

Tasa típica: 10-15% adicional.

Email 4 - Día 10-12 (servicio pausado):

Subject: Tu cuenta de [Producto] está pausada. Objetivo: notificar pausa. Comunicar qué se pierde mientras esté pausada. CTA: reactivar con tarjeta nueva. Mensaje clave: data preservada (loss aversion del trabajo invertido).

Tasa típica: 5-10% adicional.

Email 5 - Día 21-30 (win-back):

Subject: ¿Querés mantener tu cuenta? Objetivo: última comunicación antes de cierre definitivo. CTA: reactivar con descuento opcional (10-20%) o pausa de suscripción. Mensaje clave: ofrecer flexibilidad para retener.

Tasa típica: 3-7% adicional.

Total recuperación con secuencia bien implementada: 55-85% de pagos fallidos.

Reglas de la secuencia:

1. Cada email debe sentirse distinto. No el mismo template con detalles cambiados. 2. Tono progresivo: empático → urgente → última chance → cierre. No agresivo desde el inicio. 3. Multi-canal en emails 3-5. Email + SMS si es B2C, email + WhatsApp si es LATAM. 4. Frenar la secuencia inmediatamente cuando se recupera el pago. Seguir mandando emails post-recuperación es señal de sistema mal implementado y enoja al cliente.

Cuando ya cerraste la suscripción del cliente por dunning fallido, todavía hay revenue recuperable. La secuencia de win-back se ejecuta en los 30-90 días post-cierre y recupera 5-15% adicional.

Secuencia de win-back de 4 emails:

Email 1 - Día 1 post-cierre:

Subject: Tu cuenta de [Producto] se cerró — ¿podemos ayudarte? Mensaje: empático, asume buena fe, ofrece soporte si fue problema técnico que no detectaron. CTA: reactivar con asistencia humana.

Email 2 - Día 15:

Subject: Te extrañamos en [Producto]. Mensaje: caso de éxito de cliente similar, recordatorio de valor que el ex-cliente ya conoce, oferta de retorno (mismo plan, mismo precio). CTA: volver con 1 clic.

Email 3 - Día 30:

Subject: 20% de descuento si volvés en los próximos 7 días. Mensaje: incentivo concreto para retorno. Solo en este email; antes no. CTA: reactivar con descuento.

Email 4 - Día 60-90:

Subject: Última oportunidad: ¿hay algo en lo que podamos ayudarte? Mensaje: pregunta directa por la razón de no retorno, ofrece ayuda concreta. CTA: reactivar o responder al email con feedback.

Tasas típicas de recuperación win-back:

• Email 1: 1-3% recupera con asistencia.
• Email 2: 1-3% con recordatorio.
• Email 3: 3-7% con descuento.
• Email 4: 1-2% con outreach personal.

Total: 5-15% de los cierres por dunning se recuperan en 60-90 días.

Reglas críticas:

1. Diferenciar win-back post-dunning de win-back post-cancelación voluntaria. Son secuencias distintas: post-dunning enfocás en problema técnico, post-cancelación voluntaria en superar objeción real.

2. No usar el mismo descuento para todos. Si todos los churned reciben 20%, los clientes aprenden a cancelar para conseguir descuento. Mejor: 20% solo para win-back post-dunning, 10% (o nada) para post-cancelación voluntaria.

3. Cerrar la secuencia después de 90 días sin respuesta. Más allá de eso, los emails son spam.

4. Crear cuenta nueva al volver, no resucitar la vieja. La data del cliente puede haberse purgado, los precios pueden haber cambiado. Mejor empezar desde cero con contexto importado.

Stack recomendado para win-back: secuencia configurada en GoHighLevel o en plataforma de email transaccional (Resend, SendGrid). Trigger: tag 'churned-dunning' en CRM. Sin tooling especial, simplemente workflow bien configurado.

1. Pago Recovery Rate. Definición: % de pagos fallidos que se recuperan dentro de 30 días. Benchmark saludable: 70-85% con sistema bien implementado. Menor a 50%: dunning no funciona, hay problema crítico.

2. Time to Recovery. Definición: días promedio desde fallo hasta recuperación. Benchmark: 3-7 días para la mayoría de los pagos recuperables. Mayor a 14 días: secuencia de comunicación es lenta o ineficiente.

3. Distribución por razón de fallo. Definición: % de fallos por cada causa (tarjeta vencida, fondos, fraude, etc). Utilidad: identificar oportunidades sistémicas. Si 60% es fraude internacional, considerar opciones de pago locales.

4. Involuntary Churn Rate. Definición: % de clientes que se baja por pagos fallidos no recuperados, dividido por total de clientes. Benchmark: <2% mensual. Mayor a 4%: dunning falla y debería ser prioridad.

5. Win-back Rate (post-dunning). Definición: % de clientes cerrados por dunning fallido que se recuperan en 60-90 días. Benchmark: 5-15% con secuencia de win-back bien implementada.

6. Revenue Recovered. Definición: USD recuperados por el sistema de dunning cada mes. Forma de calcular ROI del sistema: revenue recuperado vs costo del stack (Stripe Smart Retries gratis + Churnkey ~USD 100/mes = costo bajo).

Dashboard recomendado: mostrar las 6 métricas mensualmente. Revisar con CFO o fundador. Cuando recovery rate cae de su benchmark, investigar inmediatamente: hay algo roto en la secuencia o en el procesador de pagos.

ROI típico del sistema completo:

SaaS con MRR USD 50.000, 5% pagos fallidos = USD 2.500/mes en pagos en riesgo. Sin dunning: 40% recuperado = USD 1.000/mes. Con dunning serio: 80% recuperado = USD 2.000/mes. Delta: USD 1.000/mes adicionales recuperados. Costo del sistema: USD 100/mes (Churnkey o equivalente). ROI neto: 900%/mes. Una de las palancas con mejor ROI en SaaS.