Summarize this documentation using AI
Overview
Wait Until... in Customer.io is the control you use when timing matters more than cadence, for example waiting to message until a shopper actually starts checkout, a package is delivered, or a product comes back in stock. Instead of guessing with a 2-hour or 1-day delay, you hold a person in a flow until a specific condition becomes true, then you move immediately into the next step.
For D2C teams, this is how you stop sending “still thinking?” emails to customers who already purchased, and how you speed up recovery when intent is high (like when someone returns to the checkout page). Propel helps brands turn these timing controls into revenue-safe orchestration across email, SMS, and paid retargeting in Customer.io, if you want help you can book a strategy call.
How It Works
Wait Until... in Customer.io pauses a person at a step in your workflow until they meet the condition you set, typically based on an event, an attribute change, or a segment membership update.
In practice, you place a Wait Until step after a trigger (like “Added to Cart”) and before a message (like “Cart reminder SMS”). The workflow checks the person until the rule is satisfied, then releases them to the next action. You can also pair it with an “escape hatch” so people do not get stuck forever, for example a max wait window followed by a different path.
Most D2C builds use Wait Until in three places: (1) to avoid premature messaging (wait for checkout start), (2) to avoid irrelevant messaging (wait until purchase does not happen), and (3) to align with fulfillment reality (wait until delivered before review request). If you are coordinating this across multiple channels and exit rules, build it in a single orchestrated journey in Customer.io so every message respects the same state.
Step-by-Step Setup
Wait Until... in Customer.io is easiest to set up when your events and attributes are already cleanly named (cart_updated, checkout_started, order_created, shipment_delivered).
- Pick the moment you want to control (example: “send cart recovery only after they have started checkout, otherwise use browse education”).
- In your workflow, add the trigger that starts the journey (example: Added to Cart).
- Add a Wait Until... step immediately after the trigger.
- Define the condition to release the person (example: event “checkout_started” occurs, or attribute “checkout_started_at” is not empty).
- Add a time limit or fallback path if appropriate (example: if they do not start checkout within 2 hours, send a product discovery email instead of a checkout-focused message).
- Place your message steps after the Wait Until release (example: SMS with checkout link, then email with social proof).
- Add an exit condition for purchase (example: exit the workflow if “order_created” happens at any time).
- QA with real event payloads (cart value, items, landing page, discount eligibility) so the first message is accurate the moment the wait releases.
When Should You Use This Feature
Wait Until... in Customer.io is the right move when behavior should dictate timing, not your calendar.
- Cart recovery with intent gating: Wait until checkout starts, then send a higher urgency message. If checkout never starts, keep it softer and more educational.
- Price drop and back-in-stock: Wait until inventory is available or price rule is met, then notify immediately. This is especially important for fast-selling SKUs.
- Post-purchase sequencing: Wait until fulfillment milestones (shipped, delivered) before asking for reviews, offering replenishment, or promoting accessories.
- Reactivation with relevance: Wait until a customer visits a collection or product page again, then trigger a “welcome back” offer that matches what they browsed.
Operational Considerations
Wait Until... in Customer.io works best when your data model supports clear state transitions and when your workflow has explicit exits.
- Event reliability: If “checkout_started” is missing for some sessions, your wait can stall. Confirm tracking for web and mobile, and confirm deduping rules so events are not dropped.
- State definition: Decide what “started checkout” means (clicked checkout button, reached shipping step, or initiated payment). Your wait condition should match that definition.
- Timeout strategy: Add a max wait window for conditions that might never happen (for example, waiting for delivery when carriers fail to post updates).
- Exit orchestration: Ensure purchase exits are global across the journey so you do not send a cart reminder after an order is created.
- Segmentation impact: If your wait is based on segment membership, make sure the segment updates quickly enough for your desired timing (minutes, not hours).
Implementation Checklist
Wait Until... in Customer.io is simple to place, but it is easy to under-spec the conditions and create revenue leaks.
- Confirm the event or attribute you are waiting on exists for at least 95 percent of relevant sessions.
- Define the exact condition in business terms (what behavior counts) before building.
- Add a max wait window and a fallback path for any condition that may not happen.
- Add an always-on purchase exit condition for the whole journey.
- QA timing with real shopper flows (add to cart, start checkout, abandon, return, purchase).
- Validate message personalization data is available at the moment the wait releases (items, price, currency, discount eligibility).
- Check channel throttles and quiet hours so the release does not send at a bad time for SMS.
Expert Implementation Tips
Wait Until... in Customer.io becomes a revenue lever when you use it to separate “interest” from “intent”, and then tailor pressure, incentives, and content accordingly.
- In retention programs we’ve implemented for D2C brands, the highest lift comes from gating incentives behind intent. Example: wait until a shopper revisits checkout twice in 6 hours before offering a discount, otherwise lead with reassurance and UGC.
- Use two-stage waits for cart recovery: first wait for checkout start (short window), then wait for purchase (another short window) before escalating. This prevents sending a sequence that feels frantic and keeps your list healthier.
- For post-purchase, wait until delivered, then branch based on product type. Consumables can flow into replenishment timing, durable goods can flow into education and accessories.
- If you rely on segments for the condition, keep the segment logic lightweight. Heavy segments can update slower than you expect, which defeats the point of behavioral timing.
Common Mistakes to Avoid
Wait Until... in Customer.io can quietly break performance when the wait condition is ambiguous or when there is no clean escape path.
- Waiting on the wrong event: Using “page_viewed: checkout” when your site fires it inconsistently, instead of a backend “checkout_started” event.
- No timeout: People get stuck in the wait and never receive the next message, which also skews reporting because they remain “in journey” indefinitely.
- Missing purchase exits: Customers buy, but still get cart nudges because the exit condition was only placed on one branch.
- Incentive leakage: Waiting until “cart exists” then immediately offering a discount, without requiring intent signals like checkout start or repeat visit.
- Over-complicating early: Building multi-branch waits before you have clean tracking. Start with one wait, one timeout, then iterate.
Summary
Use Wait Until... when you want your timing to follow shopper behavior, not arbitrary delays. It is most valuable in cart recovery, post-purchase sequencing, and reactivation where relevance and urgency drive conversion. Build it with clear exits and timeouts inside Customer.io.
Implement with Propel
If you want Wait Until... to reliably drive incremental revenue, we can help you map the right events, exits, and fallback paths across Customer.io journeys. book a strategy call.