This conundrum comes up almost every time you think about buying a Revops tool: “should we buy the best-in-class precision tool or find the best swiss army knife all-in-one product that does a good enough job?”
In the CRM (Customer Relationship Management) world it’s particularly challenging. The goal is to get you to standardize on a single platform for ease of use, limiting the number of vendors, and taking advantage of an ecosystem that grows up around the tools.
A CRM is an application built with data models that are converging to things like Companies, People, Sales Opportunities, Campaigns, Campaign Members, and custom objects. But there are newer event-driven time series that are also important, tied to product usage, external third-party events and other novel data.
This leads to a conflict when you need a new capability: build it, or use the equivalent (or lesser) capability in the all-in-one tool?
Why to use the All-In-One Tool
The best reason to use the capability that exists now is simply … that it exists now. If I wanted to build an approval process in Salesforce, I could choose to build a Salesforce Flow to model this capability; or I could use a webhook to trigger an external service to start the approval process; or I could use the built-in feature.
The opportunity cost for building a new capability is high. This doesn’t mean that you should always use the All-In-One idea. What it means is that regardless of the method that you use to model the work that gets done it’s important to abstract the Job To Be Done from the Feature That Already Exists. If you find that it’s not that much of a tradeoff to use something already built, you can get to using it faster.
And speed to solution might be the goal in RevOps today.
The value of a solution looks like:
-
How many times (a day, a week, a month) does someone run into this problem that needs remediation?
-
What’s the value of getting it right? Conversely, what’s the value of leaving it alone and doing nothing? (Does it cause harm to keep the null state)
-
Do you have a good mental model of what fixing it would look like and how to build that solution?
-
Is building a custom solution the only way to solve that problem OR the best way to solve it to maintain it for the future?
Pay attention to Step 4 above. Maintainability and usability are key to thinking about infrastructure so that you end up with a series of capabilities that are related instead of an assortment of unrelated features built in different all-in-one tools.
The case for precision tooling
The beauty of making a custom solution is that you don’t have to build all of the features you would build if you were creating a commercial product. The downside of making a custom solution is that if you want to build some of those features it will take longer, or you need to rely on different custom frameworks (hello, Pipedream!)
The best case for a custom solution is that it allows you to do something faster, more efficiently, and better than the version of the solution in the all-in-one tool. Have you ever tried to send a notification from Salesforce to an external system when an important event happens based on data that combines information in Salesforce with information in another system?
If you try to do this using the all-in-one approach, you need to echo other data into Salesforce and rely on its timing and broadcasting features to send your request. Now, think if you’d like to customize the message with data from another system. And whether you want to memorialize the current version of this workflow to source control.
Once you go through this mental calculus, you’ll end up likely thinking that it’s reasonable for Salesforce (or another all-in-one system like Apollo or Hubspot) to trigger the event in a webhook when it happens, but to use a custom external product (I use Pipedream, but Zapier, Make, and others are good solutions for many integrations) to bridge the gap to the next step.
Centralize the activity where it makes sense
You’ll notice I’ve been talking about using the outputs of an All-in-one system to drive additional capability for Revops teams. A sales user or a marketing user has different needs – namely, to work in the same system as their peers or to work in a system that shows them similar views of the companies, sales opportunities, and contacts they are using.
Over time, I’d argue for a customized CRM (and maybe even custom software verticalized for your need) if you have the engineering resources to support it. But if you don’t have that resource, using the All-in-one software most of the time makes sense to get the capabilities you need. And it has the added bonus of providing market validation for the precision tools of the world to build an integration ecosystem around that tool.
What’s the takeaway? Although All-in-one platforms often seem like they are not customized for your use case, the act of figuring out what problem you’re trying to solve often opens up a way to solve it in that all-in-one platform. And for the instances where only custom code will do, using an integration bridge like Pipedream is a critical component to building a maintainable process for the future.
