An online coffee shop launched an automated flow: if someone starts checking out on the site and there is no purchase an hour later, they get an email saying "You didn't finish your order". In its first week the flow sent 41 emails, and 17 of them went to people who had already placed their order. They chose to pay the courier with Kaspi QR, and the flow only counted a card payment as a purchase. Two of them messaged on WhatsApp, "I did order, what's wrong?", and the manager spent half a day making sure their orders hadn't been lost. It is the shop from the lesson on email marketing, and the shop's numbers are made up.
A trigger flow follows a simple rule: something happens, wait, act. The event starts the flow, the pause gives the person time to finish on their own, and before acting the flow checks once more whether the action is still needed. The shop did have a check before sending; it was just looking in the wrong place.
What counts as a purchase
The flow was built on site events. Entry is a checkout start: the person went to checkout with a non-empty cart, their email is known because they are logged in, and they are subscribed to emails. Exit is the purchase event. After the fixes in the lesson on the Conversions API Gateway, the site fires a purchase only after a card payment, and an order paid to the courier gets its own CourierOrder event. That is right for the ad account: payment at the door can still fall through. For the reminder it is a mistake. Someone who chose Kaspi QR has placed their order, and there is no reason to tell them to finish it.
There is a third route too. Some regulars order through the manager on WhatsApp, and those orders go into the CRM without touching the site. So the flow's exit is any order this person has placed, however they paid and wherever they ordered. All three routes meet only in the CRM, so that is where the second check looks.
One more detail is duplicates. A shopper refreshes the checkout page and the site sends the event twice. If the flow starts on every event, two emails go out. So it starts once per cart, keyed on the cart ID.
The check before every action
Entry conditions and sending conditions are different things. At entry the flow decides whether the person fits. Before sending it looks at what changed during the pause. In Klaviyo, for example, metric-based trigger filters are checked only at entry, while profile filters are checked at entry and again before each email or SMS. If someone fails a filter before an action, that action is skipped, but they aren't removed from the flow. Other services work in their own way, and the answer is in their documentation and their send log. The "no purchase" condition has to be checked right before sending; otherwise it only fires at entry, when there really was no purchase yet.
Before each email the shop now asks four questions, as in the picture:
- Does the CRM have an order from this person placed after they opened checkout?
- Have they unsubscribed from emails during the pause?
- Have they had another marketing message in the last 7 days?
- Are the items from the cart in stock?
Opens are never a condition. A rule like "didn't open the email, so remind them on WhatsApp" breaks on Apple Mail: Mail loads the tracking pixel itself, and the service records an open that never happened. That is why Mailchimp advises pausing flows triggered by opens: they reach more people than intended. Conditions are built on clicks and orders.
The "running out of beans" reminder
The shop's second flow serves its main goal, a second order within 60 days. Over the summer, according to the CRM, a quarter of new customers placed one, and the RFM analysis says newcomers should get a reminder after three to four weeks. The spec:
| Part | The shop's decision |
|---|---|
| Entry | The first order gets the "delivered" status in the CRM |
| Pause | 21 days: among repeat customers the median gap between orders is 28 days, delivery takes 2-5 days, so the reminder lands a few days before a typical reorder |
| Check before sending | No new order; no open complaint; consent to WhatsApp or to emails; no other marketing message in the last 7 days; the beans from the first order are in stock, otherwise suggest similar ones |
| Action | A task for the manager to write on WhatsApp if the customer agreed to that channel, otherwise an automatic email |
| Links | utm_campaign=reorder, utm_content=reminder_day21, source and medium from the dictionary: whatsapp / social or email / email |
| Exit | A second order or an unsubscribe |
| Control group | Half of everyone who enters gets no reminder |
The WhatsApp reminder is written by the manager; it needs no automation. Of roughly 150 new customers a month, about 100 consent to WhatsApp or email. In the test half of them get the reminder, and once it is switched on for everyone it comes to three to five messages per working day. The shop's WhatsApp is the app on the manager's phone, and for the CRM to message each customer on the right day by itself, you need the platform, which charges per message (the app or the platform). The manager can write five messages a day himself, in his own words, following the shop's voice guidelines.
There is no discount in the reminder. For someone who would have ordered anyway, a discount only cuts the revenue from the order.
When there are several flows
In their first month a new customer can land in four sends at once: the brewing guide two days after delivery, the monthly newsletter, the abandoned checkout email and the reminder. A cap inside a single flow does nothing about the total, so the frequency rule is shared by all marketing messages in every channel: no more than one in 7 days. If the reminder and the newsletter fall in the same week, the customer gets the reminder and skips the newsletter. Order updates don't count towards the rule; everyone gets them, the control group included.
Unsubscribing from emails doesn't move someone to WhatsApp. The reminder only goes there if they separately agreed to WhatsApp.
How many orders the reminder adds
The owner proposes counting everyone who ordered after the reminder. But over the summer a quarter of newcomers placed a second order without it. Only a comparison with a random control group shows how many orders the reminder added; opens and reads say the message arrived, not that anyone ordered because of it. So new customers with consent are assigned to two groups in advance. Both use one metric: at least one second paid order within 60 days of the first payment. Cancelled and refunded orders are excluded from the orders, while people stay in their assigned group even if the message never reached them.
Even customer IDs get the reminder, odd ones get none. This split is suitable only if ID parity is unrelated to date, channel, city or branch; establish that from an export before launch. If there is a relationship, first assign random experiment IDs, store them in the CRM, and split on those. Assign the group once the first payment and consent are recorded, before the flow acts, and keep it throughout the test. Other emails, order updates and frequency rules are the same for both groups.
Suppose the test starts at the end of October. The plan and calculation come from the retention experiment: detecting a rise from 25% to 33% at 5% significance and 80% power needs 473 people per group, 946 in total. At 3.33 people a day that means 285 days of recruitment and another 60 days of observation, 345 days in all, about 11.5 months. Before launch, record the recruitment deadline and the final reading on day 345. If either group then has fewer than 473 people with a complete 60-day window, report the shortfall and uncertainty; the test may end without a conclusion about the effect. Do not extend it based on the observed difference.
Schedule two checkpoints in advance: after three and six months of recruitment, about 150 and 300 people per group. Their complete results mature around months five and eight. These samples give about a 37% and 61% chance of detecting a true rise from 25% to 33%. The readings check data and harm: duplicate IDs, missing orders, complaints and opt-outs. The interim order difference does not select a winner or stop the test.
At the first checkpoint, the numbers might look like this:
| With reminder | Without reminder | |
|---|---|---|
| New customers in the group | 150 | 150 |
| Placed a second order within 60 days | 48 (32%) | 36 (24%) |
The difference is 8 points, about 12 extra buyers per 150 people. Half the width of the interval for a difference between two shares can be estimated like this:
half_width ≈ 2 * sqrt(p * (1 - p) * 2 / n)
Here p is the baseline share without the reminder, 0.25, and n is the number of people in one group. With 150 per group that comes to about plus or minus 10 points, so the interval for an 8-point difference runs from roughly minus 2 to plus 18. This is a provisional estimate, and the reminder cannot be credited with all 48 orders. At the next reading, with 300 per group, the interval narrows to about plus or minus 7 points; the final conclusion still waits for the scheduled reading.
One extra second order leaves the shop 6,000 ₸, from which the manager's time and sending cost still have to be covered. Run the flow according to the recorded plan unless errors or harm require it to stop. A weak interim result is no reason to add another three months, and a promising one is no reason to declare victory early.
Exercise: a spec for one flow
Take a flow your client already runs or wants to launch: an abandoned cart, a reorder reminder, an email after payment.
The coffee shop's mistake threatens any flow that waits for an order in one place when orders come from several. It turns up at the test-order step, as long as you run it with every payment method and not just a card. A pause "from an article" or "45 minutes, like a friend's shop" is a reason to pull the client's data: how long it usually takes them from cart to payment and between orders.
The same formula can cool down a plan. A salon with 20 new clients a month gets 30 people per group in three months, and at the same 25% rate the interval is about plus or minus 22 points. An 8-point rise can easily go undetected at that volume. The customer's need and the cost may justify launching the flow, but this sample cannot support a promise of measured growth.
The finished spec is a seven-row table like the shop's, three reasons to skip and a measurement plan with group sizes and timing.