--- title: "Caída del correo: reanudar los recordatorios sin enviar todo el retraso de golpe" canonical: https://www.billabex.com/es/blog/caida-del-correo-reanudar-recordatorios-sin-enviar-todo-el-retraso/ lang: es alternate: https://www.billabex.com/fr/blog/panne-messagerie-reprise-relances.md alternates: fr: https://www.billabex.com/fr/blog/panne-messagerie-reprise-relances.md en: https://www.billabex.com/en/blog/email-outage-resuming-reminders.md es: https://www.billabex.com/es/blog/caida-del-correo-reanudar-recordatorios-sin-enviar-todo-el-retraso.md updated: 2026-11-03 index: https://www.billabex.com/llms.txt --- # Caída del correo: reanudar los recordatorios sin enviar todo el retraso de golpe El correo vuelve, el indicador se pone en verde y sesenta recordatorios esperan. El reflejo es vaciar la cola para recuperar una jornada normal. Sin embargo, durante la interrupción, algunos clientes han pagado, algunos comerciales han respondido por teléfono y ciertas promesas se han renegociado. Que el canal esté disponible no hace que los mensajes antiguos vuelvan a ser pertinentes. Una reanudación correcta concilia dos historias: la del transporte de los correos y la de los expedientes de los clientes. La primera indica lo que pudo salir; la segunda indica lo que todavía hay que pedir. Confundirlas produce duplicados, importes obsoletos y reproches injustificados. Esta es una propuesta de método de reanudación para un equipo de cobros B2B, con una simulación explícita y puntos que verificar con el proveedor. ## Identificar qué se interrumpió realmente Una pantalla inaccesible, una sincronización bloqueada y un servidor de envío no disponible no describen la misma caída. En el primer caso, los mensajes pueden seguir saliendo. En el segundo, los saldos pueden envejecer aunque el canal funcione. En el tercero, el proveedor puede conservar correos ya aceptados e intentar transmitirlos más tarde. La RFC 5321, sección 4.5.4.1, prevé precisamente reintentos de transmisión SMTP. Indica un intervalo generalmente de al menos **30 minutos** entre intentos y una duración antes de abandonar generalmente de al menos **4 a 5 días**, con parámetros configurables y adaptaciones posibles. Estas cifras describen el transporte técnico; no constituyen una cadencia de recordatorios al cliente ni un compromiso de su proveedor. [Fuente: RFC 5321](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.5.4.1). Pida, pues, al soporte el perímetro afectado, la última operación confirmada y el destino de los mensajes aceptados. Un correo ausente de la interfaz puede seguir en una cola remota. Volver a crear de inmediato el mismo recordatorio desde otro buzón añade una segunda acción sin resolver esa incertidumbre. ## Separar los mensajes antiguos de las nuevas decisiones Conserve una fotografía del atraso acumulado con el identificador del expediente, el destinatario, la fecha prevista, el importe utilizado y el estado técnico conocido. Tres situaciones requieren tratamientos distintos: un borrador nunca enviado al proveedor, un mensaje enviado cuyo resultado es incierto y un mensaje rechazado expresamente. La fecha prevista por sí sola no permite elegir entre ellas. Para las operaciones inciertas, concilie las trazas del proveedor antes de crear un nuevo envío. Para los borradores que siguen bajo su control, vuelva a validar el expediente. Para los rechazos, examine el motivo: una dirección no válida no pasa a ser correcta porque el incidente general haya terminado. El control de los [duplicados al repetirse una importación](https://www.billabex.com/es/blog/importacion-repetida-no-debe-duplicar-recordatorios-probar-duplicados/) completa esta distinción, sin sustituir el análisis del transporte. No borre las acciones antiguas para obtener un contador limpio. Marque las que se anulan, se sustituyen o hay que investigar, con su motivo. Un recordatorio que ha dejado de ser útil sigue siéndolo en el historial: explica por qué no se ejecutó la planificación inicial. ## Actualizar los expedientes antes de redactar de nuevo El orden de reanudación propuesto es sencillo: recuperar los pagos, integrar los abonos, leer las respuestas recibidas y verificar después los compromisos registrados en otros sitios. También hay que confirmar que esos flujos han recuperado realmente su retraso. Una sincronización declarada terminada sin control del periodo cubierto no basta. El caso de un [retraso de sincronización contable](https://www.billabex.com/es/blog/sincronizacion-contable-retrasada-cuando-suspender-recordatorios/) muestra por qué un saldo visible puede ser técnicamente accesible pero demasiado antiguo para reclamar. Durante la reanudación, documente una hora de referencia común. Si el banco está al día hasta la mañana y el correo solo hasta el día anterior, esa diferencia debe seguir siendo visible. Una promesa de pago no salda el crédito. Puede, no obstante, modificar la siguiente acción y volver inadecuada una fórmula que afirme que el cliente nunca ha respondido. A la inversa, un pago recibido e imputado reduce realmente el importe reclamado. Tratar estos hechos por separado evita convertir toda respuesta en un pago o toda ausencia de conciliación en un rechazo. ## Simulación: sesenta acciones se convierten en veinticinco contactos Tomemos un caso totalmente ficticio. Las **60 acciones** son borradores nunca enviados al proveedor; su estado técnico está confirmado. Los grupos siguientes son disjuntos. Quince corresponden a créditos íntegramente pagados durante la caída. Diez dejan de ser útiles porque una respuesta impone ahora un tratamiento del expediente. Cinco quedan suspendidas por una excepción que requiere arbitraje. Quedan, por tanto, **60 − 15 − 10 − 5 = 30 acciones** potencialmente pertinentes. Corresponden a veinticinco cuentas de clientes: cinco cuentas tienen cada una dos borradores y las otras veinte uno solo. Tras agrupar de forma coherente por cliente, el equipo prepara **25 contactos**, sin mezclar entidades jurídicas distintas. El paso de 60 a 25 supone un **58,3 % menos de contactos** respecto al envío a ciegas de los sesenta borradores. Este porcentaje es el de la simulación, no una mejora observada en Billabex. Los diez expedientes con respuesta y las cinco excepciones deben tratarse de otro modo; no han desaparecido de la cartera. Si dos clientes más pagan antes del segundo lote, sus contactos también se retiran. La cifra de veinticinco era una decisión en un momento dado, no una cuota que alcanzar a toda costa. Precisamente por eso la revalidación debe producirse lo más cerca posible del envío. ## Reanudar de forma progresiva sin inventar una cadencia universal Una reanudación por lotes permite verificar el resultado antes de exponer toda la cartera. El tamaño depende de la capacidad real del proveedor, del volumen de respuestas que el equipo pueda absorber y de los horarios acordados con los clientes. Un lote piloto de cinco expedientes puede ser una elección interna; no es una norma ni una garantía de seguridad. Amazon explica que los intentos simultáneos pueden amplificar una sobrecarga y que escalonarlos reduce los picos. Esta observación se refiere a los sistemas distribuidos. De ella extraemos aquí una regla de organización: coordinar la reanudación con el proveedor y evitar los reinicios concurrentes de varios equipos. [Fuente: Amazon Builders' Library, 2019](https://d1.awsstatic.com/builderslibrary/pdfs/timeouts-retries-and-backoff-with-jitter.pdf). Designe a una persona que autorice la ampliación y una condición de parada: resultado técnico incierto, importe incoherente o respuesta no integrada. Un incidente descubierto en el lote piloto debe impedir las mismas acciones en el resto del perímetro. Las [excepciones confiadas a una persona](https://www.billabex.com/es/blog/agente-ia-cobros-que-excepciones-confiar-a-una-persona/) siguen siendo prioritarias, incluso cuando el retraso operativo aumenta. ## Probar también la restauración y la continuidad del trabajo Una copia de seguridad restaura un estado anterior; no garantiza que los hechos ocurridos después figuren en ella. Si la herramienta vuelve a una copia del día anterior, concilie los pagos, las respuestas y los envíos producidos desde esa copia antes de reactivar los automatismos. De lo contrario, una restauración técnicamente exitosa puede producir recordatorios ya ejecutados. La CNIL recomienda probar periódicamente la integridad de las copias de seguridad y su restauración, así como proteger las copias al mismo nivel que los datos en uso. Esto justifica un ejercicio de reanudación documentado, sin constituir una prescripción de cadencia comercial. [Fuente: CNIL, 14 de marzo de 2024](https://www.cnil.fr/fr/securite-sauvegarder). Termine el ejercicio con una conciliación: borradores anulados, mensajes cuyo transporte está confirmado, expedientes suspendidos y nuevas acciones autorizadas. Cada línea debe tener un responsable y un siguiente paso. Para evaluar un [software de cobros](https://www.billabex.com/es/software-de-cobros/), pida una demostración de esta reanudación con expedientes ficticios. Una prueba superada demuestra por qué cada mensaje sigue siendo necesario en el momento en que sale, y no solo que la cola puede vaciarse. ## Fuentes - RFC 5321, octubre de 2008, secciones 4.5.3.2.6 y 4.5.4.1: [transporte SMTP y reintentos](https://www.rfc-editor.org/rfc/rfc5321.html). - Amazon Builders' Library, Marc Brooker, 2019: [timeouts, retries and backoff](https://d1.awsstatic.com/builderslibrary/pdfs/timeouts-retries-and-backoff-with-jitter.pdf). - CNIL, 14 de marzo de 2024: [guardar copias de seguridad y probar la restauración](https://www.cnil.fr/fr/securite-sauvegarder).