Photo by Benjamin Voros on Unsplash
For a long time, I didn’t think twice about my default approach to data. When in doubt, put it in the CRM.
It felt like the right approach. It was validated by my peers and the Salesforce marketing juggernaut. Customer 360. Single source of truth. If it isn’t in Salesforce, it doesn’t exist.
But over time, my perspective has changed. I’ve seen consolidation costs build over time into tech debt. CRMs that overcomplicate and underdeliver. Teams that invest heavily in a technology project and then realize they don’t have a concrete plan to use the unified data once it exists.
The alternative starts with a different mindset. It begins with data at the center of the conversation rather than a specific tool. This data hub mentality lets us question some problematic assumptions: that data consolidation leads to insight, or that our CRM is the right place to consolidate. It prompts us to ask questions like “what do we need our data to do?” and “ what’s the right tool for each job?”
A CRM still has a key role in your tech stack. But it may not be the best hub for your data strategy.
A data hub has a few core jobs, and it’s worth understanding what they are. Although a CRM can (more or less) perform each job, they aren’t first-class functions.
A data hub needs to access all the data sources you’d like to use. That often means copying data into a centralized location, but can also mean the ability to query and work directly with data in other systems. A dedicated reporting tool that can live query data from different systems can function as a simple data hub without creating copies.
Your hub also needs a way to process (clean, transform, unify, and restructure) data from these different sources. This function might live within the hub itself or as part of a pipeline. The key is recognizing that data from different sources isn’t going to simply slot neatly into place in the format that you need.
Finally, a hub needs to make the processed data usable. This typically includes surfacing data in reports and pushing it back out to the tools where it becomes actionable. That could mean creating segments for audience targeting in a marketing tool or summarizing historical interactions for 1:1 relationship management in a CRM.
A CRM is great at the job it was designed to do: wrap a database in structure, automation, validation, and security to help individual users interact with data in ways that align with business processes. It’s powerful enough to take on elements of another job it wasn’t designed for (integrate with other sources, process that data, make it available for additional uses), but that doesn’t mean it will excel in those roles.
Briefly zooming out can give some perspective on how the pieces fit together and why so many organizations lean heavily on a CRM even if a different approach is more appropriate.
Cloud CRM (led by Salesforce) gained traction in the 2000’s and was transformative. It let you collaborate from anywhere with an internet connection and was designed around a transactional/relational database with automation and reporting. It excelled when managing individual changes to structured records (i.e., update a specific Opportunity or Contact to reflect current pipeline).
In the 2010’s cloud warehouses like Redshift, BigQuery, and Snowflake became infrastructure for analytics (at least in larger organizations). They were specifically designed to scale and provide flexible reporting across many different data sources. Although capable of changing data, these tools were fundamentally about doing so at scale and with reporting in mind rather than individual user updates.
The 2020’s have seen a rise in data activation: writing details from warehouses back into operational systems like marketing platforms and CRM. The role of a data warehouse is shifting from a layer intended to support reporting into something that drives action. And the tools are more affordable and accessible than ever.
These technologies (CRM, warehousing, activation) have slowly moved downmarket as customer expectations have evolved, data volumes have increased, and new technologies have become more accessible. But for many organizations, the second two phases either aren’t on the radar or seem like solutions for the problems of a larger organization.
The pivot from CRM to data hub is a mindset shift first and foremost that puts strategy in front of technology. Rather than ask how we can add more into an existing system, the question becomes “what do we need our system to do, and are the tools we’re using the right ones for the vision?” A non-CRM hub can give you fundamentally more flexibility to evolve and iterate than a hub that’s baked into a transactional database.
Setting your data hub up for success starts when you clearly define your desired outcomes and specific needs. This should originate from organizational strategy and flow down into specific business objectives and the tactical dependencies. You should have a clear idea of what changes you’ll make and how you’ll measure success at a macro level, as well as specific details like the level of granularity you need in each system and how you’ll approach aligning data from different sources. CRM-as-hub might be fine to resolve identity based on email addresses for a simple set of external activities, but sophisticated identity matching or aligning sales with finance data become significantly more complex.
Although we’re having a discussion about data hubs, it’s crucial not to overlook non-data outcomes such as ease of use, cost of maintenance, user adoption, and overall solution fit. A custom CRM application might be ‘best’ for data strategy but have significant UX downsides, lack of buy-in from staff using it, and ongoing end-user challenges compared to an off-the-shelf third party tool. Focusing on multi-dimensional outcomes helps avoid the trap of pursuing consolidation under the blanket assumption that good outcomes arise to those who consolidate.
Pivoting from CRM-as-a-hub to a dedicated data warehouse doesn’t mean you need to pull everything apart. The cost to shift is real, but the good news is that work you’ve already done to consolidate into your CRM can be incorporated into a new hub. As you add new sources or processing, they’re built on top of the hub rather than the CRM. And as existing CRM processes and pain points are revisited, the hub gives you another route to address them.
Another walk/crawl/run approach is to begin with analytics before adding operational dependencies. A standalone reporting tool like Power BI or Tableau can serve as a lightweight data hub. They avoid the need for automation or a dedicated warehouse and can help you surface cross-system insight and identify data quality or alignment issues. Reporting can also aid in the design of a dedicated data hub and provide value while a more robust system is being built out.
A data-first mentality also encourages looking for ways to test hypotheses and prove value before committing to a build. Ad hoc reporting and manual exports cause problems when they are part of a recurring process, but create value when they’re used to build a proof-of-concept or test an idea. Running a pilot doesn’t need to be fully automated and can help you define the right size and location for your hub.
This isn’t an approach just for large orgs with dedicated data teams. The conversation might look different depending on size, but the underlying questions and approach are size-agnostic.
Large orgs likely already have a warehouse layer in some capacity. The opportunity is to recognize that it can be more than just a reporting tool, and seek to shift processing and activation out of the CRM. It may also mean more capacity for point solutions that meet the needs of individual teams rather than being locked into an IT-driven tech stack.
Midsized orgs can be where the most friction accumulates. Historically, a warehouse may have felt out of reach or not been part of the conversation. There’s enough capacity to build in the CRM, so that’s where the complexity lands. This can result in a heavily customized system that’s doing a job it wasn’t really designed for. The warehouse approach is becoming more accessible and moving downmarket to the point where it should be part of the conversation for any org considering a CRM with platform-style capabilities. Overall cost of ownership (vendor fees, maintenance and upkeep, staffing expertise) is real, but so is the overhead created by trying to do all of these things in a tool that wasn’t designed for the job.
The smallest organizations may not have the capacity for a dedicated hub of any kind. Focused, standalone tools that meet staff where they are and where integration is *not* a top priority may be a better fit than a unified system that requires ongoing maintenance. A good analytics tool can bridge gaps with minimal integration overhead.
At all sizes, the principle is the same: match the tool to the actual job and be honest about what you need and can use now, rather than assume unified data will lead to an outcome that isn’t clearly defined.
The tech landscape has never been static, and the rate of change feels particularly quick right now. There are more tools and lower barriers to entry than ever before—*even before factoring in AI. As we explore new ways to use our data, we should be thoughtful about the current state of our systems and the goals we have for them.
Flexibility lets us take advantage of these changes, but also requires something in return. When we’re open-minded about our needs and requirements for a data hub, we might discover that a dedicated tool can actually reduce the complexity of our CRM and simplify workflows that a CRM was never designed to support.
CRM will remain important, but it’s worth checking our assumptions and considering whether it should also serve as our data hub.
*The em dash (and content of the article) are fully mine. I feel a small pang of loss every time it’s called out as an indication of AI-generated content. Correct use was drilled into me by Professor Withycombe in college and has remained a staple of my writing ever since. I used AI to help think through the structure of this post and for editorial feedback, but the writing is not AI.