The work behind the workflow.

1. Get an event. A form sends a webhook (a small automatic message to a set address). Or a timed job checks an app for new records.
2. Check and sort the facts. Confirm the request. Check the needed fields. Match it to the right customer. A database stores the lead's status, the next follow-up time and what already happened.
3. Apply the rules and link the tools. An API is a set way for one program to ask another to do work, like updating a record or sending a message. Rules decide which path runs.
4. Run at the right time, then record the result. A scheduler holds work until it is due. A worker checks the latest status, acts, and records success or failure. The owner can see what happened.

Stage 1, a person does it all: open the lead list. Find leads with no answer. Check when the last message went out. Check for a reply or booking. Write the next message. Send it. Update the record. Repeat tomorrow. The problem: it depends on someone remembering, checking many places, and writing it all down every time.

Stage 2, write the choice as a small rule. A lead is due only when its time has come and it has not replied, booked or opted out:

def needs_follow_up(lead, now):
    return (
        lead["follow_up_at"] <= now
        and not lead["replied"]
        and not lead["booked"]
        and not lead["opted_out"]
    )

Read it as: "The follow-up is due, and no stop rule is true." The rule only answers yes or no. It does not send anything.

Stage 3, link the rule to an action. A timed worker reads the lead records. It applies the rule. It asks the text service to send the approved message. It records what happened. Then it sets the next step, if there is one.

• Fresh data and stop rules: check replies, bookings and opt-outs before each send. Send unclear cases to a person.
• No doubles: each job gets one ID and runs once, so a retry can't send twice.
• Retries and alerts: retry short failures a few times, with longer waits each time. Alert an owner when a send is in doubt.
• Safe access and testing: keep passwords out of code. Check that incoming requests are real. Before launch, test the normal, double, failure and stop paths.

Further reading: Stripe: webhooks · Stripe: idempotent requests. These show common patterns. Your tools may work differently. The code here is for teaching, not for use as is.