Reactive outbound mirror of outbound-follow-up-response-watcher. It fires on the same data.mail created stream but processes the OWNER's outbound sends rather than inbound replies: when the owner sends on a thread already tracked in data.shared watch state, it confirms the sender is the owner (derived from the linked source mail's From via the stored record_id) and refreshes the row to watching_customer_response with a fresh last_outbound_at and sent_message_id, moving the ball back to the contact. Refresh-only: it never creates rows (the pressure producer and the send recipes own creation) and never reopens responded_closed threads, and it fails closed (skips) when it cannot confirm the owner or find a matching row. This captures owner replies sent from a normal mail client, which the send recipes cannot record.
Refresh follow-up watch on owner sends
Reactive outbound mirror of outbound-follow-up-response-watcher. It fires on the same data.mail created stream but processes the OWNER's outbound sends rather than inbound replies: when the owner sends on a thread already tracked in data.shared watch state, it confirms the sender is the owner (derived from the linked source mail's From via the stored record_id) and refreshes the row to watching_customer_response with a fresh last_outbound_at and sent_message_id, moving the ball back to the contact. Refresh-only: it never creates rows (the pressure producer and the send recipes own creation) and never reopens responded_closed threads, and it fails closed (skips) when it cannot confirm the owner or find a matching row. This captures owner replies sent from a normal mail client, which the send recipes cannot record.
Complete workflow
End-to-end outbound follow-up workflow pack for one-person companies. It turns Email / Outbox into a repeatable loop: surface outbound threads that may need closure, draft concise follow-ups, send selected drafts through the mail-send approval boundary, and carry loop state through data.shared with links back to the source mail.
You are viewing one recipe in this workflow. Installing it opens the complete pack so its other recipes and background automations arrive together.
Read-only outbound follow-up queue for a one-person company. It scans a sent/outbound mail folder, classifies recently sent threads that may need closure, and shows the owner what to follow up on before running the draft/send workflows.
Read-only Email/Outbox workflow. Scans a sent/outbound mail folder, classifies likely follow-up candidates, and drafts a small batch of plain-text replies without sending. Use this as the preview lane before running batch-approve-followups.
Action workflow over Email/Outbox. Scans likely silent outbound threads, drafts plain-text follow-ups, then sends the selected batch through the mail-send kernel ingredient. Because mail-send is the irreversible send-class boundary, attended runs route the send step through the existing approval gate. The send is the originating context, so after sending it seeds durable data.shared watch state (status watching_customer_response, loop_kind outbound_followup) keyed by thread — the same key the pressure producer uses, so it supersedes any followup_due row — and outbound-follow-up-response-watcher adopts that linkage to close the loop when the contact replies.
Silent auto-run (hourly) producer for the outbound follow-up loop. It scans a sent/outbound mail folder, classifies outbound threads that may need closure, and writes durable data.shared watch state (status followup_due, keyed by sanitized thread id) into the outbound-follow-up-response-watcher namespace. It records watched_contact (the primary recipient) so outbound-follow-up-response-watcher can confirm a reply actually came from the contact rather than from the owner's own sent mail, and it skips threads already advanced by that watcher or by send-support-reply-from-mail. unified-work-queue and weekly-owner-review read this same state to surface follow-up discipline without registering a new enrichment topic.
Reactive reply-side of the outbound follow-up loop. On every inbound mail it matches the message by thread against durable data.shared watch state seeded by TWO producers — outbound-follow-up-pressure-producer (status followup_due, watched_contact = the primary recipient) and send-support-reply-from-mail (status watching_customer_response, watched_contact = the customer). It confirms the reply's sender is that watched contact — recovering the contact from the linked source mail (via the stored record_id) when a producer denormalized no address, and failing closed (skipping) when it cannot establish the counterparty — then classifies the reply, advances the shared state to responded_closed or response_needs_owner, and links the reply mail to the watched source mail. Those state transitions are what unified-work-queue and weekly-owner-review read to surface or retire the follow-up. It never sends mail or mutates an external system.
Show all 13 recipes
Neutral detection recipe for the outbound follow-up loop. It scans one response_needs_owner data.shared watch row, fetches the reply body, extracts possible conversion facets for meeting, task, insight note, commitment, and linked CRM deal next-step updates, writes compatible proposal rows for the matching owner-invoked action recipes, records a per-reply notification marker, and sends one notification that the reply has conversion options. It does not choose an action and never creates calendar events, tasks, notes, commitments, or CRM updates. User intent is expressed later by running one or more manual action recipes.
Owner-invoked create half of the meeting-request conversion edge. It reads one awaiting_owner_approval proposal written by outbound-follow-up-meeting-request-calendar (optionally targeted by proposal_thread_key), creates the calendar event from the proposal's already-extracted schedule, links the event back to the reply and source mail, closes the follow-up loop on the source watch row, and marks the proposal scheduled. This recipe is manual-only on purpose: the calendar create (and, on some providers, the attendee invite) is an outward-facing action, and running it is the owner's explicit approval. It takes no calendar action when there is no pending proposal or the proposal lacks a concrete start and end time.
Owner-invoked create half of the task conversion edge. It reads one awaiting_owner_approval proposal written by outbound-follow-up-task-from-reply, optionally targeted by proposal_thread_key, creates a Recued task from the proposal, links the task back to the reply and source mail, closes the source follow-up watch row, and marks the proposal created. This recipe is manual-only on purpose: running it is the owner's approval to turn the proposed reply action into durable work.
Owner-invoked create half of the customer-insight note conversion edge. It reads one awaiting_owner_approval proposal written by outbound-follow-up-insight-note-from-reply, optionally targeted by proposal_thread_key, creates a Recued note from the proposal, links the note back to the reply and source mail, and records the note id on the source follow-up watch row WITHOUT closing the loop — an insight note is complementary memory capture, so the thread stays open (its status is preserved) for the actual task/meeting/reply. It marks the proposal created so it is not re-proposed. This recipe is manual-only on purpose: running it is the owner's approval to turn the proposed customer signal into durable relationship memory.
Owner-invoked create half of the commitment conversion edge. It reads one awaiting_owner_approval proposal written by outbound-follow-up-commitment-from-reply, optionally targeted by proposal_thread_key, creates a Recued commitment from the proposal, links the commitment back to the reply and source mail, and records the commitment id on the source follow-up watch row WITHOUT closing the loop. A commitment is complementary accountability capture, so the thread keeps its current status for the actual task/meeting/reply. It marks the proposal created so it is not re-proposed. This recipe is manual-only on purpose: running it is the owner's approval to turn the proposed promise into durable work.
Owner-invoked action half of the CRM deal update conversion edge for the outbound follow-up loop. It reads one awaiting_owner_approval proposal written by outbound-follow-up-reply-conversion-options, verifies the proposal is still tied to the same source watch row and CRM connection, updates the canonical CRM deal next_step, links the deal back to the reply/source mail, and records the CRM deal linkage on the data.shared watch row without closing the loop. This recipe is manual-only on purpose: running it is the owner's approval to update the CRM deal.
Housekeeping GC for the outbound follow-up loop. data.shared writes do not honor ttl (the durable store rejects it), so the per-thread conversion proposals written by the calendar/task/insight-note/commitment/CRM deal update detectors would otherwise persist forever after they are approved. This daily auto_run lists the outbound-follow-up namespace and deletes only proposal rows in a terminal status (scheduled / task_created / note_created / commitment_created / crm_deal_updated). It is safe because re-proposal is already blocked by the conversion id recorded on the source watch row for one-shot conversions (calendar_source_id / task_id / insight_note_id / commitment_id), while CRM deal-update duplicates for the same reply are blocked by the per-reply notification marker plus pending proposal rows. It never touches the watch rows themselves (they stay for re-open on a later reply), and it leaves awaiting_owner_approval proposals alone (they carry no timestamp, so a stale-unactioned proposal cannot be aged out here — record a created_at on proposals if that is wanted later).
How it works
Inspect the data fetches, transforms, gates, and output this recipe runs.
Trust & control
What installing this recipe would let it do. Recued grants these permissions at install — review them there before approving.