Existing flows and new product added

@Jimg - Welcome to the community, and this is a great topic to discuss.  I’ve done this so many different ways and seen different approaches to what you are experiencing.  I’ve found the approach highly depends on the various tradeoffs you prefer and how you intend to scale, and whom else besides you might be involved in your Klaviyo implementation.

The two general approaches I’ve seen, are what I call the “Depth First Method” vs a “Breadth First Method” - allow me to explain!

Depth First Method - In this approach, you have the classic Core Flows, but each Flow is highly intricate and has many logic branches based on different behaviors. I’ve seen complex Flows where it spans pages and pages of branches and conditions, with convoluted logic, and dozens of messages within the Flow. Each Flow is deep and complicated - hence the name! Here are the Pros/Cons:

Pros: 

• Flow management at the highest level is simple as there are fewer number of Flows, and the triggering conditions are unique to each Flow.  For example, there’s “One Flow for each Event or List/Segment Subscription” - so for example, if you want to get to the Cart Abandonment Flow, there’s exactly one place to look.
• Although the Flow is large and complex, they are all on a single “page”, and you can trace it to see performance at any point in the Flow using the “Show Analytics” feature.  Making “at a glance” performance review easier to spot and fix when you are looking inside a Flow.
• In many cases, you can route people to the same message(s) within a Flow wherever a common message is applicable, so there will less duplicative messages across your Klaviyo account.  Aggregate performance data for each message is easier to evaluate since it’s not spread out across different Flows.

Cons:

• Flows are super complex and tracing the various steps and logic branches can be overwhelming.  Each time you come back to the Flow, you have to wrap your mind around what’s going on.
• Aggregate Data at the Flow Level might not make as much sense as there are so many conditions and branching logic going on.  Reporting on Flow Performance becomes more of a chore, because each branch or message in the Flow might relate to completely different contexts.
• Usually super complex Flows are hard to understand, so delegating out to other team members, and outside agency or consultant, is a monumental task for them to even get started.  

Breadth First Method - In this approach, you have many Flows that may trigger on the same event or the same List/Segment - in fact, for every Core Flows, there may be multiple Flows depending on the Flow Filter to route different types of users to the correct Flows. Although there are lots and lots of Flows, each one is “light” and less complex, because the complexity was setup in the Flow Filter, and each Flow represents a small functional objective.

Pros:

• Since there are many Flows to address different conditions, each Flow in itself is less complex, and typically easier to understand once you’re looking inside the Flow.
• Since each Flow is distinct, aggregating reporting by Flow is clear and simple and you can get a quick high-level glance at the performance of the various sets of Flows.  In many cases, if Revenue is your KPI, you can just look at “Revenue per Flow” (as oppose to revenue at each message in a Flow)
• Because each Flow is smaller and distinct and addresses a unique concern, it’s easy to delegate across team members to be responsible for specific Flows without them having to know the “whole picture” of what’s going on to make improvements or adjustments.  Although it may take someone who’s super comfortable to set everything up, people who are less experienced in Klaviyo can easily maintain or improve subsets of the Klaviyo account.  Example, a less experienced person can be focused on the “Cart Abandonments for VIPS” while another person can be focused on the “Cart Abandonment for Subscription Products” etc.  Everything is easier to piecemeal.

Cons:

• Having lots of duplicative Flows, may have duplicative messages between Flows.  So sometimes making simple changes to a message in one Flow, means you have to update it in many places as well. 
• You would have to judiciously use Flow Filters and/or Message Filters to make sure a person doesn’t get into two or more overlapping Flows at the same time.  Managing these Flow exclusivity can be cumbersome at scale.
• You may find you’re making lots and lots of Flows, so proper and consistent naming convention and tagging need to be employed to keep everything in order.
  Example:
  • welcome-series_customer-type_A_product-category_A
  • welcome-series_customer-type_A_product-category_B
  • welcome-series_customer-type_B_product-category_A
  • welcome-series_customer-type_B_product-category_B

Which approach you choose, is really up to what makes the most sense in your organization and more importantly how you plan to scale. 

You can of course have a hybrid, where certain Flows are complex and long, and certain flows are fanned out with Flow Filter conditions. 

I would Love to hear other people’s opinion on this too!

Thank you Joseph.  I appreciate your answer.  We are currently using the breadth method for the most part.  My issue is as stated above not the creative side of things, but the logic behind the flows and the creation of logic that does not conflict.  

Our website is premoguard.com.  Have a look (our new products are listed as new) and lets chat further if appropriate.  

Hi @Jimg,

Love the pro/con breakdown outlined by @retention! One additional thing to point out is that if you decide to go the “Breadth First Method” (multiple flows rather than all in a single flow), we do offer a feature called Smart Sending. Smart sending prevents over emailing especially if you have a bunch of flows live in the account. Hopefully, this can give you peace of mind if you end up setting up a bunch of different flows in the account!

Best,

Julie