Start with the message that should never arrive
A customer pays an invoice in the morning and receives an overdue reminder that afternoon. They reply to explain, but another reminder arrives the following day. Each message may be politely written; together, they suggest that nobody is listening.
This illustrative situation shows why the brief for customer follow-up needs more than email templates and a sending schedule. It needs rules for deciding whether a message is still appropriate when it is about to leave.
To automate customer follow-up without spam, start with relevance, permission and clear stopping conditions. Duplicate prevention matters too, but sending an unwanted message only once does not make it useful. These controls address unnecessary contact; they do not guarantee inbox placement.
Define the purpose and permission for each sequence
Choose one recurring task that staff can already explain clearly, such as acknowledging an enquiry or reminding a customer about an approaching renewal. A narrow first workflow makes its decisions easier to review.
For each sequence, put these details in the brief:
- Purpose: What does the customer need to know or do?
- Trigger: Which recorded business event makes the message relevant?
- Recipient: Who should receive it, and where does that address come from?
- Permission: What recorded preference or customer context supports this particular contact?
- Timing and limit: When may it arrive, and how many follow-ups are allowed?
- Stop condition: Which reply, payment, cancellation or preference change ends the sequence?
- Owner: Who handles responses and exceptions?
Keep service messages and promotional sequences separately defined. For example, an enquiry acknowledgement can confirm receipt without automatically enrolling the person in a continuing sales campaign. Ask the provider how these purposes and preferences will remain distinguishable in the records.
Treat permission requirements as something to establish for your audience and chosen channel. The technical documentation cited here explains event handling and duplicate prevention; it does not establish whether your campaign has the necessary permission.
Agree which record decides whether to send
A trigger tells the workflow that something happened. It should not automatically settle whether a message belongs in the customer’s inbox now.
A webhook is a notification that one system sends to another when an event occurs. Stripe uses these notifications for events including payment confirmation and recurring payment success. Its documentation also explains that events can arrive out of order or more than once. A workflow therefore cannot safely assume that the latest notification received describes the latest customer situation. Stripe’s webhook documentation describes these delivery behaviours.
For a payment reminder, the brief should identify the authoritative invoice record. For an enquiry follow-up, it might identify the customer record containing the latest reply and assigned staff member. Ask for a fresh eligibility check before a scheduled message is released.
This decision becomes especially important when staff update another tool or record a payment manually. If that update never reaches the workflow, the automation has no basis for stopping. Ask how those changes become visible and what happens when the relevant system cannot be checked.
There is a practical tradeoff: pausing an uncertain reminder can delay useful contact, while sending it can produce an incorrect demand. Agree which outcome is preferable for each message type and who resolves uncertainty.
Prevent duplicates at both stages
There are two separate opportunities for an accidental repeat: receiving the same business event again and retrying the request to send its email.
At the event stage, Stripe recommends recording processed event identifiers so repeated deliveries do not repeat the work. It also notes that separate event objects can sometimes describe duplicates, requiring checks involving the underlying object and event type. The buyer’s question is straightforward: “How will you recognise that this business action has already been handled?” Stripe explains its duplicate-event handling recommendations.
At the sending stage, an email service may accept a request while the workflow fails to receive the response. Retrying without protection could send another message. Resend offers an idempotency key: an identifier that lets it recognise a repeated sending request and return the earlier result without sending again, within its documented 24-hour retention period. Resend’s idempotency documentation explains this protection.
That time limit matters. Stripe documents automatic live-event retries for up to three days, while Resend retains these keys for 24 hours. The design implication is that the email provider’s short-term protection alone is insufficient for every delayed replay. Ask for a workflow record of the intended message and its outcome, with a retention policy appropriate to the agreed recovery process. Stripe’s retry behaviour and Resend’s retention window support this distinction.
The identifier should also distinguish legitimate messages. A first reminder and a later approved reminder are different actions; a retry of the first reminder is the same action. Ask the provider to demonstrate both cases.
Worked example: a reminder that stops after payment
Consider an illustrative business offering an annual maintenance service. It wants a renewal notice and, if the invoice remains unpaid, one later reminder. This is a proposed workflow, not a report of company or client results.
The owner’s brief could specify the following:
| Decision | Example requirement |
|---|---|
| Entry condition | An active service has a renewal invoice ready for the named billing contact. |
| First notice | Explain the renewal, invoice reference and available next step. |
| Later reminder | Allow one reminder at an agreed interval, after checking the current invoice status. |
| Stop conditions | Payment recorded, invoice cancelled, renewal declined or staff pause applied. |
| Customer reply | Route to the responsible person and pause automated chasing pending review. |
| Uncertain status | Hold the reminder for review if the authoritative record cannot be checked. |
The provider should be able to walk through an awkward case: a reminder is already scheduled when the customer pays. The expected behaviour is to detect the updated status and suppress that reminder before sending. Agree how close-to-send changes are handled and what limitations remain.
Also inspect the message itself. It should identify the service and invoice clearly, offer a reply route and avoid language implying that staff personally reviewed the account if no such review occurred. A promotional offer added to a payment reminder deserves its own purpose and permission review.
Make timing fit the customer’s location
For a business serving India and international customers, define whose local time controls scheduled follow-ups. A sending window based on the company’s working day may be inconvenient for a customer elsewhere.
The brief should state the customer time zone where known, a fallback where it is unknown, and how date boundaries affect reminders. International scheduling should also account for daylight-saving changes where applicable. Write dates clearly and identify the currency when a message mentions an amount.
Choose channels through an explicit customer preference and an agreed business purpose. Do not assume that an email unanswered in one country should automatically trigger a message on another channel. Each added channel expands the permission, coordination and duplicate-checking work.
Ask for evidence and an operable handover
Before acceptance, request a demonstration covering a normal event, a repeated event, events arriving out of order, an uncertain sending result and a payment recorded before a queued reminder leaves. Include a customer reply and a staff pause so the test covers everyday intervention as well as technical failures.
Ask the provider:
- Can staff see why a message was sent, held or skipped?
- Can they pause one customer or the entire sequence?
- How are incoming events verified before they trigger actions?
- Who investigates failures, and what monitoring is included after handover?
- How is a failed process recovered without repeating completed messages?
- Does the business control the sending domain and provider accounts?
Keep reporting labels precise. Stripe’s successful webhook delivery means the event reached the endpoint; it does not establish that a customer received an email. Ask for reporting that distinguishes event receipt, message eligibility, sending outcome and any delivery information available from the email provider. Stripe’s delivery-status documentation explains what its endpoint status represents.
Our marketing automation service covers message and permission planning, connections to business tools, duplicate and failure checks, approved templates, reporting and handover instructions. Ongoing monitoring is agreed during review. Email setup uses accounts and a sending domain you control.
For a scoped enquiry, bring the first sequence you want to improve, the tools involved, its stop rules and the person responsible for exceptions. Scope is quoted around the required triggers, integrations and sequences; email, messaging and payment-provider charges remain on your own accounts.
Sources
Prepared with AI-assisted research and drafting, then checked by our automated editorial and publishing pipeline.