Rev Ops and Business Systems teams are under heavy pressure to deploy complex, data-driven processes in the name of Modern GTM
"Build me a revenue architecture that supports both PLG and ABM, and everything in between"
- Any CRO
Each GTM tool has its own way of storing data, making 'integration' a more complex problem than it seems
Many workflows require a mechanism where data insights are triggered or published to an end system
Most actionable insights require use-case specific logic and analytics that don't make sense to recreate in DBT
It often takes a data engineer, a Salesforce admin, a tooling engineer, and an operations just to deploy a use case
Reverse ETL tools copy data. They are not focused on orchestrating actions based on business conditions.
'Taking an action' can be very different from 'copying data'. For example, creating a Slack message requires, well... a way to type in dynamic text. Generating a new task in Salesforce based on opportunity data is more than just an upsert. Adding a contact to a custom static list in Outreach requires a specific API.
It's also hard to replicate state management - in other words, a series of custom filters and trigger conditions. If there is any branched logic or a series of related but different filters, then the user would need to create a bunch of tables which gets unwieldy.
Reverse ETL tools rely on the end system, often Salesforce, to build business logic. This works great for one or two simple use cases, but it quickly gets overwhelming as an Ops team evolves.
BI tools are visualization platforms. They do not push data or events into systems where teams already work, like a CRM or a marketing automation platform. As a result, we often hear that outside of the executive team, BI tools frequently suffer low adoption.
Some BI tools provide limited support for alerts. For example, every night, Looker can send a CSV of a table to the CRO. Or, if a certain aggregate KPI hits a threshold, Looker can send a Slack notification.
This works well for executive reporting but not for operational use cases. They do not manage state, meaning that they cannot 'nudge' a team member that a record has recently just met a set of business criteria. Oftentimes, they require the user to build an entire set of dashboards, which can quickly become unwieldy and complex.
Workflow automation tools are fundamentally event-driven. They make it difficult to run analysis across multiple data sets that then trigger a workflow.
Event-driven triggers typically look something like: 'when a new record is created in X system, then do Y'. However, as GTM strategies get more complex, many use cases revolve around calculating a cross-table metric and then proactively monitoring for changes in that metric on existing records. This is different from passively listening for new records being created.
This gets even hard if you're working with large data sets - like self-serve users. Zapier often runs into API call limits or requiring custom code to loop through records more efficiently.
Arm your team with a modern data platform
