Zapier is a god send for the non developer portions of a company.
I work in marketing. Marketing projects are inherently speculative, you don't know what they will achieve until they're done. Add to this that dev teams at every company have full sprints planned for months. Getting a marketing project done through the dev team is months of exertion and sweat.
Or... get Zapier approved by security, get platforms plugged in officially, nice and tidy. And then the marketers can do what they need in the platform, and they're able to iterate and learn at a much faster pace. It changes the whole game.
> nice and tidy. And then the marketers can do what they need in the platform, and they're able to iterate and learn at a much faster pace. It changes the whole game.
The reality is, marketers will frequently plug in any and every thing they can without thinking about the broader context. Sure you can plug all this stuff together, or you can spend a bit of time with ETL and rETL tools and develop a stack that isn't reliant on a bunch of third party silos.
Is your goal to have a martech stack that doesn't rely on third party silos, or is your goal to have your lead-gen form populate your Airtable CRM for your new experimental acquisition campaign?
The marketer is being asked to acquire users, not make it look pretty behind the scenes. In the testing phase, it's way better to use Zapier to get things done fast. Then you can revisit and scale later with a proper solution if it turns out to be a productive campaign.
But there in is the problem. Most Marketers I've had the pleasure of working with/for will never come back and implement the proper (scalable, secured, etc) solution. By the time this first ad-hoc creation has either failed horribly or taken off, they're off on the next new "idea".. there's no time to property revisit that last one, why would we? It's either dead and forgotten or working as I gloriously intended!
I've actually already seen Zapier go 'full lifecycle' in two separate environments. It went from "cautiously approved" to "banned by both name and by functionality" both times due to the marketing team zapping their collected data off to, lets call them.. overly public output storage locations.
I would have no idea where to start with rETL and I'm a software engineer... Search turns up some medicine and other non-related stuff.
If it's a typo, then sorry. But ETL is the same beast. I have few ideas where to start thanks to my programming background, but I can't imagine the marketing department guys do any of it.
Non-ideal but less expensive is still better than nothing (or too expensive to stay profitable). Not all operations are huge companies that can afford IT teams working on their behalf.
it refers to a somewhat poorly named concept known as reverse ETL, something we started working on back in 2018 with our product Census (getcensus.com). We launched it on HN in 2020, though it's come a long way since then :-) https://news.ycombinator.com/item?id=23034642
Think of rETL as an on-demand data lake that doesn't actually store any data (for the most part).
Yeah you can pull data and create snapshots to preserve views, but given the direction privacy and regulatory environments have been going with user data, it's incredibly sexy to be able to not have to dump data in yet another data warehouse just to use a new tool.
>or you can spend a bit of time with ETL and rETL tools and develop a stack that isn't reliant on a bunch of third party silos
This is the real future of 'unbundling'.
I love reading this article because while it sets up the problem and solution proposition quite well, all I could think of was how the author is proving reverse-ETL engines (& not their own platform) are the best investment right now.
At the end of the day, most business owners don't want to connect all these tools together. It just allows them to accomplish business outcomes. What makes their job hard is keeping track where all the data is and how to know if things are working.
Solutions to that problem can take shape as a CRM (and keeping it updated) or something as dumb as a dashboard of dashboards.
Agreed. It's a common trap of technologist thinking: if we gave people better access to primatives, they'd have more power to assemble what they wanted!
In fact, it's "assembling" that most people hate. Which is why products that sacrifice power to limit assembly tend to be successful.
> I work in marketing. Marketing projects are inherently speculative, you don't know what they will achieve until they're done. Add to this that dev teams at every company have full sprints planned for months. Getting a marketing project done through the dev team is months of exertion and sweat.
Slightly off-topic: you basically just described why spreadsheets were such a huge deal when they were first introduced in the 1980s.
> Add to this that dev teams at every company have full sprints planned for months. Getting a marketing project done through the dev team is months of exertion and sweat.
I'm confused by this, can you clarify?
This sounds like the exact opposite of agile sprints (assuming you're talking about agile)
It doesn’t sound too far off from what I’ve seen. The details of the sprints may not be worked out, but a dev team might have several months of high priority project queued up and marketing might be deemed lower priority. So getting extra work done from another team can sometimes take a very long time.
I fail to see how it's not agile? Roadmaps aren't against agile. If marketing is low priority and there's a large backlog of high priority work, marketing related work is never going to be considered when planning a sprint.
The only way around this is to have more dev capacity or to prioritize marketing work.
We outsource a lot of the marketing tech and website related work so marketing is not blocked by our own development team. We don’t see marketing tech and our Wordpress website as our “secret sauce”. The devs are just focused on product development.
Yeah, it's a question of prioritizing which projects make it into the pipeline. Marketing automation is often subordinate to automation projects for other departments like Finance and Operations when it comes to prioritization.
This is exactly the kind of comment I was hoping to see. May I ask, what kinds of things are you using zapier for that are not just nice to haves. Something that you would say it pays for itself (increases revenue somehow)
I would love to get an answer to this question as well. I keep comings back to Zapier and the likes hoping I will find a useful use case but can’t. It seems that all it does is add stuff from email marketing forms to Google spreadsheets.
For more complex things Zapier falls flat IMO. I've been using Make.com (formerly Integromat) and it offers way more flexibility and it's easier to configure for more complex automations.
Great convo, thought I'd share some valuable zaps I've used over the last few years to save $$$ on headcount, dev time, and burn/debt on unproven ideas/experiments.
- Slack - pipe all kinds of events into special #channels to cross teams can check one spot for external happenings: new users, new sales, support chats, form/data submissions
- Forms > CRM/Sheets - shouldn't be understated. Using lead page or no-code CRM (webflow my fave) I've swapped out various signup flows to test ideas/friction/followups repeatedly before asking dev to build actual signup flows into the backend app. Can swap paperform, typeform, mailchimp, google forms in under an hour for multiple signup/landing pages w/o any devs.
- Calendar - I use Motion (similar to Calendly) across sales team to speed up meeting flows + use Zaps to pipe those bookings into sheets/Slack/CRM or EMS. Sales team calendars can be public on marketing site (webflow) and bookings generate all the alerts and data we need to just show up to the meetings.
- Leverage SMS channel - One-click surveys, recurring survey campaigns using SimpleTexting or YesInsights and piping results wherever I need 'em. Google Sheet with charted dashboards already set up to auto-update. Great for ecomm, great for call/response feature testing with zero dev required. Can add phone signups via form integration or email campaign.
- Manual issue / todo alerts: Use specific tag in Asana to pipe a ticket into Slack channel when team member wants to surface for manager/teammate - instead of asana firehose
- Light @mention feed - Pipe brand mentions/topics, including web (reddit etc - use F5bot) into sheet or #channel for marketing eyes to check daily
- Twitter bot - built @carryonbagsizes using just Zaps: anyone tweets airline name and gets carry-on bag size restrictions back from the bot (including variations on airline names ie United vs United Airlines)
Zapier makes changes on behalf of a single account. You can change the "share" permission to only allow view for anyone except for the account tied to Zapier which has edit permissions.
1) If you're piping data into Sheets, then you most likely don't have good custody practices and aren't limiting edit users to just 1.
2) Sure there's revision history but you can't "roll back just this one change". You roll back _all the changes_ to the state at that time.
3) If the marketer does appear to save new Sheets as major data changes occur, they're not properly branched. You end up with Sheets like "customer_list_v1, customer_list_v1_no_Csuite, customer_list_v2_no_CSuite, customer_list_v2_scrubbed".
As a consequence you can never be sure if the reporting is correct or if the data is up-to-date.
Indeed, this unbundling is already happening. Many of the so-called Customer Data Platforms offer a low-code, no-code option for creating and iterating on marketing campaigns. They've already done the work of integrating with the various storefronts and ad platforms.
Yeah I was wondering too. Not that people wouldn't use it, but I wonder about what the transition is from "this is handy" to "I want to continuously pay for this service / enough that it is consistent enough / earns me money back enough to do this and not something else".
This would have been true 5 years ago but based on the current pricing, any non-trivial use case is far more expensive than identical internal development and maintenance.
One time, when we were much smaller and a team of 10, we had a marketer who also thought they were a developer.
Instead of choosing an off-the-shelf tagging solution like Google Tag manager, they used Zapier + custom injected code into Wordpress + Segment to attempt to hand-roll a "marketing tech stack".
All the data was wrong and all the integrations would break constantly. Eventually we moved on and a team had to figure out how to rip out all the code and deprecate the integrations.
We ended up just moving to a new CMS to start clean.
How do you manage this when marketing relies on PII to do anything? We just went through a switch over to a multi-channel messaging SaaS from an internal solution that "worked" for 6 years. Handling the PII aspect of things was taken care of by the SaaS being SOC 2 and GDPR compliant, but something like Zapier seems like it gives users the control to move PII into systems that don't have that compliance. Or are there controls around which data can flow where?
Long story short, you don't. No competent security organization taking their responsibilities seriously is going to issue a blanket approval of something as broad as Zapier.
What you can do is get an enterprise relationship in place, deploy tight endpoint monitoring and management, careful management of permissions at every level, and then make the review processes relatively fast. Not marketing-wants-to-build-a-whole-new-thing-with-lots-of-PII-tomorrow fast, but fast. Having strong systems for generating realistic test data and systems will make this prototyping much easier, though from experience Marketing will tend to dismiss such things.
Marketing's needs and goals are real and important and valid and blah blah blah blah. Mostly their institutional incentives are to barrel ahead as fast as possible with any and every tools available. A security organization's remit is to make sure that this isn't reckless and liability-inducing, which often means dialing back the speed from breakneck to manageable and maybe even doing some token amount of planning around what you hope to achieve.
Yep, in small companies you get carte blanche, and there are two kinds of big companies. Those that make it work with a process like the above comment (which looks like a great and reasonable set-up), and those that kneecap their marketing departments by rejecting the tools needed for modern marketing.
As a side note, I've worked with 60+ startups. One thing that kills start-ups whenever it happens is giving too much power too early to the "default to no" departments of a company - security, legal, brand.
It's been my experience that default-to-no is what happens when groups like security try a reasonable process... and find that marketing and similar enablement-first groups handle this by ignoring and bypassing it. This tends to set up a very ugly reckoning at some point. Marketing will lose, but the company overall will lose too.
If marketing ever says "But an enterprise contract with SAML is too expensive! Can't we just use the basic SaaS version?", it's time to check what other processes they're used to ignoring. I'd suggest starting with expense records. There's probably a bunch of vendors handled entirely on a director's credit card.
To be fair, the people that run SaaS platforms that extort a 3x multiple to go from "Pro" which just happens to have every feature they offer EXCEPT SAML, to "Enterprise" which, low and behold, adds no value /other/ than SAML all need to line up and die in a fire someplace.
I should look into more features with it. Right now I mainly use it to link my Slack and GitHub presence. Very very useful since I get all sorts of notes from folks on both platforms. It's been critical to avoid having things fall through the cracks. I keep a special private slack channel that has slackbot message me whenever someone pings me on GH and lays out all the relevant info.
1. New demo booked via Calendly --> find/create deal in CRM --> send Slack message to #notifications-sales
2. New app sign up --> webhook to Zap --> create new deal in CRM --> create new contact in email automation platform --> send a Slack message to #notifications-signups
3. New in-app purchase --> Update CRM Deal as 'Won', update Deal LTV --> push Slack notification --> change email sequence from 'free trial' to 'paid subscriber'
4. New Facebook Group member --> add as contact in email automation platform and subscribe to 'Facebook Group' email list
Not marketing, but we use it to automate some WordPress tasks.
WordPress Gravity Forms submission -> Zapier -> Airtable to assign calendar -> Zapier -> Create WordPress draft
Have someone fill out a structured Google Sheet -> upload to private Gravity Form -> Zapier to process > Create WordPress draft
I'm sure I could spend time figuring out how to do this stuff directly in WP with coding, but it is nice to connect existing things together relatively easily as a first step.
The article describes an idea that there are startup opportunities to be found by identifying horizontal platforms (e.g. Craigslist) that cover a lot of ground and build something that handles just one use case (e.g. job posts) covered by that platform. The article calls it "unbundling".
A while ago I was involved in a startup that attempted to compete with a dominant horizontal platform in this manner (Craigslist, in fact). The ideas were fine, the people were good, but we had a lot of trouble getting traction. Turns out, Craigslist is where the people are, and if you want to build a marketplace, you need people. Features turn out to be secondary. It's unsurprising to me that, in the end, the best competition for Craigslist came from another big horizontal platform with tons of people: Facebook.
I'm not actually trying to say that "unbundling" can't ever work. Maybe Zapier is ripe for it, as the author suggests. This is just what happened to come to mind when I read this story.
Facebook is not the largest 'classifieds' marketplace, at least not everywhere, and it did not disrupt craigslist everywhere.
There are multiple other successes to replicate the classified/craigslist model:
Other good notable and successful local models offerup, maybe somewhat ebay.
FB Marketplace only began to overtake craigslist if there was not another dominant space in the area.
Here in Utah, the dominant newsmedia made a brilliant use of their traffic to bundle their news traffic with a more reputable and useful classifieds. They are still more dominant than FB marketplace in Utah, though used about equal now.
Most local newspapers had the right classifieds model before craigslist became a behemoth, though without exception local papers struggled to capitalize on their traffic and keep the flow towards their classifieds.
Classifieds were always the extra cash that gave pure profit to newspapers for a large part of their lifetimes. News and stuff sorta went hand in hand there for awhile, too bad its random BS FB news that's bundled with classifieds now instead of real reputable news sources.
I think the canonical example of 'unbundling' is every startup that does a thing that could be done via Excel and streamlining the experience around one use-case: time tracking for freelancers, inventory management, etc. I hear there's been a bunch of money made around making SaaS out of things that used to be done in Excel sheets.
Totally, outside of people trying to make a "smarter" excel like Airtable or Rows, different business units will make some "template" that lets them run their orgs in excel. Those "templates" could certainly be better products.
I feel like Facebook Marketplace was really the only way to disrupt Craigslist because it is where the users are. There were lots of products that tried over the years with varying degrees of success, but mostly failure. I'm not saying it is a better replacement either, but as far as I can tell it's effectively stolen most of Craigslists utility. I joked the other day that the only people left on Craigslist now are scammers and older people.
Disruption is still very regional. Where I live Kijiji (Ebay) is dominant, in other locales it's still Craigslist. FB Marketplace is still an "and also" player but not dominate here
Funny enough: quite a few Zapier employees use us to do calendar automation.
IMO, the opportunity is "and" not "or". Zapier is great (I use it too!) for so many use cases, but sometimes the use case is complex enough and the opportunity large enough that dedicated solutions emerge.
So while some value may strip away from Zapier via dedicated solutions like Reclaim, I think Zapier will also continue to add value by educating more of the world, improving their UX, and connecting with more services.
For the folks looking for coding-style solutions, I'm also big fan of https://pipedream.com/. Check it out!
Craigslist is still thriving? I don't know anyone who uses Craigslist to list stuff for sale now, FB Marketplace seems to have taken the majority of traffic. They've apparently lost almost half of their revenue in the last couple of years (COVID being a contributing factor I'm sure but it started declining in 2019). Total monthly visits is also down half from 2017. I believe the golden days for Craigslist are over.
I'm a new homeowner with kids way out in the boonies, and coming from a city I've had an accelerated need to find and buy ... stuff.
Craigslist is just about over. It's a subset of things that are cross-posted to Facebook Marketplace.
What Facebook did that Craigslist won't recover from is to align groups with classifieds. I belong to regional groups devoted to selling bikes, boats, furniture, baby clothes, among others. That's where the action is, and while there is cross-posting to Craigslist, that trend is certainly ebbing.
Our customers of [Streak](www.streak.com) use zapier heavily to connect to all their other tools so we have a ton of experience with it. We're currently building an alternative for our users natively into our app (we think we can make a more optimized experience for our app).
I think we've stumbled onto a pretty key product insight - we're basing our automation tool on a spreadsheet. Zapier is clearly optimized for non-technical users so doing any logic, even basic if statements, is really cumbersome. On the other end of the spectrum, pipedream and tools like it rely on your users knowing how to code. We think spreadsheets are the perfect balance, most users (at least ours) know how to do basic formulas and understand references.
Spreadsheets are awesome:
- development environment is completely set up for you, no tooling needed
- editor, runtime, debugger are all the same tool
- by default you see the output of all your computation, its a secondary action to see the code
- you can preview the intermediate data results at every step of your computation making debugging a dream
Here's how we're thinking of applying it to the Zapier use case:
- a series of zapier like triggers and actions
- each step is just a 2 column spreadsheet (property name and property value)
- the value can be something hardcoded, a reference to a value in a previous step, or a complicated formula
I had designed a similar system for consultant customisation of complicated business rules, although I failed to deliver it. I had intended to:
* Have one workbook per business function. One inputs sheet (variables in), one sheet for the formulas, one outputs sheet (variables out).
* Use a sort of test driven, self documenting approach. When developing with clients, it is easiest to ask them about specific examples, including simple and complicated ones. Consultants understand business rules when they configure a system, but it is very hard to come back to 5 years later when the business wants something tweaked. Test data inputs and expected outputs was to be included on other sheets, with documentation. And the system would validate the sheet formulas gave the correct outputs for the example inputs.
* Use custom formulas for our industry needs with a custom data type for some variable inputs - this is the crux of where I came unstuck with my design (it was kind of SQLish table inputs per input cell, visible in Excel when in design mode).
I didn’t actually finish the system, because I was trying to bidirectional integrate directly with Excel using COM, and I just couldn’t get that working because I overcomplicated it. This was a long time ago, and I couldn’t find a suitable non-excel engine to integrate with due to other team constraints. Note that spreadsheets are inherently side effect free functional programming at its finest IMHO: I wanted to avoid any imperative programming. However we ended up with an imperative Visual Basic like design instead which did work, but it takes extremely highly skilled consultants to use it, and is spectacularly inefficient.
I just presumed splitting out the roles would make everything clearer and debugging easier. For the concept to work, the rules engine had to interact with the workbooks inputs and outputs, and that seemed like something that could have subtle mistakes and hard to debug by the consultants if everything were on a single complicated sheet.
Consultants are less familiar conceptually with functions, and this way I could get them to label variable inputs and label outputs. I expect consultants wouldn’t structure things unless given a format. The “formulas” sheet could be pretty wild and complicated: many consultants are more results focused than OCD organised. I didn’t want to have formulas etcetera mixed up with parsing the inputs and outputs. Also that way the spreadsheet can easily and unambiguously define the inputs and outputs for the engine to grab the names/definitions from.
I can think of other ways to do it, but it was just what seemed the most likely to work for multiple reasons.
One goal was to avoid recalculations by tracing the dependencies (yay spreadsheets) and using memoisation for the outputs, and versioning the results, and versioning the consultants’ formulas (i.e. the workbook was the unit of programming change, one reason to not put too much in each workbook). Auditing where values came from, and why values changed if formulas were modified, was one desire for the engine.
You can set up each column to hit an integration. As a cell is populate either by hand or from the result of an integration, it triggers other cells to evaluate.
So I'm pretty sure this is the technology revolution that we're all sleeping on.
Like, self-driving cars? VR? Meh.
Accessible programming? A safe environment for folks close to a business problem that lets them solve that business problem on their own?! That's cool.
Like for me, in my experience as a software engineer, there's basically four types of employees: The tech-naive domain expert, the tech-friendly domain expert, junior coders, and senior engineers.
The two ends of the spectrum should stay focused on they're good at: Doing business stuff, or coding on tough problems.
It's the two roles in the middle that interest me: Tech-friendly domain experts and junior coders.
Right now, in most companies, tech-friendly domain experts could totally figure out a tool like Zapier and do things that they'd normally need an engineer to do. But their company doesn't use something like Zapier, so they can't. They just have to talk to technical people and make them do it. But there lies long debugging loops and, just, slowness.
In some companies though, those that have embraced low-code platforms like Tray or Zapier or the product we made (https://docs.middle.app), they've enabled their tech-friendly domain experts to do tons of stuff they couldn't do before, without bothering people like myself, a more senior coder (I can work on platform things!).
ALSO, I've found that junior coders have a special role. We've hired non-programmers and taught them Python JUST so they could code new things in the developer side of our integration platform. It's a sandboxed environment with limited risk; they can go crazy coding whatever connectors or other things that those tech-friendly domain experts need. I don't have to be involved, outside of a code review every now and then. I know that they can't break anything other than the narrow thing they're working on.
UI based flows for integrations are as bad as UI based flows for ETL. For some reason, we managed to move past UI to code for ETL, but now we are taking the exact same path for integrations. Integrations are complex, you might have complex requirements, polling and pushing needs depending on the applications, fast lookups needs, legacy IT solutions that hold critical data. I don't think we are ready to go full UI in this space, I think good orchestration and good microservices are still a better choice.
Yeah, this is almost the sentiment behind the snarky comment I made that got voted down.
The difference is I am not so pessimistic about those UI-based ETL systems because I did a deep dive on the architecture of those and even worked for a startup that built one. I've seen how the industry's fixation on raw performance has kept ETL systems using a relational model that is hell to program for complex jobs -- I pitched a next generation system to a very acquisitive leader in this space and got shot down because my system wasn't friendly to storage locality and SIMD instructions. (That startup had the right idea of passing 'JSON' documents between the lines and the boxes but never settled exactly what the algebra was for those things, how to close event pipelines in the end properly so you always get the right results, ...)
Those "integration builders" though strike me a way of replacing a 10 line Python script with incredible tedium and "you can't get from here to there" experiences. That leads me to say things like "When I hear the word 'integration' I reach for my gun."
Is there any open source, embeddable alternatives or frameworks? I've got an ETL DSL that is fully serializable and I've been looking to create a UI tool for it.
I don't know of a solution for ETL DSL -> UI but https://github.com/lowdefy/lowdefy goes from a DSL to internal web apps. Perhaps some inspiration could be taken from there. Good luck!
Depends where those UIs are on. If you have some sort of agreement set in place where they won't update the interface, then this is very much possible.
If it is relying on an 3rd party platform that you can't control and not know when UI changes are coming, then it can be bad for criticality.
However, I fail to know how urgent criticality is in ETL space, especially when UI changes can be as simple as "theres a new button" or "margin on form changed". The key process features and UI related to it would rarely change.
There is a space for that for sure, but when things get serious, the programming bit is 10% of the capability, domain knowledge, data expertise and SQL become more relevant. Those skills are not fulfilled with UI tools. Sometimes in fact UI tools make the skill gap bigger because new hires might know SQL, but for sure don't know your expensive proprietary tool of choice.
I feel like I live in a cave. Over the past 10+ years, I’ve yet to understand what use cases people use for things like IFTTT/Zapier/etc. I clearly must for alone I’m not understanding.
Can someone please help me understand their specific use case. I’m genuinely curious.
I am a software developer, have a paid professional plan, and am almost out of my "zaps".
Here are a two of my favorites:
* Non profit community organization wants to sell event tickets. Paypal Order -> Add row to spreadsheet for simple reporting -> Add/Update user in mailchimp with a tag so they don't get future emails asking to buy tickets again.
* Small client wants a gated webinar signup. Wordpress Contact Form -> Zapier Endpoint POST -> Add user to Zoom Registration -> Add/Update to mailchimp with a source tag -> Add row in spreadsheet
Could these be done without zapier? Sure. But using zapier we can create that within 30 minutes without a server, or even dealing with serverless. Even if someone had those workflows as a one click install for lambda workflow, I would rather use zapier than deal with any AWS overhead.
To everyone who thinks that "a webform to google docs" is the most common use case you are probably right. If you think that you could create the infrastructure to do that consistently with automatic retries, logging, error handling, keep on top of API changes from both ends, across dozens of clients, proper authorization and secret management, for cheaper than $50/month, then you are kidding yourself.
A popular use case for SaaS companies isn't even in utilizing Zapier themselves, but rather adding their API to the list of integrations. This can really speed up onboarding for customers -- especially if they already use Zapier.
I'm not sure we're the target audience to be honest. My experience with bundled 'integrations' tends to be that you spend about as much effort fixing the mismatch between the provided integration and what you want as it would take to write an integration from scratch.
In one case it took a bit longer, but in the end it was still necessary to write the whole thing from scratch in order to comply with the terms of use of the API. Which kind of proves my point.
>if you have to ask you are not in the need to know
Does it really need to be said that we don't all know about every program/service available to us that we could use, and thus could occasionally use someone telling us about them?
>The process of companies building products that strip away use-cases from horizontal platforms is called “unbundling”.
Is there a more plain English explanation what this means?
I didn't understand their explanation, and then they showed Zapier that seems to be a service that relies on automating some tasks based on one or more other service .... that seems to be very "bundled" in my mind now that you've got two or more services heavily reliant on each other...
The graphic in this short article [0] that shows the numerous companies "unbundled" from Craigslist is worth the click and will help you instantly understand the concept.
The article is saying that Zapier is ripe to be unbundled.
Meaning it does many different things across many verticals, and that some of them are big enough that a company could be created around building a more specialized / better version of zapier just for a specific vertical.
My understanding of how the term was used is this: Zapier has many use cases. Many customers buy Zapier for one or two use cases, not all the features offered. New startups are emerging that accomplish a subset of the use cases that Zapier addresses.
I suspect what the author is trying to say in plain english is that Zapier is prime for being copied to a more focused business case.
ie, ITTT/zapier have proven that this idea works, lets copy+paste one but aimed at some other more specific business/scenario like catering or some junk.
Its a more jazzy version than "lets make an uber, but for farts."
Zapier seems exactly like the type of product that is difficult to unbundle because its value is in its integrations. If an integration (e.g. Gmail and Trello) maps to an addressable market, then the more permutations there are, the larger Zapier's potential market and value is. If you move away from Zapier to some optimized single-purpose integration then you lose the potential value from access to the other integrations. And because of Zapier's enormous library it covers both common and niche use cases.
Zapier is different from something like Craigslist because the latter only offers convenience from having different verticals in one place. There is no synergy between them.
Zapier is also have trouble keeping up with the demand. Their Youtube integration hasn't worked in almost 2 months now and I think it's because Google has stopped giving them enough API quota to meet the demand. The thread has been locked since and I don't think there is any resolution coming.
It’s interesting that some of these unbundling articles have started popping lately. I believe there was recently a Airbnb unbundling blog.
IMHO, if anyone wants to unbundle, FB is a prime target. They’ve grown big and acquired companies , and are distracted with the whole Metacrap, that it is high time someone picks use cases apart to do them better and well.
Zapier is really awesome for the non-tech crowd. I think this space is only going to continue to grow. I decided to build https://atlasconnex.com for developers who need more fine-grained control, but don't want to stand up their own infrastructure. The project is recently launched, so the number of connectors is growing rapidly. One my favorite (again, I'm the developer!) connectors is the "build your own" connector. You define a Python function and declare a period for it to run (once/min up to once/24hrs) and then you can do basically whatever you need inside that function. So if you need to poll an API endpoint, or pull a file from an SFTP server etc., you can create events based on that data that are then processed through transformers and filters and then delivered to their final destination.
I’ve had this same thought. The features I get out of Zapier are very useful but lacking some basic functionality that would make it a killer app. Things like branching are missing and rate limits are low. The price is also very high per action which makes it a poor use case for anything that isn’t directly making you money.
Is unbundling a good way to come up with business ideas? I am not so sure. Sounds more like human pattern matching playing its part. As in "Oh yeah, that business is a bit like a Craig's list section". Unbundling seems like the analysis of what you did, not the plan of how to do it.
Zapier is vulnerable to disruption both ends of the dev/integration chain (code/no-code), and they have been for some time. Their primary edge (IMHO) is a huge ecosystem of integrations unmatched by their competition. I don't see that edge persisting. It won't be long before OpenAI-esque UI's can generate no/low code integrations and as you'll see below there is plenty of conventional competition.
They've had adequate funds and time to implement bulk actions, interface improvements and ecosystem enhancements that would benefit users, but not much has emerged. I use Zapier and some of the providers below as alternatives:
Integromat
Pipedream
Mulesoft
Jitterbit
Built.io
Workato
JBoss
Celigo
Parabola.io
Integrate.io
IFTT
CloudHQ
MixMax
Regardless, as a private company they're really only beholden to their owners, and they generate enough revenue (and presumably NET profit) that one could imagine ownership perhaps confusing focus for what might (or might not) actually be arrogance.
low/no-code ecosystems have been promised to be "just around the corner" for decades now. I'll be really surprised if it ever arrives. Take a look at microsoft's "LightSwitch"
I work for a team that specializes in middleware development - eg the cases where Zapier really falls apart and needs a more thoroughly architected solution. I've spent a lot of time inside this topic.
The thing that will disrupt Zapier is the software vendors themselves. Most Zaps will eventually be replaced by native platform-to-platform integrations where the middleware has been designed and sanctioned by the 2 parties. Having a one-size-fits all solution is impractical over the long run. Its a temporary fix for a bigger more substantial problem.
This is plumbing. You don't use one flimsy universal type of pipe joint for every pipe in your house, otherwise you get leaks. Same thing
Reddit is the B2C version of Zapier here. It's ripe for unbundling. You're safe from Reddit itself because historically they've moved very slowly for some reason (though marginally faster, lately), and you're safe from the big players (Google, Facebook, Twitter, TikTok) because of Reddit's reputation for going after a (now) older, "savvy" customer base that is hard to monetize.
Are they in direct or indirect competition with IFTTT and also Microsoft PowerAutomate... How much space is in the industry for these no-code automation tools?
I would like to think anything you can bring to the table to compete or add value (maybe flow-based logic rules or inclusion of serverless script-level transforms similar to pipedream) could be cherry picked and added onto zapier with little stress. I'll add that it is relatively trivial to wire your own serverless function into zapier to this end. One thing lacking from the article as a niche proper webhook management (ie hookdeck).
There are many industry-niche api-interchange products out there... many predating Zapier and remaining the defacto in that industry. Think logistics, ERP and finance systems.
As much of a case that can be made for unbundling - I don't think such can be said for zapier and the breadth of moat they've created. Zapier integrations on a given SaaS usually don't hold a candle to native/direct, but they are certainly universal.
I'm very curious to hear a concrete example of a segment/industry and how it could be "unbundled", but unfortunately there is none in the article.
SOC/PCI compliance? Remember Microsoft Flow (now called Microsoft Power Automate)? Hundreds of connectors and deep integration into azure/microsoft platform... all underwritten and stamped by Microsoft's level of enterprise.
Looking at that ARR growth curve, they've certainly demonstrated the value of wide integration over deep/niche integrations.
The only argument to be made here for market displacement is that a cheaper alternative would come about offered as a loss leader by big tech, or an open data interchange standard/paradigm could come abound and disrupt the necessity of this.
That being said. I think that you're right! Trying to just take workflows (or zaps) from Zapier is not going to be the best move. These companies have focused on their verticals and started building a product where automation is a feature, not a product. Anvyl for example is a pane-of-glass for supply-chains orders/parts/sourcing along with automation to supplement the experience. I believe Alloy is trying to become an E-commerce CRM. Their wedge has been enabling some tricky workflows that aren't well supported in Zapier.
I think unbundling takes place on two levels. First, zapier competitors. (Full disclosure, I am building a workflow comparison website comparing 25 zapier competitors.)
But secondly, I start wondering if native integrations won't become more important and a bigger threat for zapier over time. Currently the typical customer pays for two SaaS services AND for zapier etc. to connect the two. Over time, native integrations can, self built or with the help of white label solutions from n8n embed, make, Paragon and others, make workflow automation solutions less important.
I also wonder if Google sheets, notion databases and airtable will not become hubs for automations. Many problems are solved for a fraction of the cost if all SaaS have native, two way automations/syncs to these spreadsheet/databases.
(Notion bought automate.io, but hasn't really interested it. Yet.)
1. Revenue is only $125m
2. Revenue growth has not plateaued
3. There is user value and multiple value in an all in one offering
4. Distribution will be hard exceptionally hard, going up against a thought leading, financially solvent, Founder led organization with a proven solution.
...Thus, your unbundled solution must be exceptionally better for a few million dollars in aspirational revenue. Otherwise, so distinctly different that it is not really a competitor.
Has the author just not heard of Jitterbit or Mulesoft?
Tangential rant - I feel like there is this group of 20-somethings that just assume that because they haven't heard of companies like SAP, Oracle, etc. that they just dismiss them as being dumb and boring and then when they analyze a problem space. Yet have no idea how a company like P&G operates at a global scale (hint - they use software like SAP). Jitterbit and Mulesoft essentially sit in that space.
P.S. - Pipedream is a super interesting model, but it's not an unbundling play.
Don't forget Microsoft Power Automate (and Logic Apps). For anyone in the 365 ecosystem these become the default, and yet I never seem to see them mentioned alongside the more start-uppy stuff like Zapier and Imtegromat.
It's mostly because the most economical way to get it is with an enterprise M365 sub, which many companies with under 1,000 users don't have. Even at that level, the unforseen need for additional premium licensing can dampen enthusiasm ("but it worked with my trial subscription!"). Besides, "low code" or "no code" is still programming, and requies that non-IT people to deal with unfamiliar concepts like software support, security and lifecycle management (or to ignore them at their own peril). Logic Apps are a whole other thing. More pro developers should give them a closer look if they aren't already using them.
You're building one for healthcare? Mind sharing more details about the company? Email in profile if it's something private but you'd be open to sharing privately.
Google started shutting down its GSA (Google Search Appliance) business in 2016, with the latest customers getting shut off by the end of 2018/2019. The promised cloud replacement never materialized, at least for anyone who wasn't also on GSuite/Workspace. GSA was an interesting product that I and others spent 100s of hours mastering. Really hated giving it up, although it was never the panacea for cutting through search results "noise" we had hoped it would be. ROI? Given its short lifespan, I doubt you could get a consensus on that. One thing in its favor over existing cloud based solutions: you had a lot of fine-grained control over the output. You could say that GDPR killed it, but that wouldn't be fair. It could have been queasiness over storing all that internal customer data. Or maybe the infamous short attention span of Google's executives.
I'll say, Our organization failed to properly implement the appliance ; as such, didnt get the best result. (can't blame Goog/the device if we didnt actually implement the thing in best way possible...)
We're playing in this space with M3O (https://m3o.com) but focused very much on making APIs programmable as opposed to completely doing away with the code.
We moved to Discord and most apps only support Slack (looking at you, Datadog and Github!). Zapier has saved us in a couple cases from having to go back to Slack.
To provide one painful example that I'm currently dealing with, at work we have a Marketing Automation platform, a CRM and a CX tool. Marketing use the MAP, sales use the CRM and customer success the CXM.
All 3 have their own data schemas, their own "customer view", their own segmentation tools, they own orchestration (workflows) tool, etc. Everything exists in a silo, and no one can see the big picture.
This area absolutely needs disruption, we're starting to see some of it at the MAP level with MessageGears, Vero and Supergrain but it's yet to feed through to those other customer facing functions as far as I've been able to see.
Is the workflow automation tool big enough that subgroups of users are still a big number of users to service
Of those subgroups, does one (or more) stand to have a better product experience if someone focused on their core use-cases / workflows. (e.g. Reclaim takes a bunch of calendar automation around scheduling and makes a product that reduces the work needed to optimize your calendar).
My sense is that most no code tools will face a far greater challenger from AI programming tools like Copilot than from further unbundling through web interfaces. It's just so much easier to set up an automated chain of api glue when you don't have to read the docks.
zapier sounds like something that doesn't scale, or will be replaced by the platforms themselves. it's like a business on 1000 other people's platforms.
I work in marketing. Marketing projects are inherently speculative, you don't know what they will achieve until they're done. Add to this that dev teams at every company have full sprints planned for months. Getting a marketing project done through the dev team is months of exertion and sweat.
Or... get Zapier approved by security, get platforms plugged in officially, nice and tidy. And then the marketers can do what they need in the platform, and they're able to iterate and learn at a much faster pace. It changes the whole game.