Zapier: A $5B Unbundling Opportunity
georgesequeira.com
georgesequeira.com
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.
1 Month (billed Monthly):
---Zapier $29
---(5 triggers / 750 events)
---Make $11
---(unlimited triggers/10,000 events)
- 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)
Especially if there's any sort of editing or data transform in sheets, there's 0 traceability of the change.
Not sure what the commenter was on about, then.
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.
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?
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.
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.
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.
I'm confused by this, can you clarify?
This sounds like the exact opposite of agile sprints (assuming you're talking about agile)
The only way around this is to have more dev capacity or to prioritize marketing work.
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.
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
5. New charge in stripe --> update CRM LTV value
> 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.
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.
Both offer no-code tools to help non-technical users make use of the data.
T - Transform
L - Load
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.
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.
I don't think anyone using Airtable as a CRM has those sorts of concerns, however.
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.
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.
Solutions to that problem can take shape as a CRM (and keeping it updated) or something as dumb as a dashboard of dashboards.
In fact, it's "assembling" that most people hate. Which is why products that sacrifice power to limit assembly tend to be successful.
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.
Slightly off-topic: you basically just described why spreadsheets were such a huge deal when they were first introduced in the 1980s.
Excel is actually a relatively decent programming language when you want to quickly _write_ a business application.
The big problem occurs when you want to _read_ the application. Alas, reading is necessary for maintenance and debugging and reviewing/auditing.
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.
Interesting overall. Thanks for the post OP!
Packy talks more about how this is also a platform being unbundled: https://www.notboring.co/p/excel-never-dies?s=r
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.
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!
https://aimgroup.com/2021/02/11/craigslist-traffic-revenue-f...
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.
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
Anyone tried something like this before?
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.
* 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.
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.
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.
It's neat. Neat stuff.
Agree that coded integrations are still very relevant, but the addressable surface for UI is pretty large now.
Right but in the same breath we should mention all code is terrible.
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."
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.
My approach to integration for ETL was a DSL.
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.
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?
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.
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.
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...
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.
In this instance I would argue that the author is saying clone the idea but make sure the APIs offered are for a specific subsection of an industry.
Or more succinctly: jump on the bandwagon in the style of hipstermatic/instagram gold rush.
[0]: https://thegongshow.tumblr.com/post/345941486/the-spawn-of-c...
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 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.
(1)https://community.zapier.com/general-questions-3/youtube-the...
Good integrations are hard to build and expensive to maintain. I’ve seen many sunset or ignored simply because the paying customer base was too small.
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.
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.
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
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.
Alloy Automation is making a better Zapier for E-commerce: https://runalloy.com/
Anvyl is making a better Zapier for supply chain: https://anvyl.com/
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.
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.)
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.
(Anyone recall the Google Search boxes from ~2007? Are they still avail?
We installed some at Lockheed in ~2006 or something... never saw the ROI on that thing...
but a zapier host on a closed network, I can see the ongoing value of such...
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).
This is what needs to happen.
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.