> 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.
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.
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.
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.
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.
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.
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.
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?
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.
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
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.
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.