Hello @Nikki,

At this time, Klaviyo does not offer the ability to differentiate between locations when using Klaviyo's pre-built Back in Stock option for Shopify. The only way to achieve this would be to create two separate Klaviyo accounts (one for the physical store and one for retail store) and connect a unique Shopify URL (store) to each Klaviyo account and run each independently with their own respective Back in Stock flows.

That said, the ability for Klaviyo to distinguish between location-based inventory for Back in Stock is a previously requested feature and I have added your insight to our existing feature request.

We appreciate your patience and understanding with the current limitations. In the meantime, as another alternative, you can consider incorporating elements of the custom Back in Stock abilities outlined here: Shopify Back in Stock for Developers. If you’d like assistance with this, I recommend reaching out to one of our partners.

Thank you and have a great weekend.

Okay, great! 

Thank you!

Hi @Dov , 

I have a follow up question on the back in stock flow and multiple locations.

We sell mainly online but have a few other locations (department stores) that sometimes get some restock and at the moment Klaviyo can’t make the difference and therefore contacts customers about new porducts available when they are not.

What is the key field that is used for the back in stock trigger?  Could a workaround be to create a different SKU or Product name in Shopify for in store products for us to track online vs in store stock for example?

Thanks,
Quentin

Hi there @quentin

You are right that there is no differentiation between brick-and-mortar for Shopify. 

Unfortunately, Klaviyo cannot distinguish between location-based inventory for Back in Stock. That said, this is a widely requested feature, and I have added your insight to our existing feature request. Although I cannot provide you with an exact timeframe yet, our Product Team is working hard to release this feature sometime this year. 

We appreciate your patience and understanding with the current limitations. In the meantime, you might consider incorporating elements of the more custom Back in Stock abilities outlined here: Set Up Back in Stock via API

For example, you can use Shopify's Location Inventory API's to retrieve location-specific inventory information about your items, then send that information into Klaviyo. From there, you can use that information to set filters which would prevent Back in Stock emails from going out to recipients who have Subscribed to Back in Stock for items that are only in stock in your physical location. 

Another workaround solution would be to create a Category within your Shopify Store that is titled OUT OF STOCK. As long as you actively manage/update this Category to reflect the items that are out of stock, you can easily add the following Trigger Split to your Back in Stock Flow: 
​

I hope this helps you to achieve your goals in the meantime.

Alex

I would also like to throw my hat in the ring - the ability to differentiate between unique warehouse locations for the BIS flow would be HUGE and is overdue. I’ve had to cancel out hundreds of users in my BIS flow to prevent them from errantly receiving a BIS notification when in fact the product is still out of stock in the warehouse visible to them. The downside to this, of course, is that now those requests are now longer in the queue, so those users will never receive a BIS notification. This is not the functionality we were hoping for and is causing frustration for my brand and also for our shoppers. Please put this on high priority at Klaviyo!

Hi there @AJ_Allen,

We appreciate the feedback and although I cannot provide updates at this time, it is indeed on our Product team’s radar as an important update to include for the future.

A workaround or method I can suggest is that you could tag each customer’s profile with a location and then set up BIS Flows for specfic segments with certain tags or profile properties. Or set flows to manual until the products are not out of stock and then let emails send after.

All the best,

Alex

Hi, any updates on this one?

Shopify provides an onlineSellableQuantity in its feed that Klaviyo really should be using instead or as well to fix this quickly.

Hi @alex.hong 

If I understand this correctly, the user will be entered into the flow when they subscribe for the item.  When the item is put back in stock, in a location I do not want to trigger BIS notifications for, then the flow would trigger the “Back in stock delay”, check the categories on the product, and because I haven’t moved the product out of the OOS category (because it is not in stock in my online location yet) then the flow would exit and the customer won’t get the email.

However, would that customer not be removed from the flow and thus if I ever put the product back in stock online and remove the product from the OOS category, then the customer would not get the notification?

Do you have a status update on the multi location support?

Kind Regards

Luke

Hi @alex.hong,

Just trying to understand this workaround. Let’s say I have two stock locations, one for POS and one for my website.  A customer signs up on my website to be notified about product X.  I add stock to the POS location for X but the website is still out of stock.  That means I won’t move the product out of the OOS category.  However the flow will now trigger correct?  And if the flow triggers, although the customer will not receive the email, they will now be out of the flow right?  Which means they will not receive the email when I add stock to the Website location?

I think I am understanding that correctly but please let me know if I have missed something. 

Is there an update on this feature request?

Kind Regards

Luke

Hey @LRotherfield 

Thanks for reaching out on this topic! Jumping in to help answer your questions about the flow example above.

1. You are correct, if you add stock to your POS but do not remove the product from the OOS category, the flow will still trigger,
2. When the flow triggers, anyone going down the “No” path will exit the flow without being notified when their item is back in stock.

Depending on how often you restock your products, you can add a Time Delay for X number of days  and then add another conditional split so the profiles in the flow will be reevaluated again if their product is back in stock. Adding the additional time delay and subsequent conditional splits will allow you to keep profiles in the flow longer until you have their product back in stock. 

Hope this helps!

Thanks for the response @stephen.trumble 

Just so I understand correctly, how exactly does the “back in stock delay” trigger?  I can see several options:

1. Does it poll the product and if the product has stock greater than the threshold then the delay triggers?
2. Does it trigger when the stock goes from below the threshold to above it, i.e if the stock is currently above the threshold then the delay will not trigger until it drops below and then comes back above the threshold?
3. Does it trigger whenever stock is added to the item and the total stock is greater than the threshold?

Or is there another way it calculates when to trigger?  

Thanks again

Luke

Hey @LRotherfield,

Another great question!

The Back in Stock Delay is configurable on the account level. So it will depend on what you or someone else on your account has set up for how it will trigger. Here is a typical example, the delay is based on a minimum number of units that are restocked and how many subscribers are are “waiting” for the back in stock notification.

Check out the Help Center doc on back in stock notification settings Hope this helps!

Thanks @stephen.trumble 

Hopefully just one final question:

When the back in stock delay triggers, does it fetch all the product data at that point in time or does it use cached data for the product’s tags?

I ask because I want to implement your above solution so have written a Shopify flow that tags products as in/out of stock dependent on the website location stock location.  This happens on inventory update, however there is a short delay while the flow runs, so if you use cached data or grab the data before the flow runs then the tag won’t exist. 

Ultimately, If I put in a 5 minute delay after the back in stock delay and before the trigger split, will the trigger split refetch the product data?

I hope that makes sense

Kind Regards

Luke

Do you mean something like this (ignore the value of the trigger split, that will be product tags that determine stock status)?:

Hi @stephen.trumble do we have an update on above, it has been a year since @alex.hong confirmed that this issue was being looked at and that Klaviyo has had prior request to implement this? Thanks

Hey @LRotherfield 

Thanks for the follow up! Klaviyo evaluates product inventory each step of the flow and should be updating in real time for the most updated information. Your solution looks great! It will recheck daily to see if the product has been restocked while allowing the profile to stay in the flow without exiting immediately. 

@NaokiKE Our product team has not implemented any changes to this at this time. However, I will send a follow up feature request on your behalf. I know how important having the right tools can be to help drive business and will make sure to share your feedback with the product team. 

Thank you both for helping make the community and Klaviyo better everyday! 

Hello, any update on this feature? 

@stephen.trumble ,

For my clarification. If there are multiple locations set up but only 1 location is set to “Fulfill online orders from this location”, the Back In Stock email will send when any location receives stock?

Thanks,
Thomas

we saw this app which i think does the job https://apps.shopify.com/customer-back-in-stock-alert-user-notification-app

Is there any update on the feature implementation ? we have also met with the same roadblock and in search of a custom solution

+1 for having this option built into Klaviyo. It's common for a store to have both online and POS locations.