Feature Requests

Got an idea for a new feature or integration? We’d love to hear it! You can find our roadmap here.

7 votes

Sync WooCommerce product edits with CRM

With CRMs that support products (Drip, HubSpot, Zoho, Infusionsoft/Keap, Ontraport, AgileCRM), make it so that the product is synced to the CRM when it is created in WooCommerce (instead of at checkout). And when the product is edited in WooCommerce, sync the updated product details to the CRM (name, price, etc).

——
Original request:
It would be useful in the future if it was possible to sync, update and add products directly in infusionsoft when they are created in woocommerce

by inserting buttons to manually decide when and if to synchronize or update them or even create them or a global setting that does it automatically.

Completed Category: Enhanced Ecommerce Edoardo Guzzi shared this idea Updated: March 6, 2023

11 thoughts on “Sync WooCommerce product edits with CRM”

  1. Worth noting that without this feature, you cannot build automations based on purchases unless the specific product has already been purchased. Furthermore, with the current capabilities, only variations get pushed through as part of a purchase, so you cannot build automation/rules based on the parent product. This makes it very difficult to fully utilize automations.

    1. Noted, thanks.

      For us, we use tags for automations, and then the Enhanced Ecommerce is more a record of the customer’s order history. So that’s why the plugin doesn’t sync products that nobody has purchased… we never needed them in the CRM unless they’d already been ordered.

      I like this as an idea for a feature enhancement but it will be a somewhat big project…. especially if we try to map custom fields between Woo products and CRM products.

      And to be honest it will probably not be 100% reliable at least through the first iterations, since it’s not building on anything we have already, it’s all from scratch. So even when this is ready to use, I’d recommend still using tags for automations that are critical.

      Definitely something we’d like to tackle, just can’t say when for sure 🙂

      1. Thanks, Jack.

        I’ve been using WPFusion for quite some time and using tags to record product history (as you describe above). I sell concert tickets, which have a short shelf life and often several variations. This approach has resulted in our repeat customers accumulating an overwhelming number of tags, making it very difficult to use tags for other purposes. In fact, the UI design for most CRM’s does not take into account displaying contacts with dozens of tags.

        Looking back, it seems silly to create so much noise with tags when the e-commerce data is there and should be actionable in the same way. But presently, I run into road blocks when trying to segment and build automations unless I rely solely on tags.

        I will also underscore this other area of functionality that is becoming increasingly important: drag and drop product blocks in email builders. ActiveCampaign just released that feature last week. I’m using Drip now, and it’s very frustrating because (1) only products that have already been purchased are available as blocks, and (2) only variations are available and not the parent product.

        I really rely on the extended features and capabilities of WPFusion, but it bums me out that the basics are not on par with the native plugins.

        1. Yup, I completely agree with you regarding the suitability of tags for tracking order history. It doesn’t scale well.

          Re: Variations. That’s kind of a separate issue. Even when we do enable syncing product edits with the CRM, every variation will be a separate product in the CRM… since there’s no way to create sub-products in any of the CRMs we support (as far as I’m aware).

          But if it would be helpful for you to have an option to ignore the variations and treat all variable purchases as a parent product purchase… that’s something we could do pretty easily. If that’d simplify things, let me know and I can put in the feature request, and we could get started on that pretty soon.

          You could also take a look at our Event Tracking addon for Drip… it’s our newest addon. Details at https://wpfusion.com/documentation/event-tracking/drip-event-tracking/

          With that you can add a Product Purchased trigger in WPF, and every time a product is purchased, the product title can be synced to Drip as an event. You can then build your automations around those purchase events (which are very similar to Shopper Activity events) without needing the products to be synced to Drip first.

  2. Thanks. For what it’s worth, we also rely on Metoric as a reporting platform that sync’s with Woocommerce. They are able to sync the product hierarchy… in other words you can segment by the parent product, or an individual variation. The data structure in Woocommerce supports that kind of reporting too.

    1. Right… but if we sync *both* the parent product and the variation over the API, then a single product purchase will have cart item quantity of 2.

      And one product will have to have a $0 price, to avoid messing up the order total / LTV.

      We have basically unlimited flexibility in how it’s *sent* to Drip, but as far as I’m aware Drip can’t run reports on product hierarchy.

      So…. would it be more helpful to have the option to sync just the parent, ignoring the variation?

      Or would it be better to sync the variant as a “pseudo-product” with a $0 price, similar to how we currently sync attributes (https://wpfusion.com/documentation/ecommerce-tracking/drip-ecommerce/#getting-started)?

      Thanks

      1. Understood. If I have to choose, I’d prefer to sync the variations.

        A more detailed answer would be that when segmenting or creating automations, we need the granularity of the variation.

        However, when using the email builder to “drag and drop” a product block, it makes more sense to add the parent product.

        1. Gotcha, thanks. So in an perfect world…

          1. When a new product is *created* in Woo, it will be synced to Drip in real time, but not include variation details (i.e. so the parent product can be used in a product block).

          2. When an order is *placed*, the variation that was purchased should be synced to the customer’s order history, not the parent product.

          Does that work? We can aim to come up with something like that

          1. This is something that would be useful for me also.

            We have a membership, where WooCommerce Subscriptions handle the subscriptions and we have monthly and annual subscriptions.

            So we have a parent product with two child products (monthly and annual payments).

            Right now I don’t see the product variations in Drip after purchase and I need to start the automation by the tags.

            1. This should work now. For variations, Drip uses the “Product Variant ID” to track them. So in your trigger, you’d select the parent product, and then the variant ID like this: https://i.wpfusion.com/SjYL6Q55

              That way you can start the automation for either Monthly or Annual payments.

              We added support for that in v1.19.3 in December ✅

              If you want them to be separate products…. that’s something we could consider. But that would have to be a separate feature request as it’s another pretty big change, and it also goes against the Drip API so we’d need to approach it carefully.

              Also, if the variation IDs aren’t showing up for you or aren’t triggering the automations, drop us a line at https://wpfusion.com/contact/ and we can check it out 🙂

  3. This is available now as a beta (opt-in) feature in Enhanced Ecom v1.20.0, with AgileCRM, Drip, HubSpot, Infusionsoft, Ontraport, and Zoho.

    It’s a pretty major change so I’d recommend testing on a staging site.

    To enable, turn on Sync Product Edits from Settings >> WP Fusion >> Enhanced Ecommerce.

    Also note that, with Drip, new products don’t show up as eligible for the Products block until ~1 to 3 hours after they’ve been added in WooCommerce.

    We do send the data right away, but for some reason Drip seems to need a couple of hours to process it before the products become available. Not sure why.

Leave a Reply to Kyle Homstead Cancel Reply

Your email address will not be published. Required fields are marked *

Powered by Simple feature Requests