Klaviyo flows: the complete guide

Every flow, however complicated it looks, is made of four things. Understanding them separately is what stops a build turning into guesswork.

The trigger is the event that puts someone in. It can be something they did in your store, such as starting a checkout or placing an order, joining a list, a date on their profile coming round, or a price changing on something they looked at. The trigger decides the moment, and the moment is most of the value.

The filters decide who stays. There are two kinds and mixing them up is the single most common build error. One kind is checked once, at the moment of entry, and decides whether the person joins at all. The other is checked again before each message, and removes people whose situation has changed since they entered. A cart recovery sequence needs the second kind, because the whole point is that people who buy should stop receiving it.

The timing is the set of delays between steps. These are not decoration. The gap between the trigger and the first message, and between each message after it, is often the difference between a sequence that works and one that annoys people, and it should come from how your customers actually behave rather than from a template.

The actions are what happens: send an email, send a text, update something on the profile, or split the path based on a condition. Splits are where flows get powerful and also where they get unmaintainable, so use them where the message genuinely needs to differ and not merely because the option exists.

Sketch all four on paper before opening the builder. A flow diagram on one page, with the trigger at the top, the filters written out in plain language, the delays marked in hours or days, and a one line summary of each message, takes twenty minutes and prevents most of the rework.

Flows can only react to data the platform receives, so the integration comes first. Building a sequence and then discovering the event that should trigger it is not being recorded wastes a week and produces a flow that silently sends to nobody.

Connect the store properly and confirm the events are arriving. The essential ones are viewing a product, adding to cart, starting checkout, placing an order, and the fulfilment and delivery updates if your platform supplies them. Place a test order yourself and watch each event land on your own profile. It takes ten minutes and it is the only way to be sure.

Sync the product catalogue too, because that is what lets a message show the actual item someone looked at along with its image, price and link. A cart recovery message that names the product outperforms one that says you left something behind, and the difference is entirely down to whether the catalogue is connected.

Check what customer data is arriving beyond the events. First name if you collect it, location, the source they signed up from, and any properties you set yourself such as which category they bought from or whether they are a wholesale account. Every one of these is a filter or a personalisation you can use later, and none of them can be added retroactively.

Set up the tracking links so orders can be attributed. Consistent campaign parameters on every link mean your analytics and your email reporting are talking about the same thing, which saves an argument every month.

Finally, decide what should not be sent in. Sensitive product information, anything you would not want stored outside your store, and personal data you have no use for. Collecting less is easier to maintain and safer, and nothing in a flow benefits from data you never filter or personalise on.

Three different things can define who receives a message, and choosing the wrong one is why flows send to people they should not. Learn the distinction once and the rest of the build gets easier.

A list is a static group people join and leave. It is the right home for consent: someone subscribed at checkout or through a form, and that membership is a record of permission. Lists are for who agreed to hear from you, not for who is interesting this week.

A segment is a live definition that recalculates itself. Anyone who matches the rules is in, and the moment they stop matching they are out, with no manual work. Customers who bought in the last ninety days, people who have ordered more than twice, subscribers who have not opened anything in six months. Segments are for describing situations.

An event is something that happened at a point in time. It is what most flows are triggered by, and it is the only one of the three that carries a moment with it.

The practical rule is that consent lives on lists, targeting lives in segments, and timing comes from events. Flows triggered by joining a list are for onboarding. Flows triggered by an event are for reacting. Segments then sit inside those flows as filters, deciding who among the entrants should actually receive each step.

One trap worth naming. Building a flow triggered by someone entering a segment feels convenient and behaves in ways people find surprising, because segment membership can flicker as data updates and someone can enter more than once. Use it deliberately and sparingly, with a filter preventing re-entry, and prefer an event trigger whenever one exists that describes the same moment.

Name everything clearly as you go. In a year, whoever inherits the account will need to work out what each list and segment is for from its name alone.

Build the sequences that touch people closest to a purchase first, then work outwards. Doing it in this order means the account is earning while the rest is still being built, which also makes it much easier to keep the project funded.

Start with checkout and cart recovery. These people chose a product, entered your checkout and stopped. They are the warmest audience you will ever message and the flow can be live in a day.

Second, build the welcome sequence for new subscribers. Everyone who signs up meets it, it introduces the brand properly, and it converts a portion of people who joined for a reason other than buying.

Third, build the post purchase sequence, covering the period from order to arrival and the weeks after. It reduces support messages, it sets up the review request and it is where the second order begins.

Fourth, add browse follow up for people who viewed products and left without adding anything. It is a colder audience than cart recovery and needs a lighter touch, so it belongs after the first three rather than instead of them.

Fifth, add the flows that depend on your catalogue. Replenishment reminders timed to how long the product lasts, if you sell consumables. Back in stock notifications if you sell out of things. A winback for customers who have gone quiet, timed from your own reorder gap.

Do not build all of them at once. Each flow needs its trigger checked, its filters tested and its timing reviewed after real people have gone through it, and a batch of seven launched on the same day gives you nothing to learn from. Launch one, watch it for a fortnight, fix what the data shows, then start the next.

The trigger decides when, the filters decide who, and most flow problems people describe as bad copy are actually filter problems. Someone got a message that was wrong for them, and no amount of rewriting fixes that.

Choose the most specific trigger available for the moment you want. If you want to reach people who reached checkout, trigger on checkout started rather than on adding to cart, and build a separate flow for the earlier moment. Two precise flows will always beat one flow with a pile of conditions inside it trying to serve both.

Then write the entry conditions. These decide who joins at all and are the right place for permanent qualities: is this person subscribed, is this their first order, is the cart above a value where a follow up is worth it, is this a wholesale account that should be excluded entirely.

Separately, write the conditions checked before each message. These handle the things that change while somebody is in the flow, and the most important is the obvious one: stop sending recovery messages to a person who has bought. Every recovery flow needs this, every store has seen it go wrong, and the resulting message reaches a customer who has already paid and reads as though nobody is paying attention.

Exclude the people who should never be there. Recent buyers who do not need a welcome discount, addresses that bounce, anyone who has asked for less contact, and internal test accounts. Building an exclusion segment once and applying it across flows is cleaner than repeating the same conditions in every build.

Finally, decide what happens if someone triggers the flow again. A person who abandons three carts in a week should not receive three overlapping sequences. Set the re-entry rule deliberately, and where the platform lets you choose, err towards not letting people back in too quickly.

Take the timing from your own data, not from a default. Look at the gap between a cart being abandoned and the orders that still happened, the gap between order and delivery, and the gap between first and second order per category. Those three numbers set most of the delays in your whole account.

The first delay is the one that matters most. Too short and the message arrives while the person is still deciding, sometimes while they are literally on the checkout page. Too long and the intent has gone. For cart recovery, most stores land somewhere in the first hour or two, but the honest answer is to test two settings against each other rather than accept a number from a guide.

Mind the clock at the other end. A delay measured in hours will eventually deliver at three in the morning for somebody, so use whatever the platform offers to hold messages until a reasonable local hour, except where the message is genuinely time critical.

Splits should exist for a reason you can say out loud. Good reasons: first time buyer against repeat customer, high value cart against low value cart, one product category against another, subscriber against non subscriber. Bad reason: it seemed like it might be interesting. Each split doubles the number of paths you have to maintain and halves the data in each one, which makes it harder to tell whether anything is working.

Where a split exists, make sure both paths are genuinely different. If the two versions differ by one sentence, put the sentence in a conditional block and keep one path. If they differ in offer, timing and structure, the split is earning its keep.

Finally, decide how long the sequence runs. Most flows have a natural end, and continuing past it converts almost nobody while adding unsubscribes. When a sequence stops producing orders after the third message, the fourth is costing you more than it earns.

Use the data you have and nothing else, because a message with an empty space where a name should be looks worse than one that never tried. Check every personalised field for what happens when it is missing, and set a fallback for each one.

The personalisation worth doing is product level. Show the item the person looked at, with its image, name, price and a link that goes straight back to it. Show the size or variant if you have it. In post purchase messages, name what they bought and speak about that product specifically. This is where the catalogue connection you set up earlier pays off, and it consistently matters more than using someone's first name.

Second most valuable is context. Referring to the fact that this is their third order, or that they bought the same thing four months ago, or that the item they wanted is back, all make the message read as though it came from a store paying attention.

Recommendations are worth including where they are based on real behaviour: what people who bought this also bought, or the accessories that fit the item they own. Recommendations based on nothing are just a product grid, and a product grid at the bottom of an email is fine as long as nobody pretends it is personalisation.

Be careful with anything that could feel like surveillance. Naming the exact time somebody looked at a page, or referring to browsing they did not realise was recorded, unsettles people even when it is technically accurate. Use the data to be useful and relevant, not to demonstrate how much you know.

And keep the fields honest. If your data cannot tell whether someone is a first time or repeat buyer, do not write copy that assumes one. It is better to write a message that works for both than a sharper one that is wrong for half the recipients.

Once several flows are live they start overlapping, and a customer who receives four automated messages in a day will unsubscribe no matter how good each one is on its own. Set the global rules before that happens rather than after somebody complains.

Start with the platform level protection that prevents sending to the same person too often, and understand exactly what it covers. Turn it on for every flow message except the ones where a delayed send would defeat the purpose, such as an order confirmation or a back in stock alert for a scarce item.

Then map the collisions deliberately. Write out every flow and the moment it fires, and look for the pairs that can trigger together. Someone who orders while a browse follow up is running. Someone who joins the list and immediately abandons a cart. Someone in a winback sequence who buys. Each pair needs a rule, and usually the rule is that the more specific flow wins and the broader one pauses or exits.

Decide the priority order once and apply it everywhere: transactional messages first, then recovery, then onboarding, then broadcast campaigns. When two want the same person on the same day, the one closer to a purchase goes and the other waits.

Exclude people in active flows from campaign sends where it matters. Someone working through a five message welcome sequence does not also need the weekly newsletter that week, and suppressing them costs you nothing.

Finally, put a cap on total automated messages per person per week and check it against reality by pulling your own profile and any test accounts and reading the full send history. Looking at what one real person received over a fortnight tells you more about your account than any report, and it is the check almost nobody runs.

Preview screens hide the faults that matter, so test by going through the flow yourself as a real customer. Use a fresh profile with an address that has never interacted with the account, then genuinely do the thing that triggers the flow.

Work through the whole path. Abandon a real cart with a real product. Wait for the actual delay rather than skipping it, at least for the first message, because timing bugs only appear in real time. Read what arrives on a phone. Click every link and check where it lands, including whether the cart is still there when you get back, since a recovery message that returns someone to an empty cart wastes the whole sequence.

Test the awkward cases as well as the happy path. What arrives for a product with no image. What the message says when the customer's first name is missing. What happens when the cart contains six items rather than one. What happens if someone buys after the first message, which should stop the sequence and often does not.

Check the message rendering in both light and dark mode and with images blocked, and read the plain text version if the platform generates one.

Then check the reporting side before you announce anything. Confirm that orders from the flow are being attributed, that the links carry the parameters you set, and that the numbers in the flow report and the numbers in your analytics move together. Discovering three months later that a flow was working but not being credited is a common and avoidable annoyance.

When it goes live, watch the entry count in the first days. A flow with far fewer entrants than expected almost always has a filter that is stricter than intended, and that is easy to fix in the first week and embarrassing to find in the sixth month.

A flow keeps sending long after the facts inside it change, so put a recurring review in the calendar and treat it as maintenance rather than optimisation. Most of the damage automated sequences do comes from being right when they were built and wrong a year later.

Every quarter, read every live message end to end as a customer would. Look for discontinued products, out of date delivery times, offers that have ended, links to pages that no longer exist, and references to a season that has passed. This costs an hour and it is the highest value hour in the account.

At the same time, check the numbers per flow rather than in aggregate. Entry counts, whether each message is still producing orders, and where in the sequence people unsubscribe. A message that generates unsubscribes and no orders should be cut, not rewritten, and cutting it usually improves the flow.

Revisit the timing annually against fresh data. Reorder gaps change when you add products, delivery times change when you change carrier, and the delays that were right two years ago may now be firing a fortnight late.

Keep a change log. One line per change with the date, what changed and why, kept beside the flow. Without it, nobody can tell whether a shift in performance came from a change you made or from something else, and the same debate repeats every quarter.

Finally, remove flows that no longer earn. Accounts accumulate sequences built for a campaign that ended or a product that was discontinued, and they sit there quietly consuming attention and occasionally sending. Turning off a flow is a legitimate result of a review, and an account with six well maintained flows is worth more than one with twenty nobody has read since launch.