A customer pays for her order, and some time later gets an email: "You forgot to complete your purchase." The marketer sees in the report that the flow fired. The customer sees a shop that has no idea who she is. A CRM flow only works when the customer data, the action and the offer terms agree with each other.
All three problems are about an online shop in Almaty with a 20,000 ₸ basket; the numbers and situations are made up. Write down your answers before you read the explanations. There is no score: you check yourself.
Problem 1: a hundred buyers are written off as lost
An export holds 100 buyers who have one order each so far. For 40 of them, the first purchase was less than a week ago; for the other 60, more than 30 days have passed. The team calls the whole hundred lost and wants to send a repeat-order discount.
What is actually known about these people, and what has the team assumed? What data do you need to compare repeat purchases? Can you work out the repeat-purchase rate from this export?
The team wants to measure a repeat paid, non-cancelled order within 30 days of the first purchase. Explain who goes in the numerator, who goes in the denominator, and what to do with people whose 30 days have not passed yet.
Problem 2: payment arrives while the email sits in the queue
A visitor abandons a cart, and the system queues a reminder. Then they pay for the order. The purchase is confirmed and linked to the same customer, but the unfinished-purchase email still goes out.
Where does the condition need to be checked again, and what should take the person out of the flow? Name the cases you would test the fix on. And what information about the sending queue and the way payments reach the system are you missing before you can promise that no such email will ever go out again?
Problem 3: a discount is supposed to bring more orders
An item costs 20,000 ₸. The goods, picking and delivery cost 12,000 ₸ per order, and in this problem those variable costs do not change with the discount. Without the promotion the team expects 100 orders over the chosen period; with a 10% discount it forecasts 120.
Work out the contribution per order and the total contribution in both cases, before advertising and fixed costs. Find the smallest whole number of discounted orders that keeps contribution where it was. Then list the assumptions you would need to confirm before launching a promotion on this forecast.
Explanation for problem 1: how much time has passed and who was exported
One order in the export is the state as of the export date. The export cannot tell you why the person has not come back. Some have not run out of the product yet, some did not like it, and some ordered again under a different ID. Each reason needs its own response.
The forty recent buyers have not had their 30 days. Mark their result as incomplete and keep the first-purchase date. Giving them a zero for days that have not happened yet is wrong: you would be writing off people who simply have not had time to return. The other sixty have a closed window, but before drawing any conclusion, link all orders of the same person and apply one rule to cancellations and refunds.
The second trap is in the export itself. Only people with one order were selected; everyone who had already come back was cut out. So these hundred rows cannot give you the overall repeat-purchase rate. You need the whole first-purchase cohort, returning buyers included.
The denominator holds every buyer in the cohort whose window has closed. The numerator holds people from that same group with at least one qualifying repeat order within 30 days of the first. A person with several repeats counts once in the numerator. Take dates and payment status from one order register agreed in advance, and treat cancellations and refunds the same way for every group.
The 30 days come from the problem. For a different product, you choose the window by the task and by how quickly the product gets used up, and you compare groups on the same horizon. A 60-day result or a repeat order on exactly day 30 is a different definition and cannot be swapped in here.
Pick the message once you know the group and the reason. If someone has not figured out how to use the product, an instruction will help and a discount will not. If they were going to buy anyway, the discount takes a slice of contribution and brings no extra order. And you can only write to people who agreed to receive this type of message on these terms.
Explanation for problem 2: what changed while the email waited
A check made when someone enters the flow goes stale while the email waits in the queue. So before sending, the system asks for the order status again and drops the reminder if the purchase is already confirmed. Build the exit in from the start, as in trigger flows with a pause and a pre-send check.
A check before sending the reminder
Email queued
The entry check may be stale
Purchase confirmed
Retrieve the current order state again
Cancel the reminder
Exclude the email before delivery handoff
Provide a way for the person to exit the flow
Cancellation depends on timely payment data and queue capabilities. It may be unavailable after delivery handoff.
That is a requirement for the flow. Whether it can be met depends on two things: when the system learns about the payment, and how late it still lets you cancel a send. So Akerke, who runs the shop's CRM, walks one order end to end with the developer: payment confirmation, the order register, transfer to the CRM, matching to the customer, and the queue's decision.
If the email has already been handed over for delivery, there may be nothing left to cancel. If the payment event arrives late, the check sees the old status. You can promise "no reminder after payment, ever" only when the whole chain allows it, and any delay you find has to be designed into the flow.
The test cases are: a cart with no purchase, a purchase before the send, a delayed payment, the same event arriving twice, and the person entering the flow again. For each, keep the order ID, the event sequence and the sending decision. For a paid purchase there is one right result: the reminder about that particular purchase did not go out.
Payment confirmations and other emails the buyer needs run as a separate process. A rule like "send nothing after a purchase" fixes one complaint and creates another: the person never hears what is happening with their order.
Explanation for problem 3: revenue and contribution move in opposite directions
Without the promotion, an order leaves 20,000 - 12,000 = 8,000 ₸ of contribution. A hundred orders give 800,000 ₸ before advertising and fixed costs.
With a 10% discount the price drops to 18,000 ₸. Costs per order are still 12,000 ₸, so contribution is now 6,000 ₸. If the forecast of 120 orders comes true, that is 120 × 6,000 = 720,000 ₸.
| Metric | No discount | 10% discount |
|---|---|---|
| Order price | 20,000 ₸ | 18,000 ₸ |
| Variable cost per order | 12,000 ₸ | 12,000 ₸ |
| Contribution per order | 8,000 ₸ | 6,000 ₸ |
| Forecast orders | 100 | 120 |
| Revenue | 2,000,000 ₸ | 2,160,000 ₸ |
| Total contribution | 800,000 ₸ | 720,000 ₸ |
Forecast revenue goes up by 160,000 ₸, while contribution drops by 80,000 ₸, or 10%. A report with only orders and revenue will never show that gap.
Keeping 800,000 ₸ takes 800,000 / 6,000 = 133.33 orders. Orders only come in whole numbers, so take 134: they give 804,000 ₸, while 133 give only 798,000 ₸. The threshold leaves out the cost of running the promotion itself. Add those costs and you need more orders.
Both 100 orders without the promotion and 120 with it are still forecasts. To see the effect, you need a comparison with a similar group or period without the discount, and a long enough stretch to tell whether purchases were added or people just bought earlier. Refunds, a shift in basket mix and the cost of preparing and running the promotion also go into the calculation. Future repeat orders can sit in a separate scenario, but they count towards contribution only once they happen.
Exercise: describe your flow and your discount decision
Take one CRM flow from your own project. Write down the entry, the check before the action and the exit condition. Add where the current status comes from, who is responsible for passing the data, and one record you can use to trace the outcome. Work with test data you are allowed to use.
Then write a short decision on the shop's promotion: is a forecast of 120 orders enough to keep contribution? And what changes if orders reach 134?
A workable flow description shows when the check runs and on what data. "Keep an eye on purchases" is not enough: whoever sets up the flow needs to know which ID and status drop the reminder, and where to see that it really was dropped.
On the promotion: 120 orders give 80,000 ₸ less than the original contribution. 134 orders cover the original 800,000 ₸ only under the problem's assumptions and leave a 4,000 ₸ margin before any extra costs. That is a threshold from a calculation; it does not show that the discount works. The next decision needs data on demand, the full cost of the promotion, and a comparison with the purchases that would have happened without it.