Customer Data Strategy: B2B's 3 Most Common Approaches

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.”

And as you’ll see in this piece – it’s different from a CDP, which is the SaaS world’s biggest misnomer. And way beyond CRM, which is the SaaS world’s biggest crutch.

The Five Fundamental Customer Touchpoints

Baked into the DNA of almost every B2B software organization are five customer-facing functions:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

Why is Legal not on the list of customer touchpoints?

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.

How can a business orchestrate customer touchpoints for a unified experience?

There are three dominant strategies when it comes to unifying customer data:

1. CRM becomes the Single Source of Truth.
2. Build a Customer Data Warehouse as the Single Source of Truth.
3. Deploy a CDP to unify customer data.

Can CRM be the Single Source of Truth?

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.

Does the Customer Data Warehouse actually work?

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.

• ETL
• 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:

1. 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.
2. 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:

Why are more and more B2B companies looking for CDPs?

My hypothesis? Because people don’t fundamentally understand why they need 3 or more tools to do the job of one.

Also, the adoption of CDPs in the B2B space is driven by needing the following:

• Unified customer data
• Enhanced customer understanding
• Improved personalization
• Data-driven decision-making

By leveraging these CDP capabilities, B2B companies can drive customer engagement and increase their revenue. This gives B2Bs a highly competitive advantage over other businesses in the market.

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.

None of these customer data strategies are a fit – what then?

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?

1. 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.
2. 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.
3. 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?
4. 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:

1. Learn from our customers’ real instances as they walk through how they use Syncari:
   1. Dooly for Reverse ETL and Product Led Growth
   2. Demostack for Customer 360
   3. Hyland for Unifying Multiple Marketing Automation Platforms
   4. Conga for Unifying Multiple CRMs
   5. Metadata for Reverse ETL and Customer Health
2. Read the raving G2 reviews from our users.
3. Watch the long-but-thorough “No BS Demo” on MarketingOps.com delivered by our CTO and Co-founder Neelesh Shastry.

Why aren’t iPaaS tools and native connectors considered a customer data strategy?

iPaaS tools and native connectors are technology solutions that facilitate data integration and connectivity between different systems and applications. While they play a crucial role in enabling data flow and integration, they’re not typically considered a customer data strategy on their own. Here’s why.

Scope

IPaaS tools and native connectors primarily focus on the technical aspects of data integration and connectivity. They provide the infrastructure and capabilities to move data between various systems, transform data formats and streamline data workflows. However, customer data strategies involve factors beyond integration — they  involve the entire lifecycle of customer data (including its acquisition, storage, governance, security, analysis and utilization).

Strategic planning

A customer data strategy involves creating a comprehensive plan with principles that allow businesses to manage and leverage their customer data effectively. A strategic plan focuses on the following: decision-making toward data collection, quality, privacy, compliance and the value of customer’s data. While iPaaS tools and connectors contribute to the execution of the strategy, they don’t inherently define the strategy itself.

Data governance

Customer data strategy includes defining data governance policies, standards and processes to ensure data accuracy, consistency, security, and compliance. But what does this involve? Well, establishing rules and controls for data access, usage, retention and consent management are top of list. But while iPaaS tools and connectors can support data governance initiatives (mostly by enabling data integration with proper security and compliance measures), they don’t fundamentally deal with the broader aspects of data governance.

Data quality and enrichment

Customer data strategy also involves improvement efforts in terms of data quality, enriching data with additional insights, and ensuring data completeness and accuracy. (This might include data cleansing, normalization, deduplication, and enrichment techniques). IPaaS tools can certainly help move data between systems, but they don’t directly address the specific challenges related to data quality and enrichment.

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.

In summary, iPaaS tools and native connectors are essential when implementing a customer data strategy because they provide the technical capabilities to integrate and connect data. However, they don’t encompass a full spectrum of:

• Strategic planning
• Governance
• Data quality
• Enrichment considerations

Each customer-facing team has its own “source of truth”

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.