Your CFO just asked why the CDP renewal is $180K when Sales still can't see which accounts stopped logging in. You don't have a good answer because the CDP was supposed to solve that problem eighteen months ago. It hasn't, and now you're stuck defending a line item that delivers dashboards nobody opens.
Here's the uncomfortable truth: most B2B companies don't need a customer data platform to build a unified customer view. They need a warehouse, a clear identity model, and the discipline to maintain both. The math favors building it yourself if your use case is internal visibility rather than real-time cross-channel activation.
What a Customer 360 Actually Is (and Isn't)
A customer 360 is a single row per account that joins data from every system touching the relationship: CRM, product database, billing, support. As Basedash's recent breakdown puts it, the goal is answering "how is this account doing?" without exporting three spreadsheets and doing a manual join.
The "360" label gets thrown around loosely. Salesforce uses it for a product line. CDP vendors use it to justify six-figure contracts. But the concept is tool-agnostic. You can build the same thing in Snowflake, BigQuery, or a well-indexed Postgres instance with dbt models on top.
What it isn't: a magic layer that fixes bad data hygiene. If your CRM has duplicate accounts, your product database uses a different customer ID than billing, and support tickets reference email addresses that don't match either system, no platform will save you. You'll just have expensive bad data instead of cheap bad data.
The Six Layers Worth Modeling
Practical implementations organize customer data into layers, each answering a different question. Not every team needs all six, but this is the checklist I use when scoping these projects:
Identity (CRM, auth, product DB): account_id, email, company_domain. Who is this customer?
Firmographic (Salesforce, HubSpot): company size, industry, region, plan tier. What kind of company are they?
Product usage (product database, event analytics): last_active_at, weekly active users, features used. Are they actually using what they bought?
Commercial (Stripe, Chargebee): MRR, plan, billing status, renewal date. How much are they worth, and what's at risk?
Support and success (Zendesk, Intercom): open tickets, CSAT, health score, CSM owner. Are they happy, and who owns them?
Lifecycle (derived): signup date, onboarding completion, expansion history. Where are they in the journey?
The first four layers are non-negotiable for any B2B company running pipeline reviews. Layers five and six become critical once you're past fifty accounts and can't keep relationships in your head.
Identity Resolution Without the Platform Tax
The hardest part of building a customer 360 isn't the data modeling. It's deciding which key wins when systems disagree.
Your CRM says Acme Corp is one account. Your product database has three workspaces under acme.com, acme.io, and a Gmail address the founder used during trial. Billing shows two separate Stripe customers because someone fat-fingered the company name during a plan upgrade.
CDP.com's glossary distinguishes between a Single Customer View (the technical achievement of one unified record) and a Customer 360 (the strategic application of that view). The distinction matters because most teams stall at the first step. They want the strategic outcome but won't do the unglamorous work of defining merge rules.
Here's the approach that works: pick one system as the source of truth for identity, usually your CRM for B2B. Every other system maps to that key. When you can't match automatically, you flag for manual review rather than guessing. A 95% match rate with 5% flagged for humans beats a 100% automated match rate with 8% wrong.
The identity resolution logic lives in your transformation layer. If you're using dbt, this is a staging model that outputs one canonical account_id per customer, with a lookup table showing which IDs from other systems map to it.
The Build Sequence That Actually Ships
Week one: inventory your sources. List every system that holds customer data, what key it uses, and who owns it. This sounds trivial until you discover that Product uses a UUID, Sales uses Salesforce Account ID, and Finance uses Stripe Customer ID, and nobody documented the mapping.
Week two: define your identity model. Pick the canonical key. Write the merge rules. Document the edge cases you're punting on (subsidiaries, acquisitions, customers who churn and return).
Week three: build the base tables. Pull identity, firmographic, and commercial data into your warehouse. Join them on your canonical key. This is your minimum viable 360.
Week four: add product usage. This is usually the messiest integration because product telemetry wasn't designed for account-level rollups. You'll need to aggregate user-level events to the account level, which means defining what "active" means for your product.
Weeks five and six: add support data and derived lifecycle fields. Build the first dashboard or CRM integration that surfaces the unified view to the people who need it.
Crystalloids documented a similar approach with Rituals, where they centralized real-time data from various touchpoints in Google Cloud, using BigQuery for analytics and APIs for scaling. The pattern is consistent: warehouse as the hub, APIs for ingestion, BI or CRM for activation.
When a CDP Actually Makes Sense
I'm not arguing CDPs are never worth it. They're worth it when your primary use case is real-time, cross-channel activation at consumer scale. If you're a B2C company sending millions of personalized messages per day and need sub-second identity resolution across web, mobile, and email, the build-versus-buy math shifts.
For most B2B companies, the use case is different. You want Sales to see which accounts are at risk before the QBR. You want Marketing to know which target accounts are actually engaging with the product. You want Finance to understand expansion patterns by segment. These are batch use cases. They don't need real-time. They need accuracy and accessibility.
Douglas Cirillo put it well: "You don't need a 360° view of the customer. You need the right one." More data isn't the goal. Alignment is. A CDP that gives you 47 attributes nobody uses is worse than a warehouse table with 12 attributes that show up in every pipeline review.
The Failure Modes to Avoid
Three patterns kill these projects before they deliver value.
First, scope creep. You start with "unified account view for Sales" and end up trying to build a real-time personalization engine. Ship the simple version. Prove value. Expand later.
Second, no owner. The 360 sits between Marketing, Sales, RevOps, and Data. If nobody owns the data model, nobody maintains it, and it rots within two quarters.
Third, building for the dashboard instead of the decision. The question isn't "what data can we show?" It's "what decision does this enable?" If you can't name the meeting where this data changes an outcome, you're building a vanity project.
The customer 360 that works is the one your team actually uses. Build it where your data already lives, model it for the decisions you actually make, and skip the platform until you've outgrown the warehouse. Your CFO will thank you, and your Sales team might actually open the dashboard.
