Connect reminder ladders

Connect: Contract signature reminders

Fires when a contract goes out for signature, then nudges at +24h, +72h and +7 days. Every wait is anchored on the event's own sent_at, and every send is gated so a late or backfilled entry only sends the highest threshold it has crossed.

Trigger

Event contract_sent

One journey per submission_id, simultaneous entries allowed.

Exit conditions

Checked before every send. Each one matches the exit event's submission_id against the trigger's.

contract_signed
contract_voided
contract_expired

Cadence

+24h → +72h → +7d after event.sent_at

Wait timeout 30 days on each step.

Send state

3 emails, all automatic

Tracked · sends to unsubscribed · no frequency cap.

Flow

Trigger

Event contract_sent performed
Wait until event.sent_at + 24h747

Maximum wait 30 days → exit (action 769)
Sent less than 72h ago?748

Skip-burst gate · sent_at newer than 72h ago AND sent_at in the past

TrueSend Nudge 1 — 24h after send

FalseSkip the send, fall through to the next wait
Nudge 1 — 24h after send749 · tpl 705

Subject: Reminder: please sign {{event.document_name}}
Wait until event.sent_at + 72h750

Maximum wait 30 days → exit (action 770)
Sent less than 7d ago?751

Skip-burst gate · sent_at newer than 7d ago AND in the past

TrueSend Nudge 2 — 72h after send

FalseSkip the send, fall through
Nudge 2 — 72h after send752 · tpl 706

Same subject and body as Nudge 1
Wait until event.sent_at + 7d753

Both the event-time and maximum-wait branches continue into the next gate
Sent less than 30d ago?754

Staleness guard · sent_at newer than 30d ago AND in the past

TrueSend Nudge 3 — 7d after send, then exit

FalseExit without sending (action 771)
Nudge 3 — 7d after send755 · tpl 707

Last message in the ladder. No upper gate beyond the 30d guard, expiry is handled by the exit conditions.
Exit746

Why the gates exist: without them, a contract armed a week late would fire all three nudges back to back. Each gate asks "is this object still inside the window this nudge is for?" so a late entry sends only the highest threshold it has crossed.

Workflow diagram

Email — contract reminder

The same body is used for all three nudges (templates 705, 706, 707). Toggle between the raw Liquid and the same email filled with demo values.

From

Reply-to

Subject

Preheader

Delivery so far

Message	Sent	Delivered	Human opens	Human clicks
Nudge 1 — 24h	3	3	0	0
Nudge 2 — 72h	8	8	1	1
Nudge 3 — 7d	2	2	1	0
Total	13	13	2	1

Opens exclude machine/prefetch opens (2 of the 4 recorded opens were prefetch). Numbers are cumulative since the campaign started on 3 Aug 2026 and are far too small to read anything into.

Connect: Intake (RCM onboarding) reminders

Fires when an onboarding intake form is sent, then nudges on day 3, 7 and 11. The day-14 gate on the last nudge is a belt-and-braces guard in case the platform's inactivity expiry lags.

Trigger

Event intake_sent

One journey per response_id, simultaneous entries allowed.

Exit conditions

Checked before every send. Each matches the exit event's response_id against the trigger's.

intake_submitted
intake_expired

Cadence

Day 3 → day 7 → day 11 after event.sent_at

Wait timeout 30 days on each step.

Send state

3 emails, all automatic

Tracked · sends to unsubscribed · no frequency cap.

Flow

Trigger

Event intake_sent performed
Wait until event.sent_at + 3d757

Maximum wait 30 days → exit (action 766)
Sent less than 7d ago?758

Skip-burst gate · sent_at newer than 7d ago AND in the past

TrueSend Nudge 1 — day 3

FalseSkip the send, fall through
Nudge 1 — day 3759 · tpl 708

Subject: Reminder: please complete your {{event.form_name | downcase}}
Wait until event.sent_at + 7d760

Maximum wait 30 days → exit (action 767)
Sent less than 11d ago?761

Skip-burst gate · sent_at newer than 11d ago AND in the past

TrueSend Nudge 2 — day 7

FalseSkip the send, fall through
Nudge 2 — day 7762 · tpl 709

Same subject and body as Nudge 1
Wait until event.sent_at + 11d763

Maximum wait 30 days → exit (action 768)
Sent less than 14d ago?764

Pre-expiry gate · 14d is the default inactivity expiry on the platform side

TrueSend Nudge 3 — day 11, then exit

FalseExit without sending
Nudge 3 — day 11765 · tpl 710

Final nudge before the form expires for inactivity
Exit756

Shape difference vs automation 98: here the third wait routes its maximum-wait branch to its own exit, so a journey that never reaches day 11 inside the window leaves cleanly rather than dropping into the last gate.

Workflow diagram

Email — intake reminder

The same body is used for all three nudges (templates 708, 709, 710). Toggle between the raw Liquid and the same email filled with demo values.

From

Reply-to

Subject

Preheader

Delivery so far

Message	Sent	Delivered	Human opens	Human clicks
Nudge 1 — day 3	19	19	10	5
Nudge 2 — day 7	5	5	1	0
Nudge 3 — day 11	2	2	0	0
Total	26	26	11	5

Opens exclude machine/prefetch opens (7 of the 15 recorded opens were prefetch). Cumulative since 3 Aug 2026.

Shared setup

Settings that are identical across both automations, plus the operational notes worth carrying into any change.

Workspace199348 (Carepatron production)

Campaign typeTransactional

Sender identityID 15, used for both From and Reply-to
{% if customer.rep_name %}{{ customer.rep_name }} @ Carepatron{% else %}Carepatron{% endif %}
{{ customer.rep_email | default: '[email protected]' }}

LayoutID 3 "HTML only" — a pass-through wrapper ({{ content }}), so the template body is the entire email

EditorWYSIWYG, premailer preprocessor

TrackingOpen and link tracking on for all six messages

Send to unsubscribedOn — deliberate, these are transactional reminders with no unsubscribe link, matching the platform version they replaced

Frequency capNone (no_cap)

Re-entryRematch, no minimum interval — one journey per object id

Wait anchoringAll waits use delay_event_attr: sent_at on the trigger event, never a profile attribute (profile-attribute date waits park forever)

Exit condition shape

Both automations use per-object exits. The exit event has to carry the same object id as the trigger event, otherwise one signed contract would silently disarm every open contract for that person.

{
  "and": [
    { "event_name": { "name": "contract_signed", "etype": "" } },
    { "foreign_event": {
        "attribute_compare": {
          "field": "submission_id",
          "field_source": "foreign_event_attribute",
          "operator": "eq",
          "value": "submission_id",
          "value_source": "event_attribute"
        }
    }}
  ]
}

Automation 98 stacks three of these (contract_signed, contract_voided, contract_expired) on submission_id. Automation 99 stacks two (intake_submitted, intake_expired) on response_id.

Worth knowing

Gates are two-condition. Each one requires sent_at to be inside the window and in the past, so a future-dated sent_at can't sneak a send through.
Backfill invariant. Any backfilled arm event must only cover objects sent before the campaign started. A re-emit for a post-start object stacks a duplicate journey; exits don't dedupe entries.
The From name and the sign-off read different sources. The sender identity resolves customer.rep_name / customer.rep_email (profile attributes) while the body sign-off uses event.rep_name. Under concurrent multi-rep objects the From name follows the latest rep, the sign-off stays per-object.
Exits are not atomic. If a disarm event lands while a send is already in flight, the send goes out. The window is seconds wide and inherent to the design.
No unsubscribe link, by design. These are transactional and mirror the platform reminders they replaced. "Just reply to this email" is the support path, so the reply-to inbox has to be monitored.

Source

Automation 98Open in Customer.io

Automation 99Open in Customer.io

Build spec06-Agent-Work/connect-reminders/build-spec.md

Templates on disk06-Agent-Work/connect-reminders/templates/ — byte-verified against the live templates