Abandoned cart automation, step by step

1. Decide when you consider a cart abandoned.

Adding a product to the cart signals interest, but it doesn't mean the shopping is over. The customer may be comparing offers, come back later or buy in the same visit. That's why you need a process definition: which event triggers the scenario, how long you wait and which purchase rules out any further action.

The Flowpeek template starts after an add-to-cart, waits three hours and then checks for a recorded purchase event by that visitor in the last 24 hours. These parameters are a starting point for configuration. The condition doesn't confirm that the order was paid, that exactly the abandoned products were bought, or that the purchase happened after that specific add-to-cart. Adjust the logic to the goal of your communication.

Plan pre-cart actions separately. They can be triggered by viewing a listing or by a Flowpredict score, without a product being added first. If you want to exclude recorded carts, use the product interest condition: any product, add to cart, at least one, selected period — and take the "NO" branch. Check for the absence of a purchase separately. One label for every stage makes it hard to match the message.

2. Lay out the four elements of the scenario.

The trigger answers the question "when to start." The delay gives the customer time to finish the purchase naturally. The condition checks the situation once that time has passed. The action passes the result to the connected tool. Separating these steps helps you avoid a message sent the instant someone clicks the cart.

In the available GetResponse template, the no-purchase branch adds the tag porzucony_koszyk (abandoned cart) and increases the contact's score by 10. The purchase branch adds the tag kupil_po_koszyku (bought after cart). The tag name is the scenario's label; the condition actually checked still covers the last 24 hours. The label and score help you choose a group of contacts and trigger further rules in GetResponse. Running these actions alone doesn't mean a message is sent.

The screenshot shows a variant of this process: the wait has been shortened to 30 minutes, and both branches end by adding a tag. The "YES" branch gets kupil_po_koszyku and the "NO" branch gets porzucony_koszyk. This screen doesn't show an extra score change. Comparing it with the table teaches an important rule: behavior is determined by the saved parameters and blocks, not by the template's name.

3. Check the signals and the contact first.

Walk through a controlled journey in the store and confirm that add-to-cart and purchase are being recorded. If order syncing takes longer, factor that into the delay you choose. No visible purchase at the time of the check may mean the data hasn't arrived yet, not that the cart was actually abandoned.

In the profile shown, a score of 71 comes with a cart and no purchase, but the visitor is marked as anonymous. That's not a contact ready for tagging. Check recognition in Flowprofile, the link to the chosen platform and current consent. An address in another system or a high-intent label doesn't replace a confirmed connection.

Before publishing, create or select a specific tag in the platform and decide which rule it will lead to. Write down its meaning: "cart without purchase within window X," not a generic "customer for promotion." That way you can later check whether the tag is still current and which process should remove it.

4. Match the action to the connected platform.

Pick an action available in your integration. GetResponse supports tags, fields and contact scoring, among others; Klaviyo — profile properties, lists and events; MailerLite — groups and fields; ActiveCampaign — tags, fields and lists. Ecomail has tags and a list, and ExpertSender ECDP supports attribute updates. These are different ways of passing on information about a contact, not identical blocks.

edrone has a separate scope: syncing customers who gave consent at purchase, plus withdrawal or deletion. Don't automatically carry the GetResponse wizard instructions over to it. In each platform, check the rule, the content and whether the communication actually runs.

5. Set re-entry and communication controls.

Decide whether a visitor can enter once, after a break or every time the condition is met. Flowpeek doesn't run parallel instances of the same scenario for the same visitor ID. That's not a global limit for a person across all devices.

Check existing cart campaigns and messaging limits in the platform. Assign one process responsible for the reminder so that tagging doesn't trigger overlapping offers. If you add an ML condition, it reads the score available at the moment the contact passes through. To react to a later score on its own, configure an ML trigger that is evaluated periodically.

6. Add a separate rule that ends things after a purchase.

The condition after the delay only checks the state at the moment it runs. The customer may buy later, after the porzucony_koszyk tag has already been added. The "YES" branch that adds kupil_po_koszyku doesn't remove a previously added tag either. That's why you need a separate flow that reacts to a purchase.

Set a purchase trigger and the "Remove tag" action in GetResponse. Select the existing porzucony_koszyk tag; if you also use intent tags, add separate actions that remove the relevant labels. Running them still requires an active link and the required consent conditions. On the platform side, define what the tag change means for the segment, the queue and any communication that has already started.

The screenshot below shows a different customer: three visits, 22 page views, one PLN 669 order and the status "Purchase completed." It's evidence of the state visible in the app, not confirmation that the customer received a message or that the tag was removed. Check those in the action history and the target platform.

7. Test both branches and the skipped cases.

Save a draft, check the settings and run the validation before publishing. Activating an event-based scenario starts watching new events; it doesn't replay all past carts. Run the cases from the protocol at the end of this guide: no purchase, purchase before the check, purchase after tagging and consent withdrawal.

For each test run, compare the Flowpeek history with the state in the platform. Skipping after consent is withdrawn may be correct; an error calls for diagnosing the connection or the action. Also note whether adding to the cart again behaves according to the entry rule you chose.

8. Write a message that fits the situation.

Start by helping the customer finish the purchase. They may need an answer about size, compatibility, shipping or payment method. Don't default to a discount for every abandoned cart. Check the economics of the offer and whether an existing process already promises a different deal.

The content should match the scope of data you actually have. If the condition doesn't identify the exact products in the abandoned cart, don't imply that level of precision in the message. Also make sure the offer is current and that unsubscribes are handled in the target platform. Assess the legal requirements for the channel and the basis for communication in the process appropriate for your store.

9. Measure process performance and sales separately.

First evaluate the process: event recognition, conditions passed, tagging and tag removal after purchase. Include skips and errors. This checks that the configuration runs, not the message's impact on sales.

Evaluate the business result separately. Set the period, the purchase attribution rule, the cost of the discount and the comparison method, including a control group if you use one. Some customers would have come back without a message, so don't call all subsequent sales recovered. With a small number of events, keep collecting observations.