Follow-up automation that knows when to stop
Give a recurring follow-up an explicit trigger, owner, evidence source and review boundary. Handle completion, stale records and silence before adding reminders.
Suppose you are trying to publish a help article before a customer starts onboarding. The engineer checking the instructions wrote ‘looks good’ in a Google Doc comment, but the Linear task still says ‘in review.’ You rewrote a setup step after that comment. A scheduled Slack reminder now risks either chasing work already done or accepting approval for the wrong version.
Before automating that follow-up, decide which record the next run should check, who resolves an unclear answer and when the reminders stop. Start with one article and a status draft you can review before anything goes out.
Put the trigger and the stop in the same contract
Follow-up contract: help article review
For the sample article above, agree this contract before a trial. Replace Tuesday's checkpoint and the source labels with your actual time and links.
- Trigger
- At Tuesday's 2 p.m. checkpoint, check whether the Google Doc has approval for its current instructions. Run only for this article and this review round. A later revision needs a new review round.
- People
- You handle the follow-up and publication; the engineer who wrote the setup steps checks their accuracy. Confirm both names in the Linear task. If either person changes, pause until you have agreed who takes over.
- Evidence and freshness
- Use the Google Doc's current revision, review comments and the deadline in Linear. Check whether ‘looks good’ came before or after the changed setup step. If the records disagree or the latest comment is inaccessible, report the gap for you to review instead of declaring the engineer late.
- Draft and review
- Prepare a status note with the source link. If review is still open, draft a Slack reminder asking whether the revised setup step is correct. You check the note and approve any outgoing message. Do not choose a new deadline or promise publication to the customer.
- Stop or hand back
- Stop when the current revision is approved, the task is canceled or either person asks to stop. Pause on a changed deadline, person or scope. If you approve and send one reminder and nobody answers by the next agreed checkpoint, pause the reminders and decide the next step yourself.
Keep the document and task links with this contract. Record which revision is being checked so a later approval can be matched to the right text. You can use the same contract if you write the article and coordinate the review; it needs named people, not dedicated process jobs.
Walk through the next run before scheduling it
First, try a completed article. The engineer has approved the current revision in the Google Doc. The expected result is a completion note with that source and no proposed reminder, even if Linear still says ‘in review.’ Check the draft before you update the task.
Now try a changed article. The engineer approved the earlier version, then you changed the setup step. The workflow should point out the revision mismatch and ask you whether another review is needed. It should leave the old reminder sequence paused until you decide how to handle the new text.
Finally, try an unavailable source. Perhaps the Google Doc's access changed, or the latest comment is absent from the material the assistant can read. ‘No approval found’ is not the same as ‘the engineer has not approved.’ The useful output names the access or freshness gap and asks you to check it. It should contain no reminder accusing someone of being late.
I would run all three cases before setting a recurring schedule. Compare the drafts and fix any case that confuses an old approval with a new one. Keep the trial on this article until completion, revision changes and missing evidence all produce the expected response.
After one unanswered reminder, take it back
If the reminder you approved and sent gets no reply by the next agreed checkpoint, pause. Ask the engineer directly whether they need context, have another priority or already replied somewhere else. Then decide whether to clarify the question, ask someone else or move the publication date. Keep that decision with the task so the next run sees it.
Record the review round, evidence checked, draft, person who approved it and message actually sent. Check that small log before another run so a stale task label cannot trigger duplicate messages. A pause needs to be visible in the record the workflow reads, including when you are the person doing both the writing and the chasing.
Keep customer promises outside the reminder's permission. If the draft suggests a new publication date, you need to approve that separately.
Use a scheduled draft as the starting point
Zeke can use connected Google Drive documents after they have been scanned to prepare a sourced status draft, and repeat that task on a schedule. First put the checked revision, review outcome and deadline into a Drive document it can use. Check that the needed evidence is present in the scanned material; a link to Linear or a Google Doc comment alone does not guarantee its contents are available.
Updated documents need a new scan. Scheduling does not refresh sources or continuously watch every deadline, and Zeke does not capture the entire Slack archive. Review the schedule and each draft yourself. You approve external messages and commitments; Zeke does not make customer promises on its own.
The longer-term direction is to introduce proactive actions gradually from those knowledge sources, with a person approving external actions and commitments. The contract above defines the follow-up behavior you want to test. It does not mean Zeke already manages the entire process for you, including noticing every revision, stopping reminders and handing unresolved items back.