The owner of an online coffee shop in Almaty sends you a screenshot. A customer paid 15,000 ₸ for an order and then, at 11:00, got an email saying "You forgot to finish your purchase". The shop's own flow would never have sent it: before every email it reads the order from the CRM again, which is how trigger flows work. This email came from the abandoned-cart scenario built into the email platform. That scenario takes the list compiled at 10:00 and never looks at the order status again.
The contractor immediately suggests buying a CDP "so all the data is in one place". Hold off. First find out what each system can see at the minute it sends a message: sometimes the systems the client already has can do the job. This is the shop from the customer value calculation, with the same economics; the numbers are illustrative.
What the system needs to know before sending
Take it minute by minute. The customer started checkout at 10:00, paid by card at 10:05, and the messaging system heard about the payment at 10:10. Under the shop's rules the reminder is due at 11:00, after a one-hour wait. If at 11:00 the system asks for the order status again, it sees "paid" and drops the email from the queue. The built-in scenario skips that step and sends everything that entered the queue at 10:00, and the customer is asked to pay for something they have already paid for.
How the shop's own flow cancels the reminder
10:00: checkout
The customer started checkout.
10:05: payment
The order was paid by card.
10:10: payment visible
The messaging system learned about the payment.
11:00: decision
The flow re-reads the order from the CRM and removes the email from the queue.
The platform's built-in scenario sent the old list without re-reading the status.
An email like that costs more than it looks. The customer may decide the payment failed and write on WhatsApp; a manager spends time replying, and some people unsubscribe.
The roles of CRM, CDP and the messaging platform
The CDP Institute defines a Customer Data Platform through a persistent, unified customer record that other systems can access. That record brings together website activity, orders and messaging permissions. The CDP links them into a profile; the workflow decides what to do with the customer.
These are two different jobs, and they are easy to mix up. You can stitch a profile perfectly and still send an email from an hour-old list. The reverse also holds: you can do without a CDP if the CRM receives every status you need and passes it to the messaging system in time.
For one reminder, the shop wrote down where each piece of information comes from and who owns the rule:
| Information | Where it comes from | Who owns the rule |
|---|---|---|
| Checkout start and cart ID | Website | Website developer |
| Order, payment method and delivery status | CRM receiving website and manager-entered orders | Shop owner |
| Confirmed payment | Payment records linked to the order | Person responsible for payments |
| Channel consent and its withdrawal | Consent form and the system receiving the unsubscribe | Marketer |
| Sending, delivery and the reason for a skipped message | Messaging platform | Marketer and integration developer |
Product names hardly matter here. Even if orders and emails live in one application, people own both rules, and the table should show exactly who. If the data sits in an external store, describe how the workflow gets it from there. A profile exists so that every system works from the same customer history. One more customer card on one more dashboard won't stop a single email.
Knowing which records belong to the same person
The same customer browses the catalogue on a phone, orders on a laptop and a week later messages a manager on WhatsApp. To the systems, that is three records. Linking them takes a reliable link between the website record and the CRM record. For the shop, that link is the account login: after a confirmed login, the website passes the customer ID along with the cart ID.
A similar name or a shared IP won't do for the link. A husband and wife order from the same home computer, and a whole family can share one phone number. Run a phone-based merge through cases like these before you trust it.
In the specification, write down what evidence was used to merge records and who can split them if the link turns out to be wrong. Signing out needs its own rule: the next person's activity on the same device must not be added to the previous one. In acceptance testing, two staff members take turns signing in to different test accounts on one device and check whose account each cart lands in.
The reminder needs customer, cart and order IDs, statuses, update times and channel permissions. Passport details and conversation text have no place in this flow. Agree field access and retention periods before connecting anything: every extra field adds work, and if something goes wrong the damage is bigger.
An event has two times
The payment went through at 10:05, but the system learned of it at 10:10, five minutes later. Keep only the receipt time and the report shows the customer paying later than they did. Keep only the payment time and you will never find the integration delay.
So an event carries both times, each with its time zone. Exports have a third one: the point up to which the source has passed on changes. An overnight order file can load completely and without errors and still be too old for a reminder an hour later.
The order in which records arrive can trip you up too. After "paid", a delayed "checkout started" record turns up. The workflow must not put the order back into unpaid just because that record arrived last. To prevent it, the developer compares the source record's versions or simply re-reads the current state, and writes the rule for corrections into the specification. A refund after payment is a new change as well, and it needs handling.
The shop's flow has nothing to fear from a late record: it reads the current order from the CRM before sending.
Check permissions and limits at the moment of action
At 10:00 the customer landed in the unpaid segment, and that is enough to start the wait. But by 11:00 they may have ordered, unsubscribed or complained, so the conditions are checked again before sending, using the list from trigger flows, from the order to message frequency.
Add one case to that list: the CRM is down and the current order cannot be read. The promotional reminder is then paused and the reason recorded. When the connection is back, the conditions are checked again. Otherwise the queue built up during the outage goes out all at once to people who have already ordered.
When a CDP is worth buying
Before signing anything, ask the contractor to demonstrate one path: cart, order, updated profile, cancelled email. If the client's CRM and messaging platform can already do that, this job doesn't need a CDP. The picture changes when unlinked records keep piling up between the website, the app and the CRM, and every new workflow needs its own matching. Then you compare two options: extend what exists or keep a shared profile in a CDP.
The budget is more than the subscription. Connecting sources, cleaning up duplicates, support, service subscriptions and handling errors all cost money, and one product's price is only part of the total.
Suppose the month's budget has 60,000 ₸ for services and another 60,000 ₸ for support, 120,000 ₸ in all. The shop keeps 6,000 ₸ per order, so covering that sum takes 120,000 / 6,000 = 20 additional orders a month. Any one-off launch fee comes on top.
Twenty orders after the emails are not twenty orders caused by them. Some customers would have come back anyway. The increase shows up in a comparison with a group that got no reminder, with the test length and group sizes set before launch. You can also justify a CDP by the manual work it saves, but then the team's hours and their cost go into the calculation.
Task: accept one workflow before buying a platform
Take a reminder from your own project: abandoned cart, reorder, any flow with a wait in it. You will end up with a data table and an acceptance record that you can take to the client to discuss implementation.
0 of 6 done
Say costs are 120,000 ₸ and 14 orders came in after reminders. Even if every one of them is additional, their contribution is 14 × 6,000 = 84,000 ₸, 36,000 ₸ short of the costs. A report on how many emails went out won't close that gap. To keep investing, you need either other confirmed results or lower costs.
Sometimes the manager-entered order test ends with an abandoned-cart email. Then the acceptance work has already found an error: the order from the CRM never reached the exclusion rule. Write down in the record where it failed and who will fix it. A new platform makes sense once you can say which part of that work it will take off the team.
Video: CRM, ESP and CDP
As you watch, match the systems' roles to your table: where the order is stored, where messaging permission lives and who decides whether an email goes out.