DEV Community

Cover image for Designing Follow-Up Automation for New Enquiries
chirag
chirag

Posted on

Designing Follow-Up Automation for New Enquiries

A visitor asks for a project discussion. Your system creates a follow-up task. Before that task runs, the visitor replies and a representative starts a conversation.

If automation sends the original reminder anyway, it no longer reflects the enquiry's state.

A follow-up workflow needs cancellation and coordination as carefully as scheduling.

Define the scope

For this hypothetical example, automation creates internal sales tasks for accepted enquiries. Any external message requires its own permission, channel, preference, and communication policy.

Do not treat an enquiry as unlimited consent for unrelated marketing messages. Keep requested service communication separate from promotional sequences.

Model the enquiry lifecycle

A small workflow might use accepted, assigned, contacted, replied, closed, and needs-review states. Define which transitions create tasks and which cancel them.

For example, an accepted and assigned enquiry can create a first-response task. A verified reply cancels obsolete reminders. A closed enquiry prevents further tasks in that sequence.

Store the automation version and task identity so retries cannot create the same task repeatedly.

Check the state at execution

A scheduling-time condition is not enough. The record may change before a delayed job runs.

When the job becomes due, reload the relevant state. Check whether the enquiry is still eligible, whether the owner changed, and whether an equivalent task already exists.

Use an atomic reservation for the action. Otherwise two workers can both decide the task is missing and create it.

Define what counts as a reply

An automated out-of-office response is not always evidence of an active conversation. A message may also relate to a different enquiry from the same contact.

Document the reply-matching rule and provide a manual pause. When classification is uncertain, routing to review is better than confidently continuing an inappropriate sequence.

Handle the timing race

A reply can arrive after the final check but before a message is sent. There is no universal local transaction spanning your database and an external messaging provider.

Reduce the race with a final check and cancellable provider scheduling where supported. Record dispatch status and acknowledge any remaining boundary rather than promising perfect cancellation.

Test transitions

Scenario Expected result
Reply arrives before due time Obsolete reminder cancelled
Owner changes Task follows documented reassignment rule
Worker retries No duplicate task
Enquiry closes Sequence stops
Reply classification uncertain Review or manual pause available

Measure completed first responses and overdue tasks. A workflow succeeds when it supports the current conversation instead of repeating a stale plan.

Top comments (0)