How to stop Klaviyo flows overlapping when cart and browse fire together

Two healthy-looking flows, ganging up on one inbox

Open the flow report and nothing looks wrong. The cart flow shows steady opens and steady revenue. The browse flow shows the same, and both dashboards are telling the truth. Neither one records that a single customer just got both messages inside half an hour.

That's why the overlap survives for years. Each flow reports healthy on its own, so the only person who ever sees the problem is the customer, and the customer doesn't file a report. They just decide your emails are a bit much and quietly stop opening either one.

We find this in most of the accounts we take over, and not as some rare misconfiguration. It's close to the default state, because nothing in Klaviyo stops it for you. You have to build the check yourself. Most accounts never have.

Klaviyo treats every flow as its own closed system

Cart and browse abandonment run on different trigger metrics. The abandoned cart email fires off Started Checkout or Added to Cart, the browse abandonment email fires off Viewed Product, and each one is a sealed machine that knows nothing about the other. Qualify, clear the delay, send.

So a customer adds something to the basket and the cart flow starts its clock. They view anything else in the same session, which nearly everybody does, and the browse flow starts a second clock. Two timers, one inbox.

None of this is a bug. It's what happens when two flows get built in isolation, months apart, and nobody goes back to wire them together. In the accounts we inherit, that's the rule and not the exception.

A list membership filter fixes what a longer delay postpones

The instinct is to push the browse flow's delay out and hope the gap does the work. That just moves the collision to a different hour. What holds is a priority decision, enforced by a flow filter checking list membership.

1. Create a plain list called something like Recent Cart Activity, with nothing else attached to it
2. At the very top of the cart flow, before any time delay, add an action that adds the profile to that list
3. In the browse flow, add a flow filter directly before the send step: has not been added to Recent Cart Activity
4. Give the browse flow a short wait before that filter runs, so a cart add moments later is still caught
5. Let profiles that fail the filter exit the flow instead of receiving the email, which is the whole point

The wrong version is the one we see constantly. Browse fires off Viewed Product and sends, blind to everything else happening on the profile. The right version reaches the send step, checks the list, and steps aside because the cart email already owns the conversation.

Decide which flow should win before you touch a filter

The filter only works if you've decided, on purpose, which flow wins. Cart should almost always take it. Adding to a basket is a stronger signal than viewing a page, and somebody mid purchase needs a nudge to finish, not an introduction to a different product.

That decision dictates the wiring. The add to list action lives at the top of the cart flow, the instant it triggers. Put it after a wait step and the browse filter can run before the profile is on the list, at which point your block does nothing at all.

There's a reversed case worth planning for too. Somebody views a product first, the browse email queues, and only then do they add something to the cart. The short wait at the start of the browse flow is what gives the cart flow time to mark its territory before the filter looks.

Run a test profile through both flows before you trust it

• Trigger Viewed Product on a live product page with a test profile
• Trigger Added to Cart on a different product straight afterwards
• Watch both flows in the flow view and confirm the browse profile exits at the filter, not at the send
• Open the list itself and confirm the profile arrived before the filter check ran
• Repeat with the order reversed, cart first and browse a few minutes later

Do that once properly and you won't need to keep checking it. Re-run it whenever either flow's structure changes, because moving a single action can quietly shift where the filter sits against the list add. An edit that looks cosmetic can undo the sequencing, and no error appears anywhere.

Any two flows sharing an audience can collide the same way

Back in stock and browse. Winback and post purchase. A replenishment nudge landing on top of a campaign. Any pair of flows with a shared audience and a similar send window can double up exactly as cart and browse do, and once the list and filter pattern exists in the account, copying it across those pairs is mostly an afternoon's work.

One honest caveat before you rebuild anything. If your traffic is low enough that cart and browse rarely fire on the same profile in the same hour, the collision may barely exist for you. Check your own send data for real overlap first, then fix the pairs that actually collide.