Customer data sits in many different systems. It is produced every time a customer interacts with your business, or when your teams pull data about customers from external sources like enrichment tools. How this data returns value to customers, through a cohesive customer experience, is the heart and soul of a “customer data strategy.”
Table of Contents
Baked into the DNA of almost every B2B software organization are five customer-facing functions:
- The product itself: Built and delivered by the product development team, this is where customers interact with the thing they bought. It’s asynchronous – meaning they can interact with it without a human from your organization.
- Marketing: This covers a lot of ground in one word, from advertising to email to the website, and beyond, to placements like PR campaigns, linkbuilding, directories, out-of-home and mailers. Most B2B teams use marketing automation to coordinate customer data at this touchpoint.
- Sales: Whether straight out of CRM or with a sales engagement tool, this is where customers engage with a person with the potential of becoming actual paying customers. There is, essentially, a human from your team involved here, every time.
- Customer Support or Customer Success: This team deals with the needs your paying customers have related to your product, and the value they derive from it. There is a human involved here for exception handling and often automation, or at least on-demand help content, for common issues.
- Finance: The team that handles the money often has a person involved, to review contracts.
This view of the world also makes it clear how tools and teams impact the customer experience: the customer sees themself as interacting with a single entity (your brand).
They might intuit the different teams, but ultimately evaluate the organization as a cohesive unit.
This is why B2B customer data models are so vital – you need to know how your organization views your customer.
In most cases, legal teams engage right at the point of sales, and almost never otherwise. This is not to diminish the vast amount of work involved in negotiating contracts and NDAs. Legal Ops deserves its own treatment separately from this discussion.
There are three dominant strategies when it comes to unifying customer data:
- CRM becomes the Single Source of Truth.
- Build a Customer Data Warehouse as the Single Source of Truth.
- Deploy a CDP to unify customer data.
Visually, it makes the prettiest of the three.
And in theory, it makes perfect sense. There it is, the CRM, already sitting as a vital tool for sales, marketing and CS (sometimes), just waiting to be integrated with the rest of the stack.
There are several problems that happen with this approach – as any sales ops or revenue operations pro will tell you.
First, CRMs are not always stellar at integrations. Even the most famous combination (HubSpot for marketing automation, Salesforce for CRM) tends to create duplicates and lacks flexibility with custom fields. The profound implications of this cannot be overstated: CRMs lock you into their data model, if you develop your data infrastructure on them rather than on another data layer.
Second, CRMs are actually many related objects. So a better representation of this approach is like this, with CRM bloated with all its component parts:
Third, CRMs do not allow cross-object reporting. Anyone who has tried to make a dashboard showing the relationship between Campaigns, Opportunities and Accounts knows how difficult this is.
Fourth, CRMs cannot report on objects in other systems, meaning you need to use another solution to get reports and visualizations of data from CS, product, finance, marketing – this is how most teams end up with a data lake or data warehouse for analytics. Often, the company already has a team building a warehouse for analytics, and so it just seems natural to push data from sales and marketing and other GTM systems into the warehouse. See the next section for what happens then.
Fifth, organizations often switch out tools at various growth stages, such as a new MAP, or even a new CRM. If CRMs are the source of truth, this is incredibly slow and painful (i.e. expensive) work.
Ultimately CRMs like HubSpot or Salesforce can’t be your Single Source of Truth.
The customer data warehouse goes by many names. For a while, it’s been known as the Modern Data Stack, and if you’ve followed Syncari long enough, you know we don’t like it. It’s like recommending fake medicine for an ailing patient. RevOps, especially, should run away. Ultimately, the Modern Data Stack (or, as it has been rebranded of late, the “Composable CDP”) is essentially a way to store customer data.
The main advantage of the customer data warehouse is its flexibility: that you get to build the customer data model that you believe best represents your data.
Vendors in this category promise uniformity in customer data – meaning normalization, deduplication, standardization, merge, sync, etc. – with only 3 tools.
- Reverse ETL
- Data Warehouse
So maybe it could look like this:
The biggest problem with the customer data warehouse is timing, or cadence. ETL tools run batch jobs to sync data out of source systems and into the warehouse. If you buy Fivetran your data waits till the hourly (or 15-minute-ly if you pay a lot of money) sync.
Then once in the warehouse, analytics can happen – which is fine. Analytics is based on snapshots, and doesn’t necessarily need to be real-time.
But wait, the data doesn’t quite fit well together from all these different tools. So the famous dbt has arisen to solve this – transformations in the warehouse.
But also, pipelines break, and that breaks everything, or data ends up missing, so observability tools have popped up.
And there are some helpful data quality tools for making sure everything’s clean and standardized in the warehouse.
So it really looks like this, with the bloat on the data stack, in terms of team, complexity and cost:
My favorite read on this problem – how much money and complexity get sucked into the data layer – is the aptly titled Fat Data Layer in B2B SaaS.
And maybe it’s more apt to say the biggest problem isn’t timing, but complexity: the logical hurdles to ensure 5+ tools effectively coordinate to manage the coordination of 7+ tools is… gargantuan.
For those who may argue that analytics is all the primary purpose of a customer data warehouse for, two things are helpful reminders:
- The primary job of data is to fuel the customer experience. This is even true of analytics (where leaders then make decisions based off of the insights they get) but before analytics happens, we need to make sure that marketers, sales people, CS teams, product development, and finance are all given accurate data in the systems where they live. Analytics is secondary. Period.
- If you’re a growth stage company, you can’t afford massive data stacks and burgeoning data teams. It rarely makes economic sense. And rarely – in b2b SaaS – do they have enough data to work with from customer touchpoints, until much later in the size of the business.
At this point many realize that the CRM is actually their Single Source of Truth for GTM teams’ tooling, whereas the customer data warehouse is a massive investment in dashboards and analytics.
But, for those who still believe a unified data layer should enable the five touchpoints to have an accurate view of customer information, are there any alternatives?
This brings us to the third approach:
My hypothesis? Because people don’t fundamentally understand why they need 3 or more tools to do the job of one.
A Customer Data Platform (CDP) implies unification of data in a single environment. It’s elegant and simple. Sophistication baked in.
The CDP was a category created by Segment, arguably at the inception of their analytics.js tracker in 2012, and they typically focus on a few key features:
- Collecting web visitor data and leveraging different data points to de-anonymize it.
- Collecting purchase and marketing data in order to personalize ecommerce experiences.
- Enabling high-volume segmentation, personalization and activation via advertising (especially display advertising). (You know when you see an ad for an item that was in your cart that you didn’t buy? It wouldn’t have been cost-effective for a marketer to place that ad to the 100 people with similar attributes, so instead, the CDP delivered it to a DMP – a Data Management Platform, which is a confusingly vague name for tool that segments audiences for display advertising only).
Often, CDPs do go some of the way to unifying data across core systems. So maybe it could look something like this:
But recall those features above – unification is the not what CDPs were built for. Arguably, CDPs are biased toward collecting data rather than merging and unifying across systems. They also tend to be weak on integrations with sales and support tools, and are redundant with much of marketing automation and product tracking.
This is a bit closer to the truth:
Traditional CDPs a bit overfeatured in the wrong places, and not effective unification tools, for the needs of the B2B customer data layer.
Well if only someone had thought to create a tool that could do this more effectively…
But before you scoff at the obvious progression in this article, consider:
What does a tool need to be able to do to effectively solve for customer data fragmentation across these five touchpoints?
- It needs to be able to sync while only storing vital information and metadata. The bias should be to updating source systems, not replicating them elsewhere. Think about it: Single Source of Truth is a concept that only made sense because there was no alternative. You don’t actually need a Single Source of Truth. Note: for you folks who need to query, you can get the storage add-on and query to your heart’s content.
- It needs to deduplicate, normalize, merge and unify everywhere. Set your logic for contacts, accounts, opportunities – any record type you want – and keep them clean in each system.
- It needs to offer minimum viable complexity – meaning, for instance, it can’t require 10 workflows to sync contacts in 5 systems. What if it could do it with one data flow?
- It needs to be usable by technical and semi-technical operators. Let’s be real, not everyone is going to know SQL, and even if they do, you don’t want them to have to perfectly match each other’s queries. Perhaps a no-code solution?
Syncari is the only solution in market that fits these parameters. It is a no-code platform that unifies data across CRM, MAP, sales, CS, finance and product analytics tools.
This is made uniquely possible by the underlying technology: patented multi-directional sync.
And for those who would like yet further convincing, we encourage you to dive a bit deeper:
- Learn from our customers’ real instances as they walk through how they use Syncari:
- Read the raving G2 reviews from our users.
- Watch the long-but-thorough “No BS Demo” on MarketingOps.com delivered by our CTO and Co-founder Neelesh Shastry.
Sometimes, iPaaS is a big part of the CRM-as-a-source-of-truth strategy, but just as often, it exists because there is no agreed-upon source of truth. And rather than worrying about that question, operators just need to serve the GTM teams. (Or there are no operations folks).
Native sync options and iPaaS are not, in themselves, holistic data strategies – they are solutions for point problems at a point in time. Some companies invest in a data strategy, in a data layer, and others do not. The debate could and should be had around at what point a mature data strategy is vital.
iPaaS tools like Zapier, Boomi, and Workato do have a strong role to play in collecting data from esoteric endpoints. Just today I wanted to connect GetSiteControl.com (inexpensive widget tool) to Marketo, and Integrately and Zapier both popped up as solutions since GetSiteControl.com does not natively connect to Marketo.
But once data is in core systems, it needs to be managed across all core systems. You could argue a lead can stay in MAP + CRM until it converts to a customer, but what about Sales engagement tools? And where do solution engineering teams live? More likely a support tool than anywhere else.
At the end of the day, you need a solution for optimizing the tools your customer-facing teams rely on as systems of record.
This should be the technical need that drives adoption of any customer data strategy or customer data stack.