---
title: "Avaria no correio eletrónico: retomar os lembretes sem enviar tudo de uma vez"
canonical: https://www.billabex.com/pt/blog/avaria-correio-eletronico-retomar-lembretes/
lang: pt
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
  de: https://www.billabex.com/de/blog/e-mail-ausfall-mahnungen-wieder-aufnehmen.md
  es: https://www.billabex.com/es/blog/caida-del-correo-reanudar-recordatorios-sin-enviar-todo-el-retraso.md
  it: https://www.billabex.com/it/blog/guasto-posta-elettronica-riprendere-solleciti.md
  nl: https://www.billabex.com/nl/blog/e-mailstoring-betalingsherinneringen-hervatten.md
  pl: https://www.billabex.com/pl/blog/awaria-poczty-wznowienie-przypomnien.md
  pt: https://www.billabex.com/pt/blog/avaria-correio-eletronico-retomar-lembretes.md
updated: 2026-11-03
index: https://www.billabex.com/llms.txt
---

# Avaria no correio eletrónico: retomar os lembretes sem enviar tudo de uma vez

O correio eletrónico volta a funcionar, o indicador passa a verde e estão sessenta lembretes à espera. O reflexo é esvaziar a fila para regressar a um dia normal. No entanto, durante a interrupção, alguns clientes pagaram, os comerciais atenderam chamadas e certas promessas foram renegociadas. A disponibilidade do canal não torna as mensagens antigas novamente pertinentes.

Uma retoma correta concilia duas histórias: a do transporte dos emails e a dos processos de clientes. A primeira indica o que pode ter sido enviado; a segunda indica o que ainda é necessário pedir. Confundi-las produz duplicados, montantes desatualizados e censuras injustificadas. Segue-se um método de retoma proposto para uma equipa de cobranças B2B, com uma simulação explícita e pontos a verificar junto do fornecedor.

## Identificar o que foi realmente interrompido

Um ecrã inacessível, uma sincronização bloqueada e um servidor de envio indisponível não descrevem a mesma avaria. No primeiro caso, as mensagens podem continuar a ser enviadas. No segundo, os saldos podem ficar desatualizados enquanto o canal funciona. No terceiro, o fornecedor pode conservar emails já aceites e tentar transmiti-los mais tarde.

A RFC 5321, secção 4.5.4.1, prevê precisamente novas tentativas de transmissão SMTP. Indica um intervalo geralmente de, pelo menos, **30 minutos** entre tentativas e um prazo até à desistência geralmente de, pelo menos, **4 a 5 dias**, com parâmetros configuráveis e adaptações possíveis. Estes números descrevem o transporte técnico; não constituem uma cadência de lembretes ao cliente nem um compromisso do seu prestador. A fonte é a RFC 5321.

Peça, por isso, ao apoio técnico o âmbito afetado, a última operação confirmada e o destino das mensagens aceites. Um email ausente da interface pode ainda estar numa fila remota. Recriar imediatamente o mesmo lembrete a partir de outra caixa acrescenta uma segunda ação sem resolver essa incerteza.

## Separar as mensagens antigas das novas decisões

Conserve um retrato da lista pendente com o identificador do processo, destinatário, data prevista, montante utilizado e estado técnico conhecido. Três situações exigem tratamentos diferentes: um rascunho nunca submetido, uma mensagem submetida cujo resultado é incerto e uma mensagem explicitamente rejeitada. A data prevista, por si só, não permite escolher entre elas.

Para as operações incertas, confronte os registos do fornecedor antes de criar um novo envio. Para os rascunhos ainda sob o seu controlo, revalide o processo. Para as rejeições, analise o motivo: um endereço inválido não se torna correto porque o incidente geral terminou. O controlo dos [duplicados na repetição de uma importação](https://www.billabex.com/pt/blog/importacao-repetida-duplicados-lembretes/) complementa esta distinção, sem substituir a análise do transporte.

Não apague as ações antigas para obter um contador limpo. Assinale as que são anuladas, substituídas ou ficam por investigar, com o respetivo motivo. Um lembrete que deixou de ser necessário continua útil no histórico: explica por que motivo o planeamento inicial não foi executado.

## Atualizar os processos antes de voltar a redigir

A ordem de retoma proposta é simples: recuperar os pagamentos, integrar as notas de crédito, ler as respostas recebidas e depois verificar os compromissos registados noutro local. É também necessário confirmar que estes fluxos recuperaram efetivamente o atraso. Não basta declarar uma sincronização concluída sem verificar o período que abrange.

O caso de um [atraso na sincronização contabilística](https://www.billabex.com/pt/blog/sincronizacao-contabilistica-atrasada-suspender-lembretes/) mostra por que motivo um saldo visível pode estar tecnicamente acessível, mas demasiado antigo para enviar um lembrete. Durante a retoma, documente uma hora de referência comum. Se o banco estiver atualizado até à manhã e o correio eletrónico apenas até à véspera, essa diferença deve continuar visível.

Uma promessa de pagamento não liquida o crédito. Pode, contudo, alterar a próxima ação e tornar inadequada uma formulação que afirme que o cliente nunca respondeu. Inversamente, um pagamento recebido e imputado reduz efetivamente o montante exigido. Tratar estes acontecimentos separadamente evita transformar qualquer resposta num pagamento ou qualquer falta de conciliação numa recusa.

## Simulação: sessenta ações passam a vinte e cinco contactos

Consideremos um caso inteiramente fictício. As **60 ações** são rascunhos nunca submetidos ao fornecedor; o seu estado técnico está confirmado. Os grupos seguintes não se sobrepõem. Quinze dizem respeito a créditos integralmente pagos durante a avaria. Dez deixam de ser necessárias porque uma resposta exige agora o tratamento do processo. Cinco são suspensas por uma exceção que exige decisão.

Restam, portanto, **60 − 15 − 10 − 5 = 30 ações** potencialmente pertinentes. Dizem respeito a vinte e cinco contas de clientes: cinco contas têm dois rascunhos cada uma e as outras vinte têm apenas um. Depois de um agrupamento coerente por cliente, a equipa prepara **25 contactos**, sem misturar entidades jurídicas distintas.

A passagem de 60 para 25 representa **58,3 % menos contactos** relativamente ao envio cego dos sessenta rascunhos. Esta percentagem pertence à simulação, não é um ganho observado no Billabex. Os dez processos com resposta e as cinco exceções continuam a exigir outro tratamento; não desapareceram da carteira.

Se dois clientes adicionais pagarem antes do segundo lote, os respetivos contactos também são retirados. O número de vinte e cinco era uma decisão num determinado momento, não uma quota a atingir a todo o custo. É precisamente por isso que a revalidação deve ocorrer o mais perto possível do envio.

## Retomar progressivamente sem inventar uma cadência universal

Uma retoma por lotes permite verificar o resultado antes de expor toda a carteira. A dimensão depende da capacidade real do prestador, do volume de respostas que a equipa consegue absorver e dos horários acordados com os clientes. Um lote-piloto de cinco processos pode ser uma escolha interna; não é uma norma nem uma garantia de segurança.

A Amazon explica que tentativas simultâneas podem amplificar uma sobrecarga e que a sua distribuição no tempo reduz os picos. Esta observação diz respeito aos sistemas distribuídos. Retiramos daqui uma regra de organização: coordenar a retoma com o fornecedor e evitar reinícios concorrentes de várias equipas. A fonte é a Amazon Builders' Library, de 2019.

Designe uma pessoa que autorize o alargamento e uma condição de paragem: resultado técnico incerto, montante incoerente ou resposta não integrada. Um incidente descoberto no lote-piloto deve impedir as mesmas ações no resto do âmbito. As [exceções confiadas a uma pessoa](https://www.billabex.com/pt/blog/agente-ia-cobrancas-excecoes-humanas/) continuam prioritárias, mesmo quando o atraso operacional aumenta.

## Testar também o restauro e a continuidade do trabalho

Uma cópia de segurança repõe um estado anterior; não garante que os acontecimentos posteriores estejam incluídos. Se o software regressar a uma cópia da véspera, concilie os pagamentos, as respostas e os envios ocorridos desde essa cópia antes de reativar os automatismos. Caso contrário, um restauro tecnicamente bem-sucedido pode produzir lembretes já executados.

A CNIL recomenda testar regularmente a integridade das cópias de segurança e o seu restauro, bem como proteger as cópias ao mesmo nível dos dados utilizados. Isto justifica um exercício de retoma documentado, sem constituir uma prescrição de cadência comercial. A recomendação citada é de 14 de março de 2024.

Termine o exercício com uma conciliação: rascunhos anulados, mensagens cujo transporte está confirmado, processos suspensos e novas ações autorizadas. Cada linha deve ter um responsável e uma próxima etapa. Para avaliar um [software de cobranças](https://www.billabex.com/pt/software-cobrancas/), peça uma demonstração desta retoma em processos fictícios. Um teste bem-sucedido mostra por que motivo cada mensagem continua necessária no momento em que é enviada, não apenas que a fila pode ser esvaziada.

## Fontes

- RFC 5321, outubro de 2008, secções 4.5.3.2.6 e 4.5.4.1: transporte SMTP e novas tentativas.
- Amazon Builders' Library, Marc Brooker, 2019: tempos-limite, novas tentativas e espaçamento progressivo.
- CNIL, 14 de março de 2024: cópias de segurança e testes de restauro.