A customer accepts a quote at 9:58. At 10:00, an automated email asks them whether they’ve had a chance to look at it. The reminder was scheduled yesterday, when the quote was still open. The worker sent it using yesterday’s information.
Imagine this happening at a maintenance business that uses a CRM for quotes and a separate inbox for replies. The useful design decision is where the reminder gets its final permission to send.
Schedule a check, then decide
Store the quote ID, quote revision, reminder step and due time. When the job runs, reload the current quote and any reply or opt-out status your workflow relies on. Send only if that exact revision is still open, the channel is allowed and the step is still due. If you can’t confirm those facts, defer or put the job in a review queue.
Pick one source of truth for each signal. The CRM might own quote status, while the inbox owns the latest customer reply. If reply ingestion is delayed and you can detect that lag, give the integration time to catch up before attempting the send. A last-minute check only sees events the system has received.
Handle retries as separate decisions
Give each planned send a unique key such as quote-184:rev-3:reminder-1:email. Reserve that key once in durable storage so two workers don’t both attempt delivery. If the provider supports idempotency, reuse the same key for retries according to its contract.
A provider timeout can leave the delivery outcome unknown. Check the provider’s delivery record or put the attempt in a review queue before retrying. Record the quote revision, decision and provider reference where available. An audit trail should explain why the reminder was sent, skipped or held without storing the whole email thread.
Acceptance checks for a test account
These are illustrative expectations for synthetic records.
| Test input | Expected result |
|---|---|
| Quote accepted before the job runs | Skip and record the accepted state |
| Revision 4 replaces revision 3 while revision 3 has a job queued | Skip the old job and evaluate revision 4 on its own schedule |
| Customer reply is present but a staff member hasn’t resolved it | Pause reminders for review |
| Two workers pick up the same reminder | Only one worker reserves the send key |
| Provider times out after the request | Record an unknown outcome and reconcile before retrying |
Start with one reminder step and a test account. Have staff review the held cases before you add another channel or increase the send frequency.
Related StackEndBox guide: Design the handoff from quote to booking.
For help implementing these checks around your existing tools, see StackEndBox’s CRM and workflow automation services.
Top comments (0)