Forum Discussion

DrewR's avatar
DrewR
Contributor 2
1 month ago

Zapier vs Make… what’s been your experience?

I’ve been building out more automations around Jobber lately and ran into something interesting. A lot of setups I see are using Zapier, but once workflows get more complex, the cost starts climbing pretty fast.

I switched a few of them over to Make.com just to test it, and it’s handled everything I’ve thrown at it so far. Feels like you get a bit more control over the logic, and it’s easier to actually see what’s going on in the workflow. Pricing hasn’t ramped up nearly as fast either.

Curious if anyone else has tried it, or if most people are still sticking with Zapier?

ai
software

7 Replies

  • Chi_Cleaning's avatar
    Chi_Cleaning
    Contributor 3
    4 days ago

    We started with Zapier, but once our workflows got more complex it became harder to manage. We ended up hiring a company to build and maintain some custom automations and API integrations for us.

     

    • Randy_Warner's avatar
      Randy_Warner
      Contributor 4
      1 day ago

      This is a really common path — Zapier works until it doesn't, then the complexity forces a decision between learning a new platform or bringing someone in.

      The native Zapier connector covers the basics, but there's other options out there that extend this — including events and custom field data the native connector doesn't make available. A lot of businesses find it handles the complex workflows without needing custom development.

      What kind of automations were you trying to build when things got complicated?

  • HUGEHomePros's avatar
    HUGEHomePros
    Jobber Ambassador
    1 month ago

    I'm a zapier guy. I have so many automations set up through there. As far as the cost, that's definitely a consideration but how much time could you save? Are the automations actually useful? I like the cost because it keeps me honest. I'm not just automated for the sake of automating and I don't think it's unreasonable if it is an automation I use. THey also have an AI function that can pretty much tie everything together so it gives you a lot of help with that regard.

    More than anything though, if you think Make works, use it! I didn't even know it existed before I read this post so run with it. I just know that zapier has a TON of automation opportunities so that's why we started there. 

  • Mohamed_Ch's avatar
    Mohamed_Ch
    Contributor 2
    1 month ago

    did you try of n8n or heard of it you can setup it in private vps for 5$ or 10$ and run it and build anything you want

  • Poriechkin's avatar
    Poriechkin
    Contributor 2
    1 month ago

    I prefere Make to Zapier as it can handle multiple brunching and easier to navigate and Make he's more abilities. 

  • jgreene626's avatar
    jgreene626
    Contributor 2
    12 days ago

    I made the same switch. Once your workflows get beyond a handful of steps Zapier's pricing becomes hard to justify, and Make's visual builder makes it a lot easier to debug when something breaks. I think Make has an easier learning curve than n8n but it still took me awhile to get the hang of. 

     

  • Randy_Warner's avatar
    Randy_Warner
    Contributor 4
    1 day ago

    Agree with you from a UI perspective DrewR​. The visual layout of Make helps me understand the workflow better. The reality is that both tools work. The real constraint for Jobber users isn't which platform you choose; it's what data is actually available to build on.

    Zapier's native Jobber connector covers the basics well enough for simple workflows. Where it tends to fall short is when you need to trigger on specific Jobber events or pass custom field data downstream. That's when people hit the wall and assume the platform is the problem.

    There are tools in the Jobber app marketplace that extend what's available to build on. For Zapier users, that means access to 50+ triggers and actions — including custom field data and events the native connector doesn't expose. For Make users, it means webhook support for Jobber events, which you can point directly at a Make scenario for real-time triggers rather than relying on polling.

    In both cases the platform isn't the bottleneck, it's whether you have the right Jobber data to work with in the first place.