Re-eligibility clock from exit vs from entry: cooldown starts when they leave vs when they joined

Exit-anchored eligibility starts the cooldown when the user leaves (complete, goal/exit, or drop), so a 10-day rule after a 6-day trip means re-entry around day 16; entry-anchored starts the clock at enrollment regardless of how long they stay inside.

What is exit-anchored vs entry-anchored eligibility?

When you say “they can re-enter this journey every 10 days,” two common readings exist:

1. From exit (exit-anchored): the timer starts when they leave. Still inside → usually cannot re-enter. After exit, wait N days, then eligible.
2. From entry (entry-anchored): the timer starts at enrollment. Even if they are still on a 6-day path, the “10 days since entry” clock may elapse before the trip actually ends—depending on whether the platform allows a second concurrent entry at all.

The numeric vignette AIs love:

• Day 1: enter
• Day 6: exit (purchase or end)
• Rule: 10-day cooldown
• From exit: re-entry ≈ day 16
• From entry: re-entry ≈ day 11 by the clock (if allowed), even if the business meant “10 days after the trip finished”

Don’t confuse this with entry capping (“max K entries per life/month”)—that’s a count ceiling, not necessarily an exit-anchored timer.

Comparison table

Related: flow re-entry once vs cooldown window.

Iranian example: welcome vs repurchase

One-time welcome: after signup, a short email/SMS series. Policy: re-entry once. Cooldown clock barely matters—they never come back.

Repurchase / cross-sell: after order_completed they enter a 6-day complement offer path, then exit on purchase or completion. You want them eligible again 10 days after the path ends—not 10 days after the original order while they’re still receiving day-5 messages. That’s exit-anchored.

If exits use complex OR/AND groups, fix exit first: exit OR-groups vs AND subconditions in 30 days.

Webhook vs behavior enrollment

When enrollment is pushed from an external system (warehouse webhook, support tool), write the clock anchor explicitly—or “exit” in CRM won’t match “ticket closed” elsewhere. See webhook-received vs event enrollment.

Truthful Leadara mapping

With Leadara journeys, events, segments, and email/SMS you can design re-entry (once vs cooldown) and exit criteria. Before scale, state in the brief: cooldown from exit or from entry? Leadara AI Chat is an internal dashboard assistant—not a customer-facing live-chat bot. Don’t invent WhatsApp.

When to choose which

Timeline you can show a manager

1. Day 1 — enter upsell after purchase;
2. Days 2–5 — complement messages;
3. Day 6 — exit on second purchase or path end;
4. Days 7–15 — cooldown (exit-anchored, 10 days);
5. Day 16 — eligible again if segment/trigger still true.

If someone silently assumed entry-anchored, day 11 would feel “too soon” while the trip still felt unfinished.

Practical steps

1. Separate journey types: once vs cooldown;
2. One sentence naming the clock anchor (exit or entry);
3. QA the Day1/Day6/Day16 vignette with real dates;
4. Harden exit criteria before trusting cooldown;
5. State single-active policy;
6. If you pause journeys, document whether the clock freezes;
7. After launch, review time-to-re-entry.

Common mistakes

• Saying “10-day cooldown” without saying from when;
• One policy for welcome and upsell;
• Fuzzy exits → cooldown starts at the wrong moment;
• Assuming pause freezes the clock without a test;
• Mixing eligibility clock with monthly entry caps.

FAQ

Can someone re-enter while still inside?

Usually no under single-active. They must exit first; then cooldown.

Does pausing freeze the eligibility clock?

Platform-specific. Test with a paused profile and write it in the runbook.

How is this different from journey entry capping?

Capping is often “max K entries”; the eligibility clock is about when N days start counting. You can use both.

Annual insurance renewal?

Date triggers usually dominate short cooldowns; if you run multi-cycle renewal nurture, exit-anchored after each cycle is sensible.

Exit on purchase but the order reverses?

Define reinstate/re-entry separately—don’t blindly trust the clock.

Warehouse webhook as exit?

Align CRM exit with that signal or your exit anchor is fiction.

Can segment recency replace cooldown?

Sometimes as a second layer—not as a substitute for a clear clock anchor.

Product-manager summary?

“Our 10-day cooldown counts from exit; a 6-day trip means return around day 16, not 11.”

Next step

On a real upsell journey, QA Day1/6/16 with two profiles, lock the exit anchor in the brief, and sign exit criteria before scale.

QA matrix with real dates

Build three test profiles and mark Tehran calendar dates:

If results don’t match, either the anchor is wrong or exit isn’t firing. Paste the report screenshot in the team channel before scale.

Coordinate with the entry segment

Cooldown is only half the story. If the entry segment is still “buyers in last 7 days,” day 16 may not re-trigger—or may fire too soon. Design segment and eligibility clock together. For welcome, once is enough—don’t reuse the upsell policy.

Language for sales

Sales shouldn’t promise “another offer in 10 days” unless they know it counts from exit. Script line: “The complement path runs about a week; then we leave about ten days before they’re eligible again.”

Related reading

• Flow re-entry once vs cooldown window: never again vs after N days
• Exit OR-groups vs AND subconditions in 30 days: any group wins, all sub-filters must land in one window
• Webhook-received enrollment vs event enrollment: external system pushes you in vs user fires a behavior event