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.
A reminder can keep arriving after the work is done. The reviewer approved the help article in a comment, the task still says ‘in review,’ and the next scheduled message asks for the same update again. More reliable delivery would only repeat the mistake more reliably.
Before automating a follow-up, decide what the next run is allowed to conclude. It needs a source for the current state, a person responsible for resolving uncertainty and a stopping point. ‘Keep chasing until this is done’ leaves all three open.
Start with a reviewable draft for one recurring task. For a help article waiting on approval, the workflow below checks the record and prepares the next action for a person. It does not infer consent from silence or send another reminder merely because the clock ticked.
Put the trigger and the stop in the same contract
Follow-up contract: help article review
Adapt this contract before a trial. Replace Tuesday's checkpoint and the named roles with the time and owners agreed for your task.
- Trigger
- At the agreed Tuesday review checkpoint, check whether the article has an accepted review outcome. Run only for this article and this review round. A later revision requires a new review round.
- Owner
- The documentation owner is responsible for the follow-up. The product reviewer approves the article's accuracy. If either person changes, pause and have the documentation owner confirm the replacement before continuing.
- Evidence and freshness
- Use the current article revision, its review comments and the task's agreed deadline. Check that an approval applies to this revision. If the sources disagree or the latest record is inaccessible, report the gap to the documentation owner instead of treating the task as overdue.
- Draft and review
- Prepare a short status note with the source link and, only if review is still open, a proposed reminder stating the specific question. A person checks the note and approves any outgoing message. Do not choose a new deadline or promise publication.
- Stop or hand back
- Stop this round when the correct revision is approved, the task is canceled or an owner asks to stop. Pause on a changed deadline, owner or scope. After the first unanswered approved reminder, hand the unresolved item back to the documentation owner; do not repeat indefinitely.
The contract is deliberately narrow. It names one article, one review round and one unresolved question. If you cannot tell which object a follow-up belongs to, you will struggle to tell whether a later approval should stop it. Keep a stable task or document link with the record.
Walk through the next run before scheduling it
First, try a completed article. The reviewer has approved the current revision in the agreed record. The expected result is a short completion note and no proposed reminder. This checks whether the workflow recognizes evidence of completion, rather than relying only on a task label that someone may have forgotten to update.
Now try a changed article. The reviewer approved an earlier version, but the author changed the instructions afterward. That approval cannot automatically carry over to the new text. The workflow should point out the revision mismatch and ask the owner whether another review is needed. It should not silently reopen the old reminder sequence.
Finally, try an unavailable source. Perhaps access changed, or the latest comment has not reached the material the assistant can read. ‘No approval found’ is not the same as ‘reviewer has not approved.’ The useful output is the access or freshness gap. A reminder accusing someone of being late would turn missing evidence into a claim about their work.
Compare the drafts these trial inputs produce and note what needed correction before widening the assignment. If the workflow confuses an old approval with a new one, fix the evidence check first. Adding more tasks would multiply that ambiguity.
Give silence to a person who can resolve it
An unanswered reminder does not tell you why the work is waiting. The reviewer might lack context, have a conflicting priority or believe they already responded. The documentation owner can decide whether to clarify the request, change the reviewer or adjust the plan. An automation should not make those choices by escalating tone or inventing a new commitment.
Keep a small record of each approved follow-up: the review round, evidence checked, draft, approving person and resulting action. Before another run, inspect that record so the same unresolved item does not produce duplicate messages. When the owner pauses the task, make the pause part of the accepted state, not a private note the next run cannot see.
The authority boundary matters as much as the reminder text. Preparing the next message does not authorize a new promise. Read the source, output and review contract.
Use a scheduled draft as the starting point
Zeke can use scanned, connected Google Drive documents to prepare a sourced brief and repeat a task on a schedule. Start by having it prepare the status note for review. A recurring run is not a live watcher of every deadline, and scheduling does not refresh old documents. New information needs to be available in the scanned sources; automatic Slack archive ingestion and continuous Drive sync are not implied.
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 is a way to define the behavior you need, not a claim that Zeke already manages that entire follow-up process for you.
For the help article, success includes the run that produces no reminder because the correct approval is already there. Decide how that run should behave before making the schedule more frequent.