Workflows & controls
How to design customer follow-ups with approval and stop rules
By POST · Published
A follow-up is useful when it helps a customer finish something they wanted to do. It becomes a problem when it continues after they replied, repeats a teammate’s message or reaches someone who did not expect it. Choosing the message is only one part of the design.
Write the trigger, audience, action and stop conditions before building an automation. Start with internal review, then decide whether any part can safely run with less intervention. The following example is a planning exercise using synthetic records, not a claim about results.
1. Use a trigger someone can verify.
“Follow up with interested customers” leaves “interested” undefined. “Notify the owner when an open enquiry has no reply for the configured period” is easier to inspect. State which message or event starts the clock and whether the rule reacts to something that happened or periodically checks for an absence.
In POST, supported workflows include event triggers, scanning triggers and message-based reply rules. A periodic scan can notice an unanswered record; it is not a promise to act at an exact minute. Choose the supported trigger that matches the evidence you actually have.
2. Choose a small audience and a narrow purpose.
For a service enquiry, the purpose might be to ask whether the customer still needs information. It should not quietly become a promotional campaign. Limit the initial audience to the records your team can review and exclude cases with an unresolved complaint or a person already handling the conversation.
Check what data supports each exclusion. If the builder cannot express a condition you need, keep that decision with a person. Do not treat a tag, a qualification score or a phone number as proof of permission to send a message.
3. Decide when the follow-up must stop.
Write stop rules before writing a sequence. A customer reply should prompt a fresh look at the conversation. An opt-out requires stopping the relevant communication. Human takeover, a completed order, a changed lead stage or a delivery failure can also make the planned next step inappropriate.
These are design requirements to verify against the available controls, not a claim that every tool enforces every exclusion automatically. Test each one. If a stop condition depends on an integration, ask what happens when its event arrives late or never arrives.
- Customer replied or asked for a person.
- Customer opted out or the permission is unclear.
- A teammate took ownership of the conversation.
- The intended outcome is complete or the record changed.
- Delivery failed or the integration state is uncertain.
4. Separate a draft, an approval and delivery.
A saved draft means there is text to review. Approval means someone authorized the proposed action. A successful provider delivery is a third state. Keep those distinctions visible so a teammate does not assume the customer has been contacted merely because the AI finished a response.
POST routes workflow outbound actions through applicable mode and sending checks, including limits, cooldown and business hours. Review the actual configuration for the action you choose. A sensitive case can stay as an internal notification followed by a manual conversation.
5. Check the channel before enabling messages.
For WhatsApp, obtain the required opt-in and honor opt-outs. Business-initiated messages and messages outside the 24-hour customer service window require approved templates. Automated replies must offer a clear escalation path. Review the current official policy before activation.
Do not assume an old chat makes every future message appropriate. Check the purpose, template and conversation state at the time of sending. Keep permission questions with the responsible person rather than asking the AI to guess.
Source: WhatsApp Business Messaging Policy. Official channel requirements reviewed on 22 October 2026.
6. Trial one rule and inspect what happened.
Use synthetic records first: one matching enquiry, one that already received a reply and one that should be excluded. Inspect the workflow history and the action outcome. Confirm that pausing the rule prevents future runs, and document who owns failures.
After activation, review a small sample regularly. Count useful replies, incorrect matches, opt-outs and interventions alongside completed outcomes. A high message count alone says little about whether customers received help. Expand the workflow only when the evidence supports it.