Cómo diseñar alertas de cobro proactivas

Hace poco me reuní con un cliente que tenía un problema importante con sus cobranzas. Esta empresa atiende a clientes en distintos países, entonces cobra en varias monedas, pero ese no era el problema principal. La empresa vende un sistema por suscripción y acepta pagos por transferencia bancaria, con facturas a plazos de 1, 3, 6 y 12 meses.

El problema real de los distintos plazos

Cuando tienes un solo plazo de vencimiento es más fácil manejar las renovaciones. Por eso muchas empresas intentan tener ciclos de facturación cerrados, como el día 1 de cada mes, porque si no terminas monitoreando el día 2, el 3, el 4… y así sucesivamente. Pero la realidad es que muchas veces tienes que ser flexible con el cliente, porque esa flexibilidad facilita la venta.

El tema se complica más cuando tienes renovaciones que no son solo mensuales, sino trimestrales, semestrales o anuales, y tienes que hacerles seguimiento a todas por igual.

En el caso de este cliente, tiene más de cuatro plazos corriendo al mismo tiempo, cada uno con su propia fecha de vencimiento, sobre una base de clientes que crece constantemente.

Un cliente que factura a 1 mes vence todos los meses. Otro que factura a 12 meses vence una vez al año. Llevar esas fechas en la cabeza, o en una hoja de cálculo que alguien tiene que revisar todos los días, es donde se cae el sistema.

Por qué la transferencia se complica más con plazos mezclados

Con tarjeta de crédito, el cobro es automático. Se ejecuta o falla, y el sistema ya sabe qué pasó.

Con transferencia, alguien tiene que enterarse de que el dinero llegó, conciliarlo contra la factura correcta, y si no llegó, escribirle al cliente.

Cuando todos los clientes tienen el mismo plazo, ese seguimiento es manejable. Cuando cada uno vence en un momento distinto según su plan, el equipo termina reaccionando a lo que se le cruza, no siguiendo un calendario real.

Distintos estudios de automatización de cobranza en 2026 muestran reducciones de entre 15% y 30% en días promedio de cobro cuando ese seguimiento deja de ser manual. La ganancia no viene de cobrar más rápido por arte de magia, viene de dejar de depender de que alguien se acuerde de revisar.

La propuesta: un sistema proactivo, no reactivo

Lo que le propuse no es esperar a que la factura venza para reaccionar. Es avisar antes de que eso pase.

Las reglas que armé son simples de leer, aunque no triviales de mapear bien.

Tres días antes del vencimiento, un primer aviso.

El mismo día del vencimiento, un segundo aviso.

Si ya venció y sigue sin pago, recordatorios diarios.

Como este cliente vende un sistema por suscripción, la propuesta incluye una regla adicional: si pasan 7 días de incumplimiento, el acceso se puede suspender automáticamente. No es un castigo, es la consecuencia lógica de un servicio que se paga para seguir activo.

Y si quiere ser más estricto, puede sumar una tarifa de reconexión, dependiendo del tipo de negocio.

Avisos internos vs. externos: cuándo usar cada uno

Personalmente, prefiero los avisos internos. Le llegan al equipo encargado de la cobranza, y ellos deciden cómo y cuándo escribirle al cliente. El mensaje sale más personalizado, más cercano, no se siente a bot.

Pero cuando el volumen de cobros ya es grande, los avisos externos, que le llegan directo al cliente sin pasar por una persona, se vuelven necesarios. No porque sean mejores, sino porque no hay forma de que un equipo humano llegue a tiempo a cada caso cuando la escala crece.

La secuencia lógica no es elegir uno u otro. Es empezar con avisos internos mientras el volumen es manejable, y sumar avisos externos como capa adicional cuando el equipo ya no da abasto.

Lo que sostiene todo esto: centralización, no solo alertas

Ninguna de estas reglas funciona si las fechas de cada cliente viven en lugares distintos.

Antes de las alertas, la propuesta parte de centralizar cada factura, con su plazo, su moneda y su método de cobro, en una sola fuente. Recién ahí las reglas de aviso se pueden aplicar al cliente correcto, en el momento correcto, sin depender de que alguien lo revise a mano.

El stack técnico: un sistema y un agente de alertas

La manera más práctica de resolver esto es con un sistema web simple. Lo armo en HTML, con login de usuarios por seguridad y una base de datos que centralice toda la información de facturas.

Para tener buen control y seguridad, manejo el código en un repositorio de GitHub conectado a Netlify para el hosting, y uso Supabase para el login y la base de datos. Todo esto lo construyo con Claude Code.

El agente de alertas también lo hago con Claude Code, pero en vez de correrlo en un servidor aparte, lo dejo como una función programada dentro de Netlify o de Supabase, que revisa la base de datos todos los días y dispara los avisos según la regla que corresponda. Esa es la parte que simplifica todo: no hay que levantar ni pagar un servidor extra solo para que algo se ejecute una vez al día.

La integración empieza por correo electrónico, que es la más simple de conectar. Recién cuando el cliente quiera mandar alertas externas directas, conectaría WhatsApp, que es más compleja y más cara de mantener.

Si te gustaron estos casos de uso, sígueme en Substack. Y si quieres que te ayude a implementar este stack técnico, escríbeme por WhatsApp.