“If it’s not in Salesforce it doesn’t exist.” This still can be heard as a common mantra from leaders on revenue teams. Similar to “one ring to rule them all,” it will ultimately lead to confusion and headaches from an operational perspective. Ultimately it’s going to drive up your tech debt and create inefficiencies.
The first issue I see as companies scale is the propensity for teams to buy software that fits a single need. This is particularly the case before a RevOps leader is in place. Marketing, sales, and customer success are all run by separate leaders and each makes their own purchasing decisions.
Platforms may sell themselves as “out of the box” or “integrated with Salesforce,” but rarely is it as simple as flipping a switch. Integration and data decisions are critical and need to fit into a broader data architecture. Without intention, these integrations will drive up redundant and sometimes conflicting data across your ecosystem.
The second largest consequence is leaders' tendency to want a field for everything in Salesforce. I cannot count the times I’ve been asked to create a new field to track the flavor of the day. Those fields stack up over time and all of a sudden you have dozens of fields you can’t remember why they were created. That tech debt is a pain to unravel and increases the likelihood of people pulling faulty data from Salesforce.
I’d like to change that original mantra to “if it’s not connected to Salesforce, it doesn’t exist”. That change from in to connected has dramatic consequences.
SaaS is critical to enable scale for companies. Point solutions can supercharge your revenue teams with the best available tools to help prospect, land new business, and keep customers happy.
The phrase, “It takes a village,” rings true. But that village cannot be haphazardly stood up. You need a civil engineer to plan out the roads and infrastructure that enables citizens to get around efficiently. RevOps are those civil engineers for go-to-market teams.
So when you’re implementing new tools, you don’t need every piece of data flowing into Salesforce, but you do need the right bridges and keys connecting the platforms so you can traverse between them.
This also keeps your main Salesforce pages focused on the fundamentals. You want your teams to see the pertinent information they need and not get lost in a deluge of fields that cause more confusion.
Salesforce reporting (among other CRMs) is clunky, a pain to use, awful to manage for teams, has limited visualization capabilities and is incredibly difficult to combine different objects quickly.
That’s why I never recommend using it for revenue reporting. I’ve only seen it add confusion and result in inaccurate data. There are better ways and it will depend on the audience for the report.
Revenue intelligence tools just make things easy. Clari is a prominent player in the industry. They allow leaders to leverage revenue, pipeline, sales, and forecasting reports easily while scaling up and down the organization. Most importantly, RevOps can control what data is ported to the platform, so everything is trusted and reliable. It’s hard to pull the wrong fields if a leader runs a custom report because it’s a controlled environment.
I call these platforms “RevOps in a box.” They reduce the strain and required RevOps headcount to deal with one-off reporting requests by:
If you are running a RevOps or sales team, these platforms will make your life simpler. They deliver a world-class user experience all based on data that you trust and can control.
The key to reporting is not the end report, it is on the opposite end, where you find your data. Having a place where your analysts can easily access trusted, up-to-date data is critical. If your analysts can quickly access the most reliable data, they’ll spend less time hunting, and more time analyzing (a far more valuable use of time).
If you’ve architected your go-to-market ecosystem appropriately, you can port in the data from your various go-to-market platforms into the data lake. From there, your data engineering team or RevOps analysts can knit these root sources together into accessible sources of truth. I would not expose every data element from the root systems, but instead curate the relevant elements into tables that analysts can consume.
These are all just examples, but they’re easier to consume than having analysts knit together multiple objects from Salesforce and other systems each time they want to run a query (think of every time joining the user table in Salesforce with the account, opportunity, or campaign objects). It just gets old. Do the legwork so your analysts have the data at their fingertips and have to do one or two joins instead of fifteen.
This method also doesn’t limit your ability to just pull from Salesforce. The data to populate your views can be mixed and matched from different systems to get at the business need, not just the core system. Doing that in the data lake is far easier than managing each of those data integrations in Salesforce itself. It will also allow you to plug and play systems easier as your ecosystem changes (and it will).
The last and potentially largest benefit, when something changes, you don’t have to update every single query and report that hits the root data. Update your source of truth and let everything else flow downstream. That just increases your ability to scale!
Don’t focus on getting everything into your Salesforce environment. It will only drive up your operational costs and create more headaches than that effort is worth. Instead, focus on making sure you build out your go-to-market ecosystem the right way and make sure that you have the right primary and secondary keys connected to your Salesforce environment.
Then build out a reporting strategy that’s going to make your stakeholders’ lives easier. If you can create trusted environments for them to self-report like a revenue intelligence platform, do it! If you can make your analysts’ and data scientists’ lives easier by creating sources of truth so they don’t have to hunt for every single query, do it! You’re going to speed up development time, make future changes easier to digest, and ultimately everyone is going to have better data to work from.
